Introduction To Software Engineering: UML: Ananda Amatya Department of Computer Science University of Warwick

Introduction to Software Engineering: UML
Ananda Amatya
Department of Computer Science
University of Warwick
November 26, 1999

2
Contents
1 Lecture 0: Introduction to UML 27
1.1 UML Introduction Topics . . . . . . . . . . . 28
1.1.1 Commentary . . . . . . . . . . . . . 29
1.2 Recommended Books . . . . . . . . . . . . 30
1.2.1 Commentary . . . . . . . . . . . . . 31
1.3 Introduction . . . . . . . . . . . . . . . . . . 32
1.3.1 Commentary . . . . . . . . . . . . . 33
1.4 Notation . . . . . . . . . . . . . . . . . . . . 34
1.4.1 Commentary . . . . . . . . . . . . . 35
1.5 Modelling Elements: Components . . . . . 36
1.5.1 Commentary . . . . . . . . . . . . . 37
3
4 CONTENTS
1.6 Modelling Elements: Relationships . . . . . 38
1.6.1 Commentary . . . . . . . . . . . . . 39
1.7 Modelling Elements: States & Interactions . 40
1.7.1 Commentary . . . . . . . . . . . . . 41
1.8 Modelling Element Diagrams . . . . . . . . 42
1.9 Modelling Elements: Notes . . . . . . . . . 43
1.9.1 Commentary . . . . . . . . . . . . . 44
1.10 Modelling Mechanisms: Adornments . . . . 45
1.10.1 Commentary . . . . . . . . . . . . . 46
1.11 Specification . . . . . . . . . . . . . . . . . 47
1.12 Extending Notation: Stereotype . . . . . . . 48
1.12.1 Commentary . . . . . . . . . . . . . 49
1.13 Extending Notation: Tagged Values . . . . . 50
1.13.1 Commentary . . . . . . . . . . . . . 51
1.14 Extending Notation: Constraints . . . . . . 52
1.14.1 Commentary . . . . . . . . . . . . . 53
CONTENTS 5
1.15 Diagrams . . . . . . . . . . . . . . . . . . . 54
1.15.1 Commentary . . . . . . . . . . . . . 55
1.16 Use Case Diagram . . . . . . . . . . . . . . 56
1.16.1 Commentary . . . . . . . . . . . . . 57
1.17 Class Diagram . . . . . . . . . . . . . . . . 58
1.17.1 Commentary . . . . . . . . . . . . . 59
1.18 State Diagram . . . . . . . . . . . . . . . . 60
1.18.1 Commentary . . . . . . . . . . . . . 61
1.19 Sequence Diagram . . . . . . . . . . . . . . 62
1.19.1 Commentary . . . . . . . . . . . . . 63
1.20 Collaboration Diagram . . . . . . . . . . . . 64
1.20.1 Commentary . . . . . . . . . . . . . 65
1.21 Activity Diagram . . . . . . . . . . . . . . . 66
1.21.1 Commentary . . . . . . . . . . . . . 67
1.22 Package Diagram . . . . . . . . . . . . . . . 68
1.23 Component Diagram . . . . . . . . . . . . . 69

6 CONTENTS
1.24 Deployment Diagram . . . . . . . . . . . . . 70
1.25 Views . . . . . . . . . . . . . . . . . . . . . 71
1.26 UML Views . . . . . . . . . . . . . . . . . . 72
1.26.1 Commentary . . . . . . . . . . . . . 73
1.27 Use Case View . . . . . . . . . . . . . . . . 74
1.28 Logical View . . . . . . . . . . . . . . . . . 75
1.29 Concurrency View . . . . . . . . . . . . . . 76
1.30 Concurrency View . . . . . . . . . . . . . . 77
1.31 Component View . . . . . . . . . . . . . . . 78
1.32 Deployment View . . . . . . . . . . . . . . . 79
1.33 Analysis: Requirements, Risks, Constraints 80
1.34 Design: Package, Class, Relationships, User-

Interface . . . . . . . . . . . . . . . . . . . . 81
1.35 Design (Dynamic): Sequence, Collaboration,

State, Activity . . . . . . . . . . . . . . . . . 82
1.36 Implementation:Components, Codes, Deploy-

ment . . . . . . . . . . . . . . . . . . . . . . 83
CONTENTS 7
1.37 Commentary . . . . . . . . . . . . . . . . . 84
1.38 Lecture 0 Exercise . . . . . . . . . . . . . . 85
2 Lecture 1: Use Cases and Use Case Diagrams 89
2.1 Lecture 1: Use Case Topics . . . . . . . . . 90
2.2 Commentary . . . . . . . . . . . . . . . . . 91
2.3 Introduction . . . . . . . . . . . . . . . . . . 92
2.4 Commentary . . . . . . . . . . . . . . . . . 93
2.5 Actor . . . . . . . . . . . . . . . . . . . . . . 94
2.6 Commentary . . . . . . . . . . . . . . . . . 95
2.7 Actor Icon & Stereotyped Class . . . . . . . 96
2.8 Actor Interactions with a System . . . . . . 97
2.9 Actor Generalisation . . . . . . . . . . . . . 98
2.10 Example: Actors in a University Course Reg-

istration Sys. . . . . . . . . . . . . . . . . . 99
2.11 Actors for Course Registration System . . . 100
2.12 Use Case . . . . . . . . . . . . . . . . . . . 101

8 CONTENTS
2.13 Use Case Icon . . . . . . . . . . . . . . . . 102
2.14 Documentation Property of Use Case . . . 103
2.15 Use Case Relationships . . . . . . . . . . . 104
2.16 << in lude >> Relationship . . . . . . . . 105
2.17 << extend >> Relationship . . . . . . . . . 106
2.18 Commentary . . . . . . . . . . . . . . . . . 108
2.19 Use Case Diagrams . . . . . . . . . . . . . 109
2.20 Use Case Diagrams . . . . . . . . . . . . . 110
2.21 Example: University Course Registration . . 111
2.22 Actors in University Course Registration . . 112
2.23 Actors . . . . . . . . . . . . . . . . . . . . . 113
2.24 Use Cases in University Course Registration 114
2.25 Use Case Names . . . . . . . . . . . . . . . 115
2.26 Use Cases . . . . . . . . . . . . . . . . . . 116
2.27 Use Case Documentations . . . . . . . . . 117
2.28 Use Case Event Flow Documentations . . . 118

CONTENTS 9
2.29 Use Case Relationships . . . . . . . . . . . 119
2.30 Example Use Case Relationship . . . . . . 120
2.31 Use Case Diagrams in Course Registration

System . . . . . . . . . . . . . . . . . . . . 121
2.32 Main Use Case Diagram . . . . . . . . . . . 122
2.33 Additional Use Case Diagram . . . . . . . . 123
2.34 Testing Use Cases . . . . . . . . . . . . . . 124
2.35 Realizing Use Cases . . . . . . . . . . . . . 125
2.36 Commentary . . . . . . . . . . . . . . . . . 126
2.37 Scenario . . . . . . . . . . . . . . . . . . . . 127
2.38 Use Case Realization: Collaboration . . . . 128
2.39 Use Case, Collaboration, Scenario . . . . . 129
2.40 Lecture 1 Exercises: . . . . . . . . . . . . . 130
3 Lecture 2: Classes, Objects, Packages and Cor-

responding Diagrams 133
10 CONTENTS
3.1 Static Modelling: Classes, Objects, Pack-

ages, Diagrams . . . . . . . . . . . . . . . . 134
3.1.1 Commentary . . . . . . . . . . . . . 135
3.2 Classes . . . . . . . . . . . . . . . . . . . . 136
3.3 Commentary: Class . . . . . . . . . . . . . 137
3.4 Commentary: Finding classes . . . . . . . . 138
3.5 Commentary: Class Name . . . . . . . . . 139
3.6 Commentary: Class Attributes . . . . . . . 140
3.7 Commentary: Operations . . . . . . . . . . 141
3.8 Commentary: Type . . . . . . . . . . . . . . 143
3.9 Example Structure of Class Course . . . . . 144
3.10 Commentary . . . . . . . . . . . . . . . . . 145
3.11 Creating Operations . . . . . . . . . . . . . 146
3.12 Commentary . . . . . . . . . . . . . . . . . 147
3.13 Example: Car Class Details . . . . . . . . . 148
3.14 Example Class: Class Car . . . . . . . . . . 149

CONTENTS 11
3.15 Example: Invoice Class Details . . . . . . . 150
3.16 Commentary . . . . . . . . . . . . . . . . . 151
3.17 Documenting Attributes & Operations . . . 152
3.18 Example Class Diagram: Class Documen-

tation . . . . . . . . . . . . . . . . . . . . . 153
3.19 Stereotype Classes . . . . . . . . . . . . . 154
3.20 Entity Class: StudentInformation Class & Spec-

ification . . . . . . . . . . . . . . . . . . . . 155
3.21 Template Example: Class Instantiation by

name and by Refinement . . . . . . . . . . 156
3.22 Commentary . . . . . . . . . . . . . . . . . 157
3.23 Class Relationships . . . . . . . . . . . . . 158
3.24 Commentary . . . . . . . . . . . . . . . . . 159
3.25 Association . . . . . . . . . . . . . . . . . . 160
3.26 Commentary . . . . . . . . . . . . . . . . . 161
3.27 Naming Relationships . . . . . . . . . . . . 162
3.28 Commentary . . . . . . . . . . . . . . . . . 163

12 CONTENTS
3.29 Multiplicity Indicators . . . . . . . . . . . . . 164
3.30 Commentary . . . . . . . . . . . . . . . . . 165
3.31 Association Role Name at one end . . . . . 166
3.32 Commentary . . . . . . . . . . . . . . . . . 167
3.33 Association Role Name at both ends . . . . 168
3.34 Navigable Association . . . . . . . . . . . . 169
3.35 Aggregation . . . . . . . . . . . . . . . . . . 170
3.36 Commentary . . . . . . . . . . . . . . . . . 171
3.37 Shared Aggregation . . . . . . . . . . . . . 172
3.38 Composition Aggregation . . . . . . . . . . 173
3.39 Commentary . . . . . . . . . . . . . . . . . 174
3.40 Composition Aggregation: One solid Diamond

for each Part . . . . . . . . . . . . . . . . . 175
3.41 Composition Aggregation: One solid diamond

and Parts tree . . . . . . . . . . . . . . . . . 176
3.42 Composition Aggregation: Parts inside whole

class . . . . . . . . . . . . . . . . . . . . . . 177
CONTENTS 13
3.43 Composition Aggregation: Two or more parts 178
3.44 Qualified Association . . . . . . . . . . . . . 179
3.45 Commentary . . . . . . . . . . . . . . . . . 180
3.46 Or-Association . . . . . . . . . . . . . . . . 181
3.47 Commentary . . . . . . . . . . . . . . . . . 182
3.48 Ordered Association . . . . . . . . . . . . . 183
3.49 Commentary . . . . . . . . . . . . . . . . . 184
3.50 Reflexive Relationships: Recursive Associ-

ation . . . . . . . . . . . . . . . . . . . . . . 185
3.51 Commentary . . . . . . . . . . . . . . . . . 186
3.52 Recursive Association . . . . . . . . . . . . 187
3.53 Commentary . . . . . . . . . . . . . . . . . 188
3.54 Recursive Association of Courses & Prereq-

uisites . . . . . . . . . . . . . . . . . . . . . 189
3.55 Commentary . . . . . . . . . . . . . . . . . 190
3.56 Association Class . . . . . . . . . . . . . . 191
3.57 Commentary . . . . . . . . . . . . . . . . . 192

14 CONTENTS
3.58 Ternary Association . . . . . . . . . . . . . 193
3.59 Commentary . . . . . . . . . . . . . . . . . 194
3.60 Class Diagrams . . . . . . . . . . . . . . . . 195
3.61 Commentary . . . . . . . . . . . . . . . . . 196
3.62 Example: A class diagram to model an In-

surance Business . . . . . . . . . . . . . . 197
3.63 Commentary . . . . . . . . . . . . . . . . . 198
3.64 Example Class Diagram: Order . . . . . . . 199
3.65 Commentary . . . . . . . . . . . . . . . . . 200
3.66 Example: Order with navigability . . . . . . 201
3.67 Object Diagram . . . . . . . . . . . . . . . . 202
3.68 Example Object Diagram with Roles . . . . 203
3.68.1 Commentary . . . . . . . . . . . . . 204
3.69 Example Class Diagram: Object Diagram

(Bob’s Computer) . . . . . . . . . . . . . . . 205
3.69.1 Commentary . . . . . . . . . . . . . 206
3.70 Interfaces . . . . . . . . . . . . . . . . . . . 207

CONTENTS 15
3.70.1 Commentary . . . . . . . . . . . . . 208
3.71 Packages: Example . . . . . . . . . . . . . 209
3.72 Commentary . . . . . . . . . . . . . . . . . 210
3.73 Package Classes: Example . . . . . . . . . 213
3.74 Package Classes: Example . . . . . . . . . 214
3.75 Example Packages: Class Dependence on

Package Interface . . . . . . . . . . . . . . 215
3.76 Package Relationships . . . . . . . . . . . . 216
3.77 Commentary . . . . . . . . . . . . . . . . . 217
3.78 Example Packages: Subsystem Dependence 218
3.79 Example Packages: Subsystem Importing . 219
3.80 Example Packages: Subsystem Generali-

sation and Dependence . . . . . . . . . . . 220
3.81 Generalisation (Inheritance) Relationships . 221
3.82 Commentary . . . . . . . . . . . . . . . . . 222
3.83 Example: Vehicles . . . . . . . . . . . . . . 223
3.84 Inheritance Relationship: Vehicle Tree . . . 224

16 CONTENTS
3.85 Inheritance Relationship: Vehicle Hierarchy 225
3.86 Inheritance Relationship: Vehicle abstract,

with abstract ops. . . . . . . . . . . . . . . . 226
3.87 Commentary . . . . . . . . . . . . . . . . . 227
3.88 Inheritance Relationship: Person assoc. drive

with Vehicle . . . . . . . . . . . . . . . . . . 229
3.89 Example: Hierarchy with attribs. and as-

socs. for children . . . . . . . . . . . . . . . 230
3.90 Inheritance Relationship with class attribs.

and assocs. . . . . . . . . . . . . . . . . . . 231
3.91 Example: Hierarchy with relocated attribs.

and opers. . . . . . . . . . . . . . . . . . . . 232
3.92 Inheritance Relationship with reallocated at-

tribs. and ops. . . . . . . . . . . . . . . . . 233
3.93 Inheritance vs Aggregations . . . . . . . . . 234
3.94 Example: Inheritance vs Aggregate Contd. 235
3.95 Inheritance vs Aggregation . . . . . . . . . 236

CONTENTS 17
3.96 Constraint Generalisations: Inheritance Con-

straints . . . . . . . . . . . . . . . . . . . . 237
3.97 Constraint Generalisations: Alternative In-

heritance Constraints . . . . . . . . . . . . 238
3.98 Class Diagrams: Overlapping . . . . . . . . 239
3.99 Disjoint Generalisation . . . . . . . . . . . . 240
3.100Complete Generalisation: No other Sub-class 241
3.101Dependency Relationship . . . . . . . . . . 242
3.102Refinement Relationship . . . . . . . . . . . 243
3.103Commentary . . . . . . . . . . . . . . . . . 244
3.104Derived Association . . . . . . . . . . . . . 245
3.105Commentary . . . . . . . . . . . . . . . . . 246
3.106Constraint Association . . . . . . . . . . . . 247
3.107Commentary . . . . . . . . . . . . . . . . . 248
3.108Constraint Attribute . . . . . . . . . . . . . . 249
3.109Commentary . . . . . . . . . . . . . . . . . 250
3.110Derived Attribute . . . . . . . . . . . . . . . 251

18 CONTENTS
3.111Commentary . . . . . . . . . . . . . . . . . 252
3.112Lecture 2 Exercises: . . . . . . . . . . . . . 253
3.113Sequences, Collaborations, Activities, States

and Diagrams . . . . . . . . . . . . . . . . . 259
3.114Commentary . . . . . . . . . . . . . . . . . 260
3.115Sequence Diagrams . . . . . . . . . . . . . 263
3.116Sequence Diagrams Cont’d. . . . . . . . . . 264
3.117Example: Printer Service . . . . . . . . . . 265
3.118Example: Use of Label for Time Constraint 266
3.119Example: Use of Label for Iteration . . . . . 267
3.120Example: Recursion . . . . . . . . . . . . . 268
3.121Example: Creating a Course . . . . . . . . 269
3.122Example: Add a Course Offering . . . . . . 270
3.123Example: Order Sequence . . . . . . . . . 271
3.124Example: Transaction Sequence . . . . . . 272
3.125Example: Transaction Check . . . . . . . . 273

CONTENTS 19
3.126Commentary . . . . . . . . . . . . . . . . . 274
3.127Collaboration Diagram . . . . . . . . . . . . 275
3.128Commentary . . . . . . . . . . . . . . . . . 276
3.129Message Flow: message label syntax . . . 277
3.130Message Flow: message label syntax (cont’d.)278
3.131Links . . . . . . . . . . . . . . . . . . . . . . 279
3.132Lifetime of Object . . . . . . . . . . . . . . . 280
3.133Example: Print Service . . . . . . . . . . . 281
3.134Example: Iteration and Return value . . . . 282
3.135Example: Elevator - Calling a Lift by press-

ing a button . . . . . . . . . . . . . . . . . . 283
3.136Example: Elevator - Explanation . . . . . . 284
3.137Example: Summarising Sales Result . . . . 285
3.138Example: Sales Result Explanation . . . . . 286
3.139Example: Add A Student . . . . . . . . . . . 287
3.140Example: Add A Student Explanation . . . 288

20 CONTENTS
3.141Example: Add a Course Offering . . . . . . 289
3.142Example: Add Course Offering Explanation 290
3.143Example: Create A Course . . . . . . . . . 291
3.144Example: Create A Course Explanation . . 292
3.145Example: Orders with Simple Numbering . 293
3.146Example: Orders Simple Numbering Expla-

nation . . . . . . . . . . . . . . . . . . . . . 294
3.147Activity Diagrams . . . . . . . . . . . . . . . 295
3.148Commentary . . . . . . . . . . . . . . . . . 296
3.149Transitions . . . . . . . . . . . . . . . . . . 297
3.150Commentary . . . . . . . . . . . . . . . . . 298
3.151Activity Diagram: Concurrent actions . . . . 299
3.152Commentary . . . . . . . . . . . . . . . . . 300
3.153Activity Diagram: Swim Lanes . . . . . . . . 301
3.154Commentary . . . . . . . . . . . . . . . . . 302
3.155Activity Diagram: Using Objects with Activity

Diagram . . . . . . . . . . . . . . . . . . . . 303
CONTENTS 21
3.156Commentary . . . . . . . . . . . . . . . . . 304
3.157Activity Diagram: Passing Signals in Activity

Diagram . . . . . . . . . . . . . . . . . . . . 305
3.158Commentary . . . . . . . . . . . . . . . . . 306
3.159Activity Diagram: Receiving An Order . . . 307
3.160Activity Diagram: Receiving A Supply . . . 308
3.161Activity Diagram: Swim Lane for Order Pro-

cessing . . . . . . . . . . . . . . . . . . . . 309
3.162Activity Diagram: Decomposing Activity Di-

agram . . . . . . . . . . . . . . . . . . . . . 310
3.163Commentary . . . . . . . . . . . . . . . . . 311
3.164State . . . . . . . . . . . . . . . . . . . . . . 312
3.165Commentary . . . . . . . . . . . . . . . . . 313
3.166State Activities . . . . . . . . . . . . . . . . 314
3.167Commentary . . . . . . . . . . . . . . . . . 315
3.168State Transitions without Events . . . . . . 316
3.169Transitions . . . . . . . . . . . . . . . . . . 317
22 CONTENTS
3.170Commentary . . . . . . . . . . . . . . . . . 319
3.171Events for a transition: 4 kinds . . . . . . . 320
3.172State Diagrams . . . . . . . . . . . . . . . . 321
3.173Example State Diagram: Invoice . . . . . . 322
3.174Example States: CourseOffering . . . . . . 323
3.175Example Transition: Add Student/Set Count=0324
3.176Commentary . . . . . . . . . . . . . . . . . 325
3.177Example Transitions: CourseOffering . . . . 326
3.178Example State Diagram: CourseOffering . . 327
3.179Sending message between State Diagrams 328
3.180Sending Messages to States . . . . . . . . 329
3.181Commentary . . . . . . . . . . . . . . . . . 330
3.182Signals & States . . . . . . . . . . . . . . . 331
3.183Or State . . . . . . . . . . . . . . . . . . . . 332
3.184And State . . . . . . . . . . . . . . . . . . . 333
3.185Install State . . . . . . . . . . . . . . . . . . 334

CONTENTS 23
3.186Order Processing . . . . . . . . . . . . . . . 335
3.187Order Processing with Cancellation . . . . . 336
3.188Order Processing with SuperState . . . . . 337
3.189Authorising Order . . . . . . . . . . . . . . . 338
3.190Concurrent States in Order Processing . . . 339
3.191Lecture 3 Exercises: . . . . . . . . . . . . . 340
3.192Components, Deployment, Patterns, Frame-

works . . . . . . . . . . . . . . . . . . . . . 346
3.193Architectural Views . . . . . . . . . . . . . . 347
3.194Logical View . . . . . . . . . . . . . . . . . 348
3.195Logical View of Package in Course Regis-

tration . . . . . . . . . . . . . . . . . . . . . 349
3.196Logical View of Package in Course Regis-

tration . . . . . . . . . . . . . . . . . . . . . 350
3.197Component View & Diagrams . . . . . . . . 351
3.198Component Name, Tagged Value, Realized

Interfaces . . . . . . . . . . . . . . . . . . . 352
24 CONTENTS
3.199Component and Classes . . . . . . . . . . . 353
3.200Components and Interfaces . . . . . . . . . 354
3.201Components and Interfaces Cont’d. . . . . 355
3.202Binary Replaceability . . . . . . . . . . . . . 356
3.203Kinds of Components . . . . . . . . . . . . 357
3.204Component View of Package in Course Reg-

istration . . . . . . . . . . . . . . . . . . . . 358
3.205Software Components of University Class . 359
3.206Process View of Lecturer Executables . . . 360
3.207Process View of Lecturer Executables . . . 361
3.208Deployment View of Course Registration . . 362
3.209Collaboration . . . . . . . . . . . . . . . . . 363
3.210Patterns and Frameworks . . . . . . . . . . 364
3.211Design Patterns . . . . . . . . . . . . . . . 365
3.212Mechanisms . . . . . . . . . . . . . . . . . 366
3.213Architectural Patterns – Frameworks . . . . 367

CONTENTS 25
3.214Frameworks . . . . . . . . . . . . . . . . . . 368
26 CONTENTS
Chapter 1
Lecture 0: Introduction to UML
27
28 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML
1.1 UML Introduction Topics
Recommended Books
Introduction
Notation
Diagrams
Views
OOSD
Requirements
Analysis
Design
Implementation
1.1. UML INTRODUCTION TOPICS 29
1.1.1 Commentary
This lecture will give an overview of the UML component of

the course. These notes draw much of the material from
the three books recommended here. However, over the
last year many more books on UML have been published,
and many of them are to be found in the university library.
UML is the OMG standard for describing the complete life
cycle of object-oriented software in terms of diagrams and
textual descriptions. Since September 1997 when UML
1.1 became an OMG standard, there have been many re-
visions. The current standard is UML 1.3 as described
in Booch et.al. books. The reference documents for this
standard are available at http://www.omg.org. The content
of these notes follows this standard. UML uses a whole
range of diagrams appropriate for the various phases of
a software’s life-cycle to deal with its static structures and
dynamic behaviours. UML supports different views of the
software’s architecture. Particularly relevant for this course
are UML features to support Requirement, Analysis, De-
sign, Implementation and Testing of Object Oriented Soft-
ware Development.
1.2 Recommended Books
1. Booch, Grady and Rumbaugh, James and Jacobson,

Ivar, The Unified Modelling Language User Guide, Addition-
Wesley, 1998.
2. Eriksson, H. and Penker, M., UML Toolkit, John Wiley,

1998.
3. Fowler, Martin and Scott, Kendall, UML Distilled: Ap-

plying the Standard Object Modelling Language, Addison-
Wesley, 1998.
1.2. RECOMMENDED BOOKS 31
1.2.1 Commentary
Booch et. al.’s book is the most authoritative and follows the
1.3 standard. It is conceptually quite hard at places. Some
examples are rather sketchy, and language bindings (Java
or C++) are touched upon only briefly. Quite expensive (
40 U. K. Pounds).
Eriksson et. al.’s book is about UML 1.1. It is well writ-

ten, and comes with a demonstration version of Rational
Rose (version 4) and has a complete case study exam-
ple (though somewhat simple). This version of Rational
Rose differs appreciably from the current commercial ver-
sion, though. Cheaper ( 35 U.K. Pounds)
Fowler et.al.’s book also uses UML 1.1. It is a rather slim

volume with good examples. The technical content is ex-
cellent, though quite hard. Cheapest of the three ( 25
U.K. Pounds).
1.3 Introduction
UML concepts to be introduced and illustrated by exam-

ples will include:
UML (Unified Modelling Language) is a modelling lan-

guage using text and graphical notation for document-
ing specification, analysis, design and implementation
of OOSD (Object-Oriented System Development) pro-
cess.
It is the recommended OMG (Object Management Group)

standard notation for visual modelling with well-defined
syntax and semantics.
Logical, Component, Process, Deployment and Use case

views (the “4+1 view”) of UML’s architecture for complex
systems development will be discussed.
UML can be used with all processes throughout the

development life cycle and across different implemen-
tation technologies. A unified approach to the methods
in a development process has been made by Booch
et. al. (discussed in a recent book on Unified Software
Development Process), but is not the concern of UML.
1.3. INTRODUCTION 33
1.3.1 Commentary
In Software Engineering, modelling is an activity that is ap-

plied to every software system throughout its life-cycle. Its
purpose is to pinpoint relevant issues about the system at
every level of abstraction needed from all points of view.
UML is a graphical language with a standard syntax and
semantics to formalise this modelling process. UML nota-
tion provides rules and modelling elements to document the
whole software process in terms of diagrams and texts so
that they may be used along with software tools.
This ISE course in Warwick has been using the Fusion

method for the past few years. The Fusion book recom-
mended for the course uses OMT notation. Fusion in UML
notation will be taught by Mike Joy in the second half of
this term. You are expected to follow the Fusion method in
UML notation in your Group project work.
1.4 Notation
Modelling Elements:
– Basic elements
– Composite elements
– Relationships between elements
– States and Interactions
– Annotations
Modelling Mechanisms:
– Adornments
– Specifications
Modelling Rules
Notation Extending Mechanisms:
– Stereotypes
– Tagged Values
– Constraints
1.4. NOTATION 35
1.4.1 Commentary
UML provides various basic elements for building models.

Basic elements may be grouped into composite elements.
Relational elements deal with various kinds of relationships
between the model elements. Other elements are there
to describe object states and interactions. Annotations are
provided for clarifying the meaning. Specifications are saved
in files to document responsibilities and capabilities of the
model elements. Adornments make symbols mean spe-
cific things. In order to cover every possible situation UML
provides notation extending mechanisms. One such mech-
anism is stereotyping which specialises the general no-
tation to specific application areas. Standard stereotypes
and icons are provided, though domain specific stereo-
types and icons may be introduced as and when required.
Notation extension uses tagged values to add more infor-
mation. Constraints are used to show restrictions that ap-
ply.
1.5 Modelling Elements: Components
Basic:
– Class
– Object
– Interface
– Collaboration
– Use Case
– Active Class
– Component
– Node
Composite:
– Package
1.5. MODELLING ELEMENTS: COMPONENTS 37
1.5.1 Commentary
Classes are Basic model elements. Class names are shown

in boldface type. Abstract classes are shown in italic. Ob-
jects (class instances) are shown by class elements with
underlined names. Class name or object name may be
elided (anonymous). Interfaces are indicated by lollipops.
No implementation just operations are provided. Collabora-
tions are indicated by dashed ovals. They realize use cases.
Use case is shown as an ellipse; it shows a functionality of
the system for the external user. Active classes are shown
by thick bordered class boxes; they represent independent
thread of processing. A component is a combination of one
or more classes that forms a physical software. A node is
a processor or device (a physical hardware). A compos-
ite model element is a package or a subsystem of base or
composite elements.
1.6 Modelling Elements: Relationships
Relationships represented by connecting lines, labels and

arrows
– Association (solid line between instances) or Aggre-

gation (solid line with diamond (empty or full) be-
tween whole and part) occasionally directed, labelled,
and with multiplicities and role names
– Dependency (dashed line, possibly directed and oc-
casionally with a label)
– Generalisation (solid line with hollow arrowhead point-
ing to the parent)
– Realization (dashed line with hollow arrowhead, e.g.,
between interfaces and the classes that realize them
and between use cases and collaborations that re-
alize them)
1.6. MODELLING ELEMENTS: RELATIONSHIPS 39
1.6.1 Commentary
Association and aggregation refer to structural relationships

between objects. In normal aggregation parts may be added
or removed; parts may survive after the whole has died.
In containment aggregation the parts are contained in the
whole and die with the container. Dependency refers to
relationships between whole classes; type of parameter
passed to the calling class or the type of returned value.
Generalisation is finding the superclass from subclasses,
specialisation is the opposite. Realization is implementing
classes that collaborate to realize the use case. Interfaces
are realised by the classes or components that implement
them.
1.7 Modelling Elements: States & Interactions
State:
– Transitions
– Events
– Activities
– Rounded rectangle with name
Interaction:
– Message exchange between objects

– Action sequences
– Links
– solid line with a solid arrow head and a label giving
the operation name
1.7. MODELLING ELEMENTS: STATES & INTERACTIONS 41
1.7.1 Commentary
Attributes of an object change to give transition to another

state. Events trigger the transition from one state to an-
other. Links are instances of relationships and refer to links
between objects
1.8 Modelling Element Diagrams
Class Object State
Attributes Attributes
Operations Operations
Node Interface
Use Case
Package Note
Component
Association Aggregation Aggregation

Composition
Dependency Generalization Realization
1.9. MODELLING ELEMENTS: NOTES 43
1.9 Modelling Elements: Notes
Note: rectangle with top-right corner turned and with

textual comment inside
Add info for explanation or reminders
String type not known to UML
Associate to a diagram element using dashed line
May contain question for future resolution
Can be stereotyped
Stock Option
Using Black-Scholes
TheorPrice()
MarketPrice() Formula
ExpireDate()
1.9.1 Commentary
“dog-eared” box is used for notes. Comments are used in

notes. May contain stereotypes, e.g., <<requirement>>.
1.10. MODELLING MECHANISMS: ADORNMENTS 45
1.10 Modelling Mechanisms: Adornments
Graphical
Add semantics
Boldface (as in Class, Node type)
Underline (as in object, instance of a node)
Multiplicities of relationships
1.10.1 Commentary
Graphs includes lines and texts. Bold line rectangles are

used for active classes. Italic names are used for abstract
classes.
1.11. SPECIFICATION 47
1.11 Specification
Property of a model element can be specified further
Property has a name and tagged-values (of predefined

type, e.g. string or an integer)
Predefined properties: Documentation, Responsibility, Per-

sistence, Concurrency
Additional properties (with new names and correspond-

ing tagged-values) are given to specify further model
element instances
These informal specification on model instances are

accessed via tools.
For example, a Class may be given additional property

of a Portfolio (name) with suitable specification (tagged-
value) for it.
1.12 Extending Notation: Stereotype
Extend/adjust existing model element.
New model element based on existing one.
Adds extra semantics to the new model element
Can have stereotypes of:
– Class (e.g., <<Boundary>>, <<Entity>>, <<Control>>)

– Node
– Component
– Notes
– Generalisation
– Association (e.g., <<include>>, <<extend>>)
– Dependencies
– ... etc.
Already existing stereotypes may be used to modify an

existing model element.
Double angle brackets (<<...>>), “guillemets” used to

identify stereotypes
Also Graphical representation using icon (e.g., Actor)

1.12. EXTENDING NOTATION: STEREOTYPE 49
1.12.1 Commentary
Some standard stereotypes (all inside <<...>> : chevrons

also called guillemets, pronounced Gee May):
<<become>>
<<constructor>>
<<copy>>
<<enumeration>>
<<exceptions>>
<<friend>>
<<helper>>
<<includes>>
<<process>>
<<send>>
<<query>>
<<type>>
1.13 Extending Notation: Tagged Values
Model elements with additional properties are given

name-value pairs, the value being stored as tagged-
values: string or integer to specify the property
Tagged properties are added on top of predefined ones.

1.13. EXTENDING NOTATION: TAGGED VALUES 51
1.13.1 Commentary
Some standard tagged values (all inside {...} :):
{version=...}
{abstract}
{author=...}
{status=...}
1.14 Extending Notation: Constraints
Restricts the usage or meaning or both of a model ele-

ment
May be declared in a tool and used in diagrams
May be defined and applied as needed in a diagram
Classes, objects, relationships can be constrained
SeniorCitizenGroup 0..* 0..* Person

{person.age > 60}
1.14. EXTENDING NOTATION: CONSTRAINTS 53
1.14.1 Commentary
Some standard constraints (all inside {...} :):
{disjoint}
{subset}
{overlapping}
{constraint1, constrraint2}
1.15 Diagrams
Use-case
Class
Object
State
Sequence
Collaboration
Activity
Package
Component
Deployment
1.15. DIAGRAMS 55
1.15.1 Commentary
Objects are instances of classes. State means state of an

object; state-charts are used. Deployment and component
diagrams are physical (files).
1.16 Use Case Diagram
Sales Statistics Customer Statistics
Signing an insurance policy
Register for course
Model the behaviour of a (sub)system

1.16. USE CASE DIAGRAM 57
1.16.1 Commentary
Each use case represents a functionality offered by the

system. Use case diagram shows it simply. This must
be supported by full textual description in terms of flow
of events, the scenarios. Sometime activity diagrams are
preferable to text descriptions. Finding actors and use
cases to draw use case diagrams can be hard and should
be done iteratively.
1.17 Class Diagram
<<Boundary>>
name (b)
attributes
operations
(a) (c)
1.17. CLASS DIAGRAM 59
1.17.1 Commentary
Class diagrams give the static structure of the system. It

shows attributes and operations in the objects of the sys-
tem. The diagram represents ER diagram. The lines con-
necting the classes in the class diagram show relationships
between the connected classes. Role-names and multiplic-
ities that adorn the connecting lines describe association,
aggregation or composition. Aggregation and composition
are whole-part relationships. Other relationships may be
dependency or generalisation. Dependency relationships
involve the dependent class using the other class type pa-
rameter in method calls. Generalisation is an inheritance
relationship. Messages are passed through the connect-
ing lines in either direction unless navigation is specifically
restricted to one direction. A system may require many
class diagrams for its complete description. Special class
types (<<stereotype>>) may be introduced. Object di-
agrams use instances, objects being shown by underlined
names of instances and classes. Sometimes they may be
anonymous.
1.18 State Diagram
On first floor go up Moving up
arrived
arrived
Moving to first
floor
Moving down arrived Idle

go up
go down
time-out
1.18. STATE DIAGRAM 61
1.18.1 Commentary
The states represent object states. Change of state cor-

responds to transition from one state to another brought
about by an event. Strictly speaking Start state is a pseudo-
state, transition to next state being trigger-less. Transition
from “Idle” state to “Moving to first floor” state is caused
by the event of time-out. State diagrams help to determine
the behaviour of class operations precisely. This is possi-
ble for only those classes whose objects have well-defined
states.
1.19 Sequence Diagram
:Computer :PrinterServer :Printer :Queue
Registrar
1: Print (file)
2: Print(file)
3.1: [printer free] Print (file)

3.2: [printer busy] Store (file)
1.19. SEQUENCE DIAGRAM 63
1.19.1 Commentary
The objects used here are anonymous belonging to the

classes shown. Sequence of messages are passed be-
tween the objects one after another. The messages are
synchronous so that returns follow only after completion
of the actions. The labels used show the order of events
but are not necessary as the progress of time (top to bot-
tom) ensures this order. This sequence diagram shows the
scenarios for the particular use case. It is a generic dia-
gram and include two alternative scenarios corresponding
to printer being free and busy. It describes a dynamic situ-
ation and is an interaction diagram. It helps to specify the
corresponding system functionality. Comments may be in-
cluded on the left column of the diagram.
1.20 Collaboration Diagram
:Computer :PrinterQueue
1. Print (file) [printer busy] 1.2: Print (file)
[printer free] 1.1 Print (file) : Printer

: PrinterServer
1.20. COLLABORATION DIAGRAM 65
1.20.1 Commentary
Objects are involved. No time line is involved, but links are

labeled to show the order of events. Arrows show the flow
of messages from object to object. While sequence dia-
grams can take up a lot of space collaboration diagrams
are more compact. Sequence diagrams are semantically
equivalent to corresponding collaboration diagrams. Re-
turn lines are not shown. Active objects using concurrent
threads can be used.
1.21 Activity Diagram
Show
[disk Full] MessageBox
PrintFile() "Disk full"
on screen
Show
[free disk space] MessageBox
"Printing"
on screen
Remove ^Printer.Print(file) Create postscript

MessageBox
file
UML1.3 uses send instead of ^ in send-clause

1.21. ACTIVITY DIAGRAM 67
1.21.1 Commentary
Activity diagrams are used to specify use-cases and in op-

erations implementations. They show the sequence of activ-
ities in algorithm implementations. Generic diagrams can
have branching controlled by guards. Completion of one
activity may automatically (trigger-less) lead to another ac-
tivity. Send clauses may send action messages to trigger
other activities. UML 1.3 no longer uses ˆ for send clauses.
Start pseudo-activity may send an action message. Sim-
ilarly an action message may take to the stop pseudo-
activity.
1.22 Package Diagram
Interfaces UniversityArtifacts
People
1.23. COMPONENT DIAGRAM 69
1.23 Component Diagram
Item.java Loan.java
BorrowerInformation.java
Title.java Reservation.java
1.24 Deployment Diagram
Dorm
Registration
DatabaseServer
lecturer.exe student.exe
Library
Main Building
student.exe
student.exe
1.25. VIEWS 71
1.25 Views
4+1 UML Views: Use-Case, Logical, Concurrency, Com-

ponent, Deployment
Use-Case: functionality as seen by external actors (An-

alysts, Testers)
Logical: static structure and dynamic behaviour of func-

tionalities as seen by end-user
Concurrency: communications and synchronisation of

components as seen by system integrators
Component: code component organisation as seen by

programmers
Deployment: physical architecture of computers and

devices as seen by system engineer.
1.26 UML Views
Design View
(Logical) Implementation View
structure (Component)
behaviour system assembly
configuration
manage,ment
Use-Case View
functionalities
system services
actors
Process View
(Concurrency) Deployment View
threads system topology
processes distribution
performance delivery
scaling installation
throughput
1.26. UML VIEWS 73
1.26.1 Commentary
Logical View is also the Design view, Concurrency view is

also the Process view and Component view is also the Im-
plementation view.
1.27 Use Case View
A typical interaction between a user and a Computer

System.
Captures a functionality of the system to be used by a

user
A typical user goal to be achieved
Manifests as scenarios (instances)

1.28. LOGICAL VIEW 75
1.28 Logical View
Designers, developers
Static structure of system:class object relationship
Dynamic collaboration between objects
Persistence and concurrency in the system
Interfaces
Class structures: class and object diagrams
State, sequence, collaboration and activity diagrams

1.29 Concurrency View
Processes in the system and processors for them
Nonfunctional
Efficient usage of resources:
– Parallel execution
– Threads handling (communication & synchronisa-
tion)
Developers and integrators
Dynamic diagrams: state, sequence, collaboration, activ-

ity
Implementation diagrams: component diagrams, deploy-

ment diagrams
1.30. CONCURRENCY VIEW 77
1.30 Concurrency View
Running
Forward Backward
Low Speed High speed

1.31 Component View
Description of implementation modules.
Dependencies between modules
Developers need this view
Component diagrams: structure of components, their

dependencies and resource allocation
Progress report for development

1.32. DEPLOYMENT VIEW 79
1.32 Deployment View
Physical components: computers, devices, connections
Developers, integrators, testers
Deployment diagram
Mapping of software components to physical nodes

1.33 Analysis: Requirements, Risks, Constraints
UML support for Analysis to be discussed include:
Use cases and actors are used in use-case diagrams to vi-

sualise, capture and describe functional requirements
at the requirements analysis phase of the software de-
velopment life-cycle. Use case diagrams provide means
to communicate with domain experts to refine the con-
ceptual model of the system being designed. They pro-
vide “snapshots” of different aspects of the system re-
quired.
Domain analysis using static domain class diagrams (

encapsulating software structure), as well as state tran-
sition diagrams (of changes in an object), sequence di-
agrams (event sequence corresponding to a function-
ality) and activity diagrams (of work-flows) and parallel
processes capture static and dynamic behaviour of the
system and its constraints.
1.34. DESIGN: PACKAGE, CLASS, RELATIONSHIPS, USER-INTERFACE 81
1.34 Design: Package, Class, Relationships, User-Interface
UML support for design to be discussed include:
Use of package diagrams for architectural design and

reuse.
Detailed design using class diagrams, class stereotyping,

class packaging and documenting.
Class structure design using attributes, operations, in-

heritance.
Relationships: class diagram association, aggregation, mul-

tiplicity, package diagram relationships.
User interfaces (“lollipop” notation).

1.35 Design (Dynamic): Sequence, Collaboration, State, Activity
Dynamic modelling of object interactions using:
Sequence Diagrams: to show object interactions by time

sequence.
Collaboration Diagrams: to show object interactions by

context (relationships).
State Diagrams: to show object states and events that

cause transitions between them.
Activity Diagrams: to show flow of activities due to op-

erations and object interactions.
1.36. IMPLEMENTATION:COMPONENTS, CODES, DEPLOYMENT 83
1.36 Implementation:Components, Codes, Deployment
UML notation for implementation to be illustrated will in-

clude:
Component Diagrams: to show dependencies among

various types of codes: source, binary, executable, in-
terfaces, linking, execution, etc.
Deployment Diagrams: to show components distribu-

tion among processor nodes, repositories, networks,
and communications between them.
Java and UML: Existing tools for domain modelling,

specification modelling and code generation will be looked
into.
1.37 Commentary
Some Software Enginnering tools that support UML:
Rational (Free Demo Period):
http://www.rational.com/ http://www.rational.com/products/rose/tryit/stu
Argo/UML (FREE):
http://www.ics.uci.edu/pub/arch/uml/
A recent Britsh (Scottish) UML book:
Pooley, Rob and Stevens, Perdita: “Using UML”, Addison-

Wesley, 1998. (24.95 U.K. Pounds).
1.38. LECTURE 0 EXERCISE 85
1.38 Lecture 0 Exercise
These are simple exercises to introduce you to the UML

diagramming conventions. You may answer these using
Pencil and Paper. If you are not familiar with a diagram-
ming tool (e.g., xfig on UNIX) you might learn to draw them
using the tool of your choice.
1. Draw a diagram to show each of the following Basic

UML modelling elements:
(a) a class with

i. Name: Window,
ii. Attributes: origin, size,
iii. Operations: open(), close(), move(), display();
(b) an interface with name: ISpelling;
(c) a collaboration with name: Sales Order Validation;
(d) a use case with name: Place Order;
(e) an active class with name: Event Manager and op-
erations: suspend() and flush();
(f) a component with name CheckPoint.java;
(g) a node with name Server.
2. Draw a diagram to show a package with the name:

Race Analyser.
3. Draw a diagram to show a message with the operation

name: display exchanged between objects in an inter-
action.
4. Draw a diagram to show a state with the name: Wait-

ing.
5. Draw a diagram to show a note with the text “using

Pseudo Random Function”.
6. Draw a diagram to illustrate each of the following rela-

tionships:
(a) Dependency;
(b) Association with multiplicity and role names;
(c) Generalisation;
(d) Realisation.
7. Use adornments to show an abstract class with name:

Transaction and two public operations execute() and
rollback(), a private operation timeStamp() and a pro-
tected operation priority().
8. For each of the following give an example diagram to

show the difference between
(a) a class and its objects;

(b) an interface and its implementation.
1.38. LECTURE 0 EXERCISE 87
9. Give an example diagram to illustrate each of the fol-

lowing:
(a) Stereotype class;

(b) Tagged values;
(c) Constraint.
10. A University Course Registration System uses Course,

Course Offering, Student class with some suitable class
stereotypes, attributes, operations, and relationships.
Give a Class diagram showing appropriate
(a) Class stereotypes, names, attributes, operations;

(b) Associations, aggregations, multiplicities and navi-
gation.
Chapter 2
Lecture 1: Use Cases and Use Case

Diagrams
89
90 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS
2.1 Lecture 1: Use Case Topics
Introduction
Actor
Use Case
Use Case Diagram
Use Case Instantiation: Scenarios
Use Case Realisation with Collaboration

2.2. COMMENTARY 91
2.2 Commentary
For a proposed system use-cases represent functional re-

quirements. For an existing system they represent the avail-
able system functionalities. Use-case diagrams model the
expected behaviour of the system from the point of view of
end users and developers with a view to arriving at the sys-
tem functionalities as a result of the iterative consultative
process.
2.3 Introduction
Use case analysis of a system (or its part) is concerned with
specifying the outcome of the communication between

the system (or subsystem) and external actors (human
or automated systems) who are its users, developers
and domain experts;
capturing and analysing system functionalities (require-

ments);
validating its architecture;
verifying its services;
testing its parts and its integrity;
the variety of sequences of actions performed (scenar-

ios) by it in response to its external user requests;
what it and its parts do in response to requests by its

users, developers and domain experts (but not how the
response is realised by its implementing collaboration).
2.4. COMMENTARY 93
2.4 Commentary
Each use-case should refer to one complete system func-

tionality. Use-case represents what the system does, NOT
how it does it (No implementation details). System should
behave as a black box. Actor may be a user, a software
system seeking some service from the system or a hard-
ware. Provides support for the documentation and market-
ting team. Use-cases are used by developers and users
for validating system architecture and for verifying system
services. Use-cases are used in integration testing.
2.5 Actor
Actor icon (Stick-man);
Actor name (label for the icon);
Actor documentation: text (optional);
External user with stereotyped class <<actor>> whose

specific role is to use one or more use case in a sys-
tem;
Communication relationships with the use cases in the

system;
Identifying actors help determine use cases in the re-

quirement Analysis phase of the Software Development
Process.
The same physical object may play different roles and

become different actors that use different use cases
(e.g., the same person may be the Customer actor who
orders goods and Salesman actor who processes sales)
2.6. COMMENTARY 95
2.6 Commentary
Textual description of the actor will show its boundary.

2.7 Actor Icon & Stereotyped Class
Student
<<actor>>
Student
stereotyped
class
equivalent
Student to the icon
2.8. ACTOR INTERACTIONS WITH A SYSTEM 97
2.8 Actor Interactions with a System
Input information to the system
Receive Information from the system
Both input and receive information to and from the sys-

tem
Communication (participating) association with use cases
Interface
Each functionality of a System associated with one or

more actors (users)
Between actors: No association but possible generalisa-

tions
2.9 Actor Generalisation
Person
Lecturer Student
2.10. EXAMPLE: ACTORS IN A UNIVERSITY COURSE REGISTRATION SYS. 99
2.10 Example: Actors in a University Course Registration Sys.
Student
– A student interacts with the system to register for

courses
Lecturer
– A lecturer interacts with the system to select courses

to teach
Registrar
– The Registrar interacts with the system to create

the curriculum and to generate a timetable for the
semester, and also to maintain the information about
courses, lecturers, and students
Billing System
– Billing System interacts with the system to obtain all

the billing information on the system
2.11 Actors for Course Registration System
University
Course
Registration
System
Registrar Student
Billing System Lecturer

2.12. USE CASE 101
2.12 Use Case
Use case icon: ellipse;
Use case name: a label inside or below the ellipse icon;
Use case documentation: textual description (optional);
Use case generalisation to inherit behaviour;
Use case extension stereotypes <<include>> (to in-

clude factored out common behaviour) and <<extend>>
(to extend into variants by adding extra behaviour)
A typical use of a Computer System by an external user

(actor) involving one or more sequences of actions in
the system on behalf of the user;
Capture of a system functionality (user requirement) in

a use case;
Use case realized by a collaboration in the system;
Use case instance manifests as a scenario;
A use case encompasses all possible scenarios for it.

2.13 Use Case Icon
Sales Statistics Customer Statistics
Register for course

2.14. DOCUMENTATION PROPERTY OF USE CASE 103
2.14 Documentation Property of Use Case
To fully specify a use case its documentation must contain:
1. Purpose: goal being achieved, functionality provided by

it
2. User: actor initiating it
3. Messages exchanged with actors: events, updates, re-
trievals, decision making
4. Generalisations
5. Extension stereotypes: <include>> & <<extend>>
6. Scenarios as use case instances to complement use case
description
7. Alternative scenarios and Exceptions
8. Succinct but informal for communicating with user
9. Termination conditions, results returned to actors
10. Activity diagrams to supplement the use case, if needed
11. Example: Register for Course use case:
(a) Use case started by Student
(b) Provides facility to create, delete, modify, and/or re-
view a student schedule for a specified term
2.15 Use Case Relationships
Communicates - Participation of an actor in a use case;
Generalisation - Inheriting parent behaviour, adding and

overriding with the child’s own behaviour;
<<include>> Relationship - One Use Case including

another use case to include the latter’s behaviour
<<extend>> Relationship - One Use case is extended

to another use case so that the latter has the behaviour
of the former in addition to its own; extension can only
be done at extension points of the use case being ex-
tended.
2.16. << INCLUDE >> RELATIONSHIP 105
2.16 << in lude >> Relationship
Behaviour common to many use cases – factored off

into another use case used by the others
Example: Analyse Deal and Price Deal use cases both

use Valuation use case
Example: Signing Car Insurance use case and Sign-

ing Life Insurance use case both use Signing Insurance
Policy use case
<<include>>
Signing Car Insurance
<<include>>Signing Insurance
Signing Life Insurance
<<include>> use cases must be used by the use cases

that use them before the latter can be complete
Stereotyped Relationship
2.17 << extend >> Relationship
A use case extends another use case to do more than

the latter
Example: Capture Deal use case (keeps to the spec-

ified limits) is extended by Exceed Limits use case (to
include Capture Deal with limits exceeded)
Example: Signing Car Purchase Contract use case (nor-

mally not dealing with insurance) is extended by Signing
Insurance Policy use case (to include the car sale with
an insurance for it)
Capture Deal Exceed Limit

<<extend>>
<<Communicates>>
Salesman
Price Deal
<<include>>
Valuation
2.17. << EXTEND >> RELATIONSHIP 107
<<extend>> adds more info to allow the already com-

plete use case to extend its use (Stereotype)
2.18 Commentary
The notation for the relationship between use cases has

changed more than once. The current usage is dashed
line with open arraow-head. For <<extend>> the arrow
head is at the use case being extended. For <<include>>
the arrow head is at the included use case.
2.19. USE CASE DIAGRAMS 109
2.19 Use Case Diagrams
External actors outside the box representing current

system
Use cases for the system inside the box
Determine the functionality of the system as seen by

actors communicating to it
Communication association between actors and use cases
Generalisation relationship between use cases
Extend and Include relationship between use cases
Documentation property: textual documentation of func-

tionalities
Sequence, collaboration and activity diagrams associ-

ated with the use case diagram for information on flow
of events
Use case model package containing use cases and ac-

tors with relations among them.
2.20 Use Case Diagrams
Sales Statistics
Salesperson
Customer
Customer Statitics
2.21. EXAMPLE: UNIVERSITY COURSE REGISTRATION 111
2.21 Example: University Course Registration
Determine Actors:
– Names
– Documentations (brief descriptions – iterative)
Determine Use Cases
– Names
– Documentations (brief descriptions, and also docu-
mentation of the flow of events – iterative)
Determine Use Case Relationships
Draw Use Case Diagrams

2.22 Actors in University Course Registration
Actor names:
– Student
– Lecturer
– Registrar
– Billing System
Actor documentations (brief descriptions)
– Student: a person registered to take classes at the

University.
– Lecturer: a person who is certified to teach classes
at the University.
– Registrar: the person who is responsible for the
maintenance of the University Course Registration
System.
– Billing System: the external system responsible for
student billing.
2.23. ACTORS 113
2.23 Actors
Actor Student Actor Lecturer
Student Lecturer
Name; student Name: Lecturer
Documentation: a person registered Documentation: a person
to take classes at the University certified to teach at the
University
Actor Registrar Actor Billing System
Registrar Billing System

Name: Registrar Name: Billing System
Documentation: the person who is Documentation: System
responsible for maintenance of the responsible for billing
University Course Registration the students
2.24 Use Cases in University Course Registration
Use case names
Use case documentations
Use case events flow documentations
Use case relationships
Use case diagrams

2.25. USE CASE NAMES 115
2.25 Use Case Names
Register for courses
Select course to teach
Request course roster (time-table)
Maintain course information
Maintain lecturer information
Maintain student information
Create course catalogue
etc.
2.26 Use Cases
Register for Courses

Name: Register for Courses
Documentation: started by the student provides the capability to create,
delete, modify, and/or review a student schedule for a specified semester.
Request Course Roster

Maintain Course Information
Name: Request Course Roster
Name: Maintain Course Information
Documentation: .................
Documentation:.................
Select Course to Teach

Maintain Lecturer Information
Name: Select Course to Teach
Name: Maintain Lecturer Information
Documentation:......... Documentation:............................
Maintain Student Information Create Course Catalog

Name: Maintain Student Information Name: Create Course Catalog
Documentation:...................... Documentation: .....................
2.27. USE CASE DOCUMENTATIONS 117
2.27 Use Case Documentations
Register for courses: started by the Student; provides

the capability to create, delete, modify, and/or review a
student schedule for a specified semester.
....
2.28 Use Case Event Flow Documentations
....
Select course to teach:
– Preconditions:
– Main Flow:
If the activity selected is ADD, then S-1: Add a
Course Offering sub-flow is performed.
...
– Sub-flows:
S-1: Add a Course Offering ...
S-2: ...
– Alternative Flows:
E-1: An invalid lecturer ID number is entered.
The user can re-enter a lecturer id number or ter-
minate the use case.
E-2: ...
– ....
2.29. USE CASE RELATIONSHIPS 119
2.29 Use Case Relationships
Communication Association:
– Between an actor and a use case

– Uni-directional or bi-directional
– Uni-directional association shown by an arrow head
to the destination
Relationships between use cases:
– Include or extend
– Stick arrow head is put nearest to the use case that
is being used
– Stick arrow head is put next to the base use case
that is being extended.
– Include and extend are stereotype associations be-
tween use cases
2.30 Example Use Case Relationship
<<extend>>
<<Communicates>>
<<include>>
2.31. USE CASE DIAGRAMS IN COURSE REGISTRATION SYSTEM 121
2.31 Use Case Diagrams in Course Registration System
Main
– system boundary (actors)

– functionality (use cases)
– communication associations between actors and use
cases
– use case relationships (if any): generalisation
– <<include>> and <<extend>> relationships be-
tween use cases: to include or extend usecases
Additional use case diagrams:
– all the use cases for a selected actor

– all the use cases implemented in an iteration
– all the relationships (to actors and use cases) for a
use case
– etc.
2.32 Main Use Case Diagram
Register for Courses

Student
Billing System
Select Course to Teach
Lecturer
Maintain Student Information

Maintain Lecturer Information
Registrar Create Course Catalogue

Maintain Course Information
2.33. ADDITIONAL USE CASE DIAGRAM 123
2.33 Additional Use Case Diagram

Select Course to Teach Lecturer
<<include>> <<include>>
Validate User
2.34 Testing Use Cases
Validation: making sure that use case matches user

requirement, i.e., use cases are correctly specified.
– Walk-throughs with user to ensure that all the re-

quired use cases are there.
Verification: making sure that system built has the func-

tionality of the use case, i.e., use-cases are correctly
implemented.
– Every use case is implemented to produce the func-

tionality specified by it.
2.35. REALIZING USE CASES 125
2.35 Realizing Use Cases
A use case is realized in a collaboration. A collabo-

ration is an implementation of a use case in terms of
classes/objects and their relationships called its con-
text. The interactions in the collaboration achieve the
functionality of the use case.
A collaboration is represented as a number of diagrams

showing its context and interactions between them. The
context is made up of classes. The interactions are the
collaboration diagrams, sequence diagrams, and activ-
ity diagrams.
A scenario is an instance of a use case or a collaboration.

The scenario is a specific execution path (a specific
flow of events) that represents a specific instantiation
of the use case. Its external behaviour is an instance
of the use case. Its internal representation is the col-
laboration between the implementing classes/objects and
their interactions.
2.36 Commentary
Collaboration describes the sequence of class diagrams that

implement the corresponding use case.
2.37. SCENARIO 127
2.37 Scenario
Instance of a use case: one path in the flow of events for

use case
Scenarios help to determine objects, classes, object inter-

actions for a functionality specified by a use case
Primary scenario: normal flow
Secondary scenario: what-if cases
Two types of interaction diagrams for scenarios: Sequence

(time order), collaboration (object linkage order)
2.38 Use Case Realization: Collaboration
<<realizes>>
Use Case collaboration
<<implements>>
<<implements>>
<<implements>>
<<boundary>> <<control>> <<entity>>
Class A Class B Class C
Use case description
1. Actor Pushes button
2. Use case does action Oper1() Oper1() Oper1()
3. Use case responds to Oper2() Oper2() Oper2()
......
actor with message Oper3() Oper3() Oper3()
4. ... ..... ..... .....
2.39. USE CASE, COLLABORATION, SCENARIO 129
2.39 Use Case, Collaboration, Scenario
Perspective Model type Modelling language Model (document)

refers to describes a
Text in Description
Use Case natural
outside the of a Use
is a realization of a language Case
system
(implements)
Sequence
diagram
inside the Description
Collaboration Collaboration
system of an
(context and diagram
boundary interaction
interaction)
Activity
diagram
is an instance of a
May be illustrated
by one or more
is an instance of a
Sequence
diagram
Description
Collaboration
of a
An execution diagram
scenario
path through Scenario
Activity
the system diagram
2.40 Lecture 1 Exercises:
1. A Financial Trading System (FTS) is used by an ac-

counting system for updating accounts. It allows anal-
ysis of trading risks by traders. The trading manager
uses it to set limits on price deals. A trader arrives at
price deals after checking with the valuation service of
FTS. This valuation service is also used in the analy-
sis of trading risks. A sales person uses the price deal
to capture a deal with a trader. Capturing a deal may
sometime need previously set limits to be exceeded.
Give a use case model for the above problem show-
ing all the actors and use cases needed in a use case
diagram. Also show any stereotyped relationships be-
tween these use cases.
2. For a Place Order use case in a Sales system show

relationships to use cases Request Catalogue, Sup-
ply Customer Data Order Product Arrange Payment
with appropriate stereotype names <<extend>> and
<<include>>.
3. For a Telephone Catalogue System with external ac-

tors Customers, Salesperson, Shipping Clerk and Su-
pervisor draw a use case diagram for the use cases
Check Status, Place Order, Fill Orders and Establish
2.40. LECTURE 1 EXERCISES: 131
Credit.
4. Determine 5 actors and 7 use cases for an ECG Mon-

itoring System and draw a use case diagram show-
ing communication, <<include>> and <<extend>>
relationships. Give one typical course of events for
one action and one corresponding system response for
each of the actors.
5. Determine 6 use cases and 3 actors for your University

Library Lift System and draw a use case diagram show-
each of the actors.
6. Determine 5 use cases and 2 actors for a Cellular Tele-

phone System and draw a use case diagram show-
each of the actors.
7. Determine 5 actors and 4 use cases for a Credit Card

Validation System and draw a use case diagram show-
relationships. Also show any generalisation relation-
ships between the actors. Give one typical course of

events for one action and one corresponding system
response for each of the actors.
8. Determine 4 actors and 5 use cases for a Point Of Sale

System and draw a use case diagram showing com-
munication, <<include>> and <<extend>> relation-
ships. Give one typical course of events for one action
and one corresponding system response for each of
the actors.
9. Determine all the use cases and actors for a Formula

1 Race Information System. You might find it better to
divide the system into subsystems. For each of these
subsystems draw corresponding use case diagrams show-
relationships and any generalisation relationships be-
tween the actors. Give both the typical and alternative
courses of events for all the relevant actions and the
corresponding system responses.
10. Extend the use case analysis of exercise 9 above to in-

clude the functionalities of the Graphical User Interface
for the Formula 1 Race Information System.
Chapter 3
Lecture 2: Classes, Objects, Packages

and Corresponding Diagrams
133
134CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS
3.1 Static Modelling: Classes, Objects, Packages, Diagrams
Classes
Relationships
Class Diagrams
Interfaces
Instances
Objects
Object Diagrams
Packages
Package Diagrams
Inheritance
3.1. STATIC MODELLING: CLASSES, OBJECTS, PACKAGES, DIAGRAMS 135
3.1.1 Commentary
Aggregation and Association are class relationships; They

have multiplicities. Interfaces have operations only. In-
stances are objects. Object diagrams have objects and links,
no multiplicities. Package relationships are dependancies.
Inheritance relationships are generalisation/specialisation be-
tween classes.
3.2 Classes
Structure: static internal to Class
– Name
– attributes
– operations (behaviour)
– responsibilities (documenting specification)
Stereotypes
Templates
Example classes in a University Course Information Sys-

tem:
– LecturerCourseOptions
– AddACourseOffering
– Course
– CourseOffering
– LecturerCourseManager
– LecturerInformation
– StudentInformation
3.3. COMMENTARY: CLASS 137
3.3 Commentary: Class
CRC cards record Class Responsibility Collaboration infor-

mation for the class. Stereotype refers to a particular ap-
plication. Templates are parametrised classes. Lecture-
CourseOptions is a class giving course options for a par-
ticular lecturer. AddACourseOffering is a class that deals
with adding a new course for a Lecturer. Course is a class
representing the course. CourseOffering is a class that
deals with different parts of a course. LecturerCourseM-
anager is a class to manage courses offered by a lecturer.
LecturerInformation: class containing details of a team.
StudentInformation: class containing details of students.
Objects are items of a running system; objects get manip-
ulated during the run. Real objects are represented by sys-
tem objects. Class provides the type of its objects and de-
termines the characteristics of an object. Instantiation cre-
ates an object of the class. A variable is to type as an ob-
ject is to class. While type operations need no implemen-
tation class methods need implementations. Inheritance
simplifies class implementations in system development.
Problem domain Objects are realized by classes in the sys-
tem. System software classes are files, windows, icons, ...
Information system classes are customer, invoice, asset,
quote, ... Technical system classes are engine, sensor,

display, buttons, ...
3.4 Commentary: Finding classes
Domain experts help to determine classes in an applica-

tion. Class name should reflect domain object name. In-
formation needed to be stored, transformed or analysed
is represented by persistent classes (saved in a database).
Temporary classes are created as the program is started
and then lost when the program is terminated. External
systems with which the system needs to interact will be
classes in the system. For example Student class uses a
Registration System, so the Registration System will have
a Student class in it. Libraries, components and patterns
contain classes which will be used in a system. Devices
(e.g., Printer) a system needs to handle are classes in the
system. Organisational parts in a system are classes in the
system, e.g., Finance system. Roles played by actors give
classes in the system, e.g., user, operator, customer, etc.
Requirement specification document gives domain specific
classes (noun words).
3.5. COMMENTARY: CLASS NAME 139
3.5 Commentary: Class Name
The top component of a class is a unique identifier for the

class, should be in bold, starting with capital letter and a
singular name, a single word (no suffix or prefix), unam-
biguous, appropriate and reflecting domain object.
3.6 Commentary: Class Attributes
Describes object characteristics. Determined by system

requirements. Types must be specified whether primitive
or class. Visibility may be given (+: public, -: private,
#: protected) or assumed public when not shown. At-
tribute values are assigned at object creation. Every class
scope attribute (static in Java) has the same value for all
the objects of the class; shown underlined in the diagram.
Enumeration type is shown by a property-string: {..,..}.
Syntax for attribute:
visibility name: type-expression = initial-

value {property-string}
Property-string is used to show the persistence of the at-

tribute. Attributes are elided if not needed for the particular
context.
3.7. COMMENTARY: OPERATIONS 141
3.7 Commentary: Operations
Class has operations that manipulate its attributes and per-

form other operations on its objects. Operations are some-
times referred to as functions; can be applied onto its own
objects only. May have return types. Operation names may
be overloaded; parameters differentiating between them.
Parameters have types and may have default values. Op-
erations are applied to an object of a class by calling it
from that object. Operations hold the services offered by
the class; they form the interface of the class. Visibility
and scope of operations in a class may be restricted as for
attributes. Static operations are referred to as class-scope
operations, as they apply to all the instances of the class.
They may be called directly using class name and without
creating any instances. Class-scope operations can ac-
cess only class-scope attributes of the class. Class-scope
operations carry out generic operations of the class e.g.,
creating objects, finding objects, etc.
Operation syntax:
visibility name (parameter-list): return type-

exp {property-string}
name: type-exp=default-value
Default values of parameters are as supplied in class def-

inition. Operations are implemented by methods; methods
are NOT operations. Operations are specified (in the doc-
umentation file) using pre-conditions, post-conditions, algo-
rithms, and effects on objects. Pre-conditions are condi-
tions that must be true before the operations can be ap-
plied. Post-conditions are conditions that must be true af-
ter the operations has been completed. Operation proper-
ties are documented in a file which are accessible via tools.
Persistent classes will have their objects stored in files so
that they may be accessed even after the program has fin-
ished. Class-scope operations of a persistent class per-
forms the storing and retrieval of objects; such operations
may be: store(), load(), create()... Persistent
class operations are shown by persistent tagged values.
3.8. COMMENTARY: TYPE 143
3.8 Commentary: Type
Type-exp of attributes, operations and parameters may be

primitive or class name. Primitive type operations are al-
ready implemented, cannot change these implementations.
Class type operations must be implemented by methods be-
fore use. Primitive type attributes hold values while class
type attributes hold references.
3.9 Example Structure of Class Course
Class Course Attributes:
– courseName
– courseDescription
– creditHours
Class Course Operations
– getOffering()
– addLecturer()
– validLecturer(lecturerID)
Course
courseName
courseDescription
creditHours
getOffering()
addLecturer()
validLecturer(lecturerID)
3.10. COMMENTARY 145
3.10 Commentary
class structure gives information on and behaviour of ob-

jects belonging to it. A class hasname, attributes and op-
erations. getOffering() gets course offerings for the
course, addLecturer() adds lecturer for the course. validLecture
checks that the lecturer for the course is correct.
3.11 Creating Operations
From interaction diagrams, e.g., from Sequence Dia-

gram for Select Course to Teach / Add to a Course Of-
fering:
– getOffering() in CourseOffering
– getOffering(Course) in LecturerCourseManager, Course
– setLecturer(LecturerInformation, CourseOffering) in
LecturerCourseManager
– addLecturer(LecturerInformation, CourseOffering) in
Course
– addLecturer(LecturerInformation) in CourseOffering
– validateLecturer(LecturerInformation) in Course
Independently (e.g., to help another operation)

3.12 Commentary
Sequence diagrams for use-cases determine the class op-

erations (methods).
3.13 Example: Car Class Details
Car Class
Car Class with attributes
Car Class with attributes and their types
Car Class with attributes, their types and their visibility

(+: public, -: private, #: protected); if not shown visibility
is still defined.
Car Class with attributes (types, visibilities) and opera-

tions (parameters, return types, visibilities)
3.14. EXAMPLE CLASS: CLASS CAR 149
3.14 Example Class: Class Car
Car
Car registrationNumber
data
speed
direction
Car Car
registrationNumber: String + registrationNumber: String
data: CarData - data: CarData
speed: Integer + speed: Integer
direction: Direction + direction: Direction
Car
+ registrationNumber: String
- data: CarData
+ speed: Integer
+ direction: Direction
+ drive(speed: Integer, direction: Direction)
+ getData(): CarData
3.15 Example: Invoice Class Details
Invoice Class with attributes, their types, visibilities, de-

fault values and class-scope attribute (number of in-
voices). This last attribute has the same value for all
object instances of Invoice class.
Enumeration types may be used for attribute types (e.g.,

Status = {unpaid, paid} in the attribute status).
Invoice
+ amount: Real
+ date: Date = currentDate
+ customer: String
+ specification: String
- administrator: String = "Unspecified"
-number of invoices: Integer
+ status: Status = unpaid{unpaid, paid}
3.16 Commentary
Class scope or static attributes are underlined; all object in-

stances will have the same value for the static attribute.
{unpaid, paid} means enumerated type.
3.17 Documenting Attributes & Operations
Example: Course Class
Attribute Documentation:
– documentation for name:

The title of the course that is used in all University
Publications.
– ....
Operation Documentation:
– documentation for addLecturer(LecturerInformation,

CourseOffering) operation:
Add a Lecturer as the teacher of a particular course
offering of the course
Input: Lecturer and course offering
Output: success indicator
– ...
3.18. EXAMPLE CLASS DIAGRAM: CLASS DOCUMENTATION 153
3.18 Example Class Diagram: Class Documentation
Student Information
Documentation:
Information needed to
register and bill students.
A student is some one who
is registered to take classes
at the University
3.19 Stereotype Classes
Entity classes: noun phrases to accomplish responsibil-

ities; domain classes
Boundary classes: handle communications between ac-

tors and use cases interfaces
Control classes: handle sequencing in use cases
<<Entity>> <<Entity>>
LecturerInformation
CourseOffering
(from People) (from UniversityArtifacts)
<<Boundary>> <<Control>>
LecturerCourseOptions LecturerCourseManager
(from Interfaces) (from UniversityArtifacts)
Boundary Control Entity

Class Class Class
3.20. ENTITY CLASS: STUDENTINFORMATION CLASS & SPECIFICATION 155
3.20 Entity Class: StudentInformation Class & Specification
<<Entity>>
Student Information
Specification:
Name: StudentInformation
Type: class
Stereotype: Entity
Export control: Public
Documentation: Information needed to register and bill

students. A student is one who is registered to take
classes at the University.
3.21 Template Example: Class Instantiation by name and by Refine-

ment
Array<Car,100>
T, n:Integer
Array
<<bind>> <Colour,50>
ColourArray
3.22 Commentary
Parametrized class: class name passed as a parameter

(along with other parameters) in the template to get the
real class. Only real class may be used. NOT Java equiva-
lent, only in C++. The top class gives implicit implementa-
tion using parameters Car and 100. Explicit binding using
dependency relationship shown in the bottom diagram.
3.23 Class Relationships
Association
Dependency
Specialisation, Generalisation
Packaging
Refinement, Realisation
3.24 Commentary
Association is a connection between classes. A link is an

instance of an association: Objects are connected by links.
3.25 Association
Association
– Bidirectional semantic connection between classes.
Navigable Association
– Unidirectional semantic: Arrowhead shows direc-

tion of navigation
Aggregation
– One class is a part of another
Example Association: LecturerCourseManager & Course
LecturerCourseManager Course
3.26 Commentary
Associations are bidirectional each object being aware of

the other. Arrow at one end of the line implies navigable
in that direction only. One class can use another class but
not the other way round.
3.27 Naming Relationships
A relationship is named to give
– meaning
– association name
– role name
Example:
– Association name: manages

– LecturerCourseManager manages Course
LecturerCourseManager manages Course

3.28 Commentary
Bidirection (default) association has names in both direc-

tions (indicated by the arrow associated with the name).
Unidirectional association has name in only one direction.
These names reflect the relationship in the problem do-
main (e.g., verb words in the problem spec).
3.29 Multiplicity Indicators
Exactly 1: 1
Zero or more: 0..*
One or more: 1..*
Zero or one: 0..1
Specific range (5,6,7,8): 5..8
Combination (4,5,6,7,9): 4..7,9
Example:
Person Car
1..* Owns 0..*
Owned by
3.30 Commentary
Default multiplicity is 1.
3.31 Association Role Name at one end
One class in the association given role name.
– Example Association between CourseOffering (from

UniversityArtifacts) and LecturerInformation with role
name ”Teacher information” at LecturerInformation
end of the association:
LecturerInformation CourseOffering
Teacher
Information (from UniversityArtifacts)
3.32 Commentary
Roles are attached to the association line at one or both

ends. Role names describe particular roles of the classes
at their ends.
3.33 Association Role Name at both ends
Both classes in the association given role name.
– Example Association between Car and Person As-

sociation name “drives” (or “driven by”), Role name
“company car”
driver drives 0..*

Person Car
driven by company
Car
3.34. NAVIGABLE ASSOCIATION 169
3.34 Navigable Association
Example: A person may have 0 or more cars, but there

is no information about how many persons can own a
car.
Owns 0..*
Person Car
Useful in Specification and Implementation diagrams

3.35 Aggregation
Example Aggregation: CourseOffering being part of

Course
Course CourseOffering
3.36 Commentary
Aggregation is a special form of association: stronger form.

Whole-part relationship, e.g., “consists of”, “is part of”, “has
a”, “contains”. Referred to as normal aggregation. Parts
may be shared by more than one aggregate relationship,
so parts may remain even after an aggregate whole has
died. Name, direction, multiplicities, roles, navigation as in
association.
3.37 Shared Aggregation
Component may belong to more than one aggregate
Example: Shared aggregation between several Teams

and Persons; a person belonging to more than one
team
0..*
Team 0..*
Person
Members
3.38. COMPOSITION AGGREGATION 173
3.38 Composition Aggregation
Stronger variety of Aggregation
Part object may belong to only one whole object
Parts live and die with the whole object
Any deletion of whole cascades down to parts
The multiplicity on the whole side must be 0 or one (0..1),

but the multiplicity on the part side may be any interval
(0..*)
A composition Aggregation forms a tree of parts.
3 Notations: one solid diamond for each part, or one

solid diamond as root of the tree of parts, or all parts
inside the whole class
3.39 Commentary
Special type of aggregation where the parts are contained

wholly in only one class; so when the container class dies
all the parts must die as well.Only one role name - at the
parts end.
3.40. COMPOSITION AGGREGATION: ONE SOLID DIAMOND FOR EACH PART 175
3.40 Composition Aggregation: One solid Diamond for each Part
0..*
Text
0..*
LicstBox
Window
Button
0..*
Menu
0..*
3.41 Composition Aggregation: One solid diamond and Parts tree
0..*
Text
0..*
ListBox
Window
0..*
Button
0..* Menu
3.42. COMPOSITION AGGREGATION: PARTS INSIDE WHOLE CLASS 177
3.42 Composition Aggregation: Parts inside whole class
Window
*
Text
*
LicstBox
*
Button
*
Menu
3.43 Composition Aggregation: Two or more parts
A
B
B:X X
C
C:X
A
0..
z[0..]:Z z Z
3.44. QUALIFIED ASSOCIATION 179
3.44 Qualified Association
Qualifier used to distinguish among the set of objects

in the many end of the association.
Example Qualified Association: Canvas & Figure
0..*
Canvas figure id Figure
3.45 Commentary
Makes a single 1 to many relationship into many 1 to 1 re-

lationships, by distinguishing each association by a quali-
fier id. This will then make it possible to identify an object
uniquely by giving the qualifier id of the association. Can
subset the objects at many end into groups each group be-
ing associated to a qualifying group id at the 1 end. This
converts a 1 to many relationship into many 1 to many re-
lationships. In the figure example, figure id will identify a
unique figure or a group of figures depending on whether
the qualifier is for each object or each group of objects.
3.46. OR-ASSOCIATION 181
3.46 Or-Association
Mutually exclusive association, one or the other but not

both
Dashed line labelled “or” between the alternatives
Example Or-Association: Insurance Contract & Person

or Company
Insurance Insurance
Company 1 0..* Contract
0..* 0..*
or
1..* 1..*
Person Company
3.47 Commentary
Association with one or the other possible classes. Group-

ing into choice classes. Exclusive or.
3.48. ORDERED ASSOCIATION 183
3.48 Ordered Association
When multiplicity more than 1 ordered constraint is used

if ordering of the association is desired (list instead of
set, which is the default)
Labelled: {ordered}
Example: Insurance Contract & Customer
Insurance 0..* {ordered} 1..*

Contract Customer
3.49 Commentary
Ordered at the many end of an association. Order needs

to be preserved when new objects are added. Ordering
criterion (and whether increasing or descending) needs to
be specified . Default is no order, i.e., new object added at
the end of a list.
3.50. REFLEXIVE RELATIONSHIPS: RECURSIVE ASSOCIATION 185
3.50 Reflexive Relationships: Recursive Association
Multiple objects belonging to the same class communi-

cate with each other:
*
Node
*
3.51 Commentary
* means 0 or more.
3.52. RECURSIVE ASSOCIATION 187
3.52 Recursive Association
Semantic connection between many objects of the same

class
Node1 Node2 Node3
Node4
Node5
Node7
Node6 Node8
3.53 Commentary
Objects of the class linked to each other by links; there may

be one or more links to the same object.
3.54. RECURSIVE ASSOCIATION OF COURSES & PREREQUISITES 189
3.54 Recursive Association of Courses & Prerequisites
Association between LecturerCourseManager and Course
Association name: manages
Multiplicity at LecturerCourseManager: 1
Multiplicity at Course: 1
Reflexive Association between the objects of Course
Association role name: Pre-requisite
Multiplicity 0..* at both ends
LecturerCourseManager manages Course

1 1
Pre-requisites
0..*
0..*
3.55 Commentary
For each course there may be 0 or more pre-requisite courses.

3.56. ASSOCIATION CLASS 191
3.56 Association Class
Association with attributes and operations.
Example:
– Association between Person and Company

– Association class: Employment holding date person
was employed by company
– Dashed line to association line
1..* 0..1
Person Company
employer
Employment
period: dateRange
Association Class
3.57 Commentary
Association relationship between classes may itself have

attributes and operations and so may be regarded as a
class: association class. Examples: Employment, Loan.
Loan attributes: book name, borrower name, return date,
etc.; Loan operations: extendLoan(), cancelLoan(), etc.
3.58. TERNARY ASSOCIATION 193
3.58 Ternary Association
Association between three classes
Diamond
May have association class connected at one corner of

the diamond
Example: Association between Insurance Contract, Per-

son, Insurance Policy
Insurance Company 1 0..* Insurance Contract

insurer
0..*
Insurance Policy
0..1
1..* policyHolder
Person
3.59 Commentary
Three class relationship. Example: Doctor, patient, drug.

No qualifier allowed in ternary association; Can have asso-
ciation class, e.g., Treatment (patient, doctor, drug, date;
startTreatment(), postponeTreatment(),..).
3.60. CLASS DIAGRAMS 195
3.60 Class Diagrams
static structure of classes in subsystems of a system
class relationships
internal structure of classes:

3.61 Commentary
Class diagram gives a static view of a system in terms of

its classes and relationships among them.
3.62. EXAMPLE: A CLASS DIAGRAM TO MODEL AN INSURANCE BUSINESS 197
3.62 Example: A class diagram to model an Insurance Business
One Insurance company has many Insurance contracts

(0..*)
An insurance Customer has many Insurance contracts

(0..*)
An Insurance contract is related to one Insurance com-

pany (1)
An Insurance contract is related to one or more insur-

ance Customers (1..*)
Insurance
company 1 0..* Insurance
contract
0..*
1..*
Customer
3.63 Commentary
An object collaboration diagram for Order Processing. The

order is entered andeach order line is processd by deliv-
ering the item if in stock and reordering if not in stock or
iforder level reaches reorder limit.
3.64. EXAMPLE CLASS DIAGRAM: ORDER 199
3.64 Example Class Diagram: Order
:Order Entry Window

1:prepare()
:Order
2 *[for all order lines]:prepare()
3:hasStock()=check() 5:needsReorder:=
4 [hasStock]:remove() needToReorder()
:Order Line :Stock Item
7[hasStock]:new 6 [needsReorder]:new
:Delivery Item :Reorder Item

3.65 Commentary
Navigable from an order to the customer credit rating. Cus-

tomer credit rating is checked only for a given order. Can-
not find order from a customer credit rating.
3.66. EXAMPLE: ORDER WITH NAVIGABILITY 201
3.66 Example: Order with navigability
Order contains a pointer to Customer, and Order line a

pointer to Product
Order Customer
dateReceived name
isPrepaid 0..* 1
address
number: String
price: Money
dispatch() creditRating(): String
close()
1 {if Order.customer.creditRatring
is "poor", then Order: isPrepaid
must be true}
line
items 0..* Personal
Corporate Customer
Customer
OrderLine contactName
creditCard#
creditRating
quantity: Integer
creditLimit remind
price: Money
isSatisfied: Boolean billForMonth(Integer)
0..*
sales rep 0..1 {creditRating() = "poor"}
0..*
Employee
1
Product
.
3.67 Object Diagram
object instances
snapshot of class diagram
Labelled rectangle with object name underlined
Example Object Diagram:
Algebra 101, Section 1

3.68. EXAMPLE OBJECT DIAGRAM WITH ROLES 203
3.68 Example Object Diagram with Roles
p1/lead: Point
x = 3.14
y = 2.718
lead: Point
p2/lead, tail: Point

tail: Point
x=1
y = 1.414
roles objects
3.68.1 Commentary
Object instances connected by links. Instance of the cor-

responding class diagram. No multiplicities. Underlined
class name and object name; class name may be elided;
anonymous object name possible Separator between ob-
ject and class names: “:”.
Roles are parts of collaborations. They are represented like

classes with role name followed by colon followed by type.
Not underlined. Instances are underlined and shown with
optional name, followed by optional slash, followed by list of
roles, colon and list of types.
3.69. EXAMPLE CLASS DIAGRAM: OBJECT DIAGRAM (BOB’S COMPUTER) 205
3.69 Example Class Diagram: Object Diagram (Bob’s Computer)
Author Computer
Use
name: String
name: String
age: Integer memory: Integer
0..* 1..*
Bob: Author Bob’sPC: Computer

name = "Bob J."
age = 32 name = "Dell 456"
memory = 64
3.69.1 Commentary
Object diagram is an instance of a class diagram

3.70. INTERFACES 207
3.70 Interfaces
Storable
Class A Class B
Runnable
<<interface>>
Runnable
{abstract}
Runnable
run(){abstract}
<<interface>>
Storable Class C
{abstract}
load(){abstract}
save(){abstract}
Class A supplies (realises) interfaces Storable & Runnable
Class C supplies (realises) interface Runnable
Class B uses (depends on) Storable & Runnable interfaces
provided by Classes A & C
3.70.1 Commentary
Interface: a collection of operations used to specify a ser-

vice of an abstraction. Each operation will have pre-conditions
and post-conditions. Also there will be invariants unaf-
fected by each operation. OCL can be used to specify the
semantics of interfaces. State machines may be used to de-
termine legal partial ordering of an interface’s operations.
Collaborations will determine the expected behaviour of an
interface. Interface implemented by a class. The objects of
an implementing class will have methods that provide the
operations in the interface. An implementing class may re-
alize more than one interface. Also one or more interfaces
of a class may be used by different roles which will have
some of the interface operations. Different roles corre-
spond to different selection of interfaces supported by the
class. There may be many implementations of the same
interface. Objects use interfaces which have been imple-
mented. Dependency relationship between the interface
user object and the interface. <<interface>> stereo-
typed class with operation used shown explicitly instead
of lollipop icon. Generalisation / specialisation diagram with
<<interface>> stereotyped class is used to include in-
terface hierarchy.
3.71. PACKAGES: EXAMPLE 209
3.71 Packages: Example
Interfaces with classes
UniversityArtefacts with classes
People with classes:
People
Semantically related grouping
Owned by package: import
No instantiation; no aggregation/association
Dependency & inheritance: Yes
Visibility of components
3.72 Commentary
Semantically related grouping of classes, interfaces, com-

ponents, nodes, diagrams, etc. No instantiation of a pack-
age. Packages related by dependency, refinement, or gen-
eralisation. Visibility of package elements from outside a
package can be controlled. Package contents are owned
by the package, and cannot be in another package. Pack-
age name unique: simple or path name (showing packages
containing it) with optional tags, e.g., Client::OrderForm
(fully qualified name of the element OrderForm in the pack-
age Client). Elements of one package can be imported
by another package by referring to the package contain-
ing it. Package contents are like composite aggregates
of the package. Different kinds of elements in a pack-
age can have the same name. Contents of another pack-
age is imported by reference: shared aggregation; compo-
nents belonging to one package used by another by shar-
ing. Visibility defaults to public being accessible from an-
other package element provide the latter imports it. Pri-
vate elements not visible outside the package. Visibility
symbols: +:public, -:private, #:protected. Friend
package can import and access everything from another
package. <<import>> stereotype adorns the dependency
relationship (dashed line with arrow, the arrow pointing to

the package imported). Import requires no qualified name,
the source name space being visible to the importer. How-
ever, to avoid name clash qualified name is used. <<access>>
is a similar stereotype which allows importation but always
requires qualified name. Thepublic parts of a package are
visible only to the contents of the package. They are called
its exports. To use them outside a package they must be
imported by the user. Both import and access are not
transitive. If A imports B and B imports C, it does not fol-
low that C is imported by A. Packages may be contained
in other packages - nesting. All elements visible in a pack-
age are visible from packages nested in it. No import is
necessary. Generalisation/ specialisation relationship be-
tween packages form super-package, sub-package hierar-
chy. Protected elements of a package accessible by im-
porting only from its sub-packages. A sub-package may
be used wherever its super-package is used.
5 Standard package stereotypes:
1. facade: Package which is aview of another package.
2. framework: Package of patterns.
3. stub: Package that serves as a proxy for the public

contents of another package.
4. subsystem: Package that forms an independent part

of a bigger system
5. system: Package that represents the whole system.

3.73. PACKAGE CLASSES: EXAMPLE 213
3.73 Package Classes: Example
Package Interfaces:
– LecturerCourseOptions
– AddACourseOffering
Package UniversityArtifacts:
– Course
– CourseOffering
– LecturerCourseManager
Package People:
– LecturerInformation
– StudentInformation
3.74 Package Classes: Example
(from UniversityArtifacts) (from UniversityArtifacts)
LecturerCourseManager
(from UniversityArtifacts)
3.75. EXAMPLE PACKAGES: CLASS DEPENDENCE ON PACKAGE INTERFACE 215
3.75 Example Packages: Class Dependence on Package Interface
Class P Class S
B
D
C
3.76 Package Relationships
Dependency relationship
Dashed line
Arrow at the dependent package
Example Package Relation:
– From Package: Interfaces

– To Package: UniversityArtefacts
– Relationship: One or more classes in Interfaces ini-
tiates communication with one or more public classes
in UniversityArtefacts (e.g., AddACourseOffering class
of Interfaces sends a message to LecturerCourse-
Manager class of UniversityArtefacts)
3.77 Commentary
Package dependency rlationship has two standard stereo-

types: <<access>> and <<import>>. <<access>> refers
to granting of permission for one package to reference the
public elements owned by another package (subject to vis-
ibility). <<import>> refers to granting of permission for
one package to reference the public elements of another
package and to adding the names of the public elements of
the supplier package to the client package.
3.78 Example Packages: Subsystem Dependence
SubSystemA
SubSystemB SubSystemC
SubSystemE
SubSystemD
3.79. EXAMPLE PACKAGES: SUBSYSTEM IMPORTING 219
3.79 Example Packages: Subsystem Importing
B W::Z
3.80 Example Packages: Subsystem Generalisation and Dependence
SubSystemA
SubSystemB SubSystemC
SubSystemD SubSystemE
3.81. GENERALISATION (INHERITANCE) RELATIONSHIPS 221
3.81 Generalisation (Inheritance) Relationships
Example User Information in University Course Informa-

tion System:
Parent: UserInformation
Child1: LecturerInformation
Child2: StudentInformation
UserInformation
LecturerInformation StudentInformation
3.82 Commentary
A subclass inherits attributes, operations and associations

from its superclass. Usually further information is added
to the subclass. An instance of a subclass can be used in-
stead of an instance of its superclass. Inheritance is a class
(type) relationship not object relationship. A subclass ob-
ject inherits a superclass object characteristics through the
inheritance relationship between the subclass and the super-
class. Public superclass operations and attributes inherited
remain public in the subclass. Private superclass opera-
tions and attributes inherited remain private in the subclass
and so inaccessible to the subclass. Protected superclass
operations and attributes remain protected and so accessi-
ble to the subclass. UML uses - for private, + for public and
# for protected. A class in a hierarchy may be a superclass
and a subclass.
3.83. EXAMPLE: VEHICLES 223
3.83 Example: Vehicles
Parent: Vehicle
Child1: Car
Child2: Boat
Child3: Truck
Vehicle
Car Boat Truck

3.84 Inheritance Relationship: Vehicle Tree
Vehicle
Car Boat Truck

3.85. INHERITANCE RELATIONSHIP: VEHICLE HIERARCHY 225
3.85 Inheritance Relationship: Vehicle Hierarchy
Vehicle
Car Boat
Sports Sailing Motor Cargo

Truck Estate
Car Boat Boat Ship
3.86 Inheritance Relationship: Vehicle abstract, with abstract ops.
Vehicle {abstract}
drive() {abstract}
Car Boat
drive() drive()
drive() starts the wheel drive() starts the prpeller

3.87 Commentary
An abstract class cannot have any objects or instances,

but it can have subclasses which may be abstract or con-
crete. UML uses tag {abstract} below the name in the
name compartment of the class. Also the name is given
in italic. An abstract class has normally abstract oper-
ations. An abstract operation has only signature but no
implementing method in the class where the operation is
specified. In UML an abstract operations name is given in
italic and its signature is followed by the tag {abstract}.
A class with at least one abstract operation must be an
abstract class. The abstract operations are implemented in
subclasses. Thus drive() abstract operation of vehicle is
implemented in its subclasses car, boat, truck. Concrete
classes can be instantiated into objects. All their opera-
tions have implementations in the class. However these
operations may be redefined in its subclasses, though their
signatures must remain the same. All instances of a sub-
class will use the operations (with their new definitions if
changed). Subclasses allow new attributes, operations
and associations to be added to those inherited from the
superclass. This possibility of using newly defined meth-
ods in subclasses for the operation inherited from the su-
perclass is called polymorphism. Discriminators specify

the basis for inheritance, e.g., the characteristics inherited.
For example vehicles may be subclassed on the basis of
methods used for propulsion or on the basis of number of
wheels. Java uses extend to create subclass.
3.88. INHERITANCE RELATIONSHIP: PERSON ASSOC. DRIVE WITH VEHICLE 229
3.88 Inheritance Relationship: Person assoc. drive with Vehicle
*
Vehicle {abstract}
drives colour
Person
drive() {abstract}
Car Boat
drive()
drive()
drive() starts the wheel drive() starts the prpeller

3.89 Example: Hierarchy with attribs. and assocs. for children
– Attributes:
tenureStatus
name
IDNumber
– Association:
Association: to CourseOffering
Multiplicity at LecturerInformation: 1
Multiplicity at CourseOffering: 0..4
Role at LecturerInformation: Teacher Information
– Attributes:
major
name
IDNumber
– Association: to CourseOffering
Multiplicity at StudentInformation: 3..10
3.90. INHERITANCE RELATIONSHIP WITH CLASS ATTRIBS. AND ASSOCS. 231
3.90 Inheritance Relationship with class attribs. and assocs.
UserInformation
Lecturer Information StudentInformation

major
tenureStatus name
name IDNumber
IDNumber
1 3..10
Teacher
Information
0..4 0..4
CourseOffering
3.91 Example: Hierarchy with relocated attribs. and opers.
– Attributes:
name
IDNumber
– Attributes:
tenureStatus
– Association:
Association: to CourseOffering
Multiplicity at LecturerInformation: 1
Role at LecturerInformation: Teacher Information
– Attributes:
major
– Association: to CourseOffering
Multiplicity at StudentInformation: 3..10
3.92. INHERITANCE RELATIONSHIP WITH REALLOCATED ATTRIBS. AND OPS. 233
3.92 Inheritance Relationship with reallocated attribs. and ops.
UserInformation
name
IDNumber
tenureStatus major
1 3..10
Teacher
Information
0..4 0..4
CourseOffering
3.93 Inheritance vs Aggregations
Inheritance to separate commonality from specifics
Aggregation to show composite relationships
Example:
– Parent: UserInformation
Attributes:
name
IDNumber
– Child1: LecturerInformation
Attributes:
tenureStatus
– Child2: StudentInformation
Attributes:
major
Aggregation: to Classification
Multiplicity at StudentInformation: 0..*
Multiplicity at Classification: 1
3.94. EXAMPLE: INHERITANCE VS AGGREGATE CONTD. 235
3.94 Example: Inheritance vs Aggregate Contd.
Classification hierarchy:
– Parent: Classification
Attributes:
maxCourseLoad
– Child1: Fulltime
Attributes:
gradYear
– Child2: Parttime
Attributes:
yearsInAttendance
3.95 Inheritance vs Aggregation
UserInformation
name
IDNumber
Lecturer Student
Information Classification
Information
tenureStatus maxCourseLoad
1
major 0..*
Fulltime Parttime
gradYear yearsInAttendance
3.96. CONSTRAINT GENERALISATIONS: INHERITANCE CONSTRAINTS 237
3.96 Constraint Generalisations: Inheritance Constraints
4 types of constraints on generalisations:
complete,
disjoint,
incomplete,
overlapping.
Class A
{constraint 1, constraint 2,...}
Class B Class C Class D

3.97 Constraint Generalisations: Alternative Inheritance Constraints
Class A
{constraint 1, constraint 2,...}
Class B Class C Class D

3.98. CLASS DIAGRAMS: OVERLAPPING 239
3.98 Class Diagrams: Overlapping
Vehicle
Propulsion Propulsion
{overlapping}
Car Boat
Amphibian
Can have multiple inheritance with a common super-

class.
NOT Java
Default: not overlapping

3.99 Disjoint Generalisation
Vehicle
Four-wheeled Two-wheeled
{disjoint}
Car Mototor-Cycle
Sports Car Moped
Can NOT have multiple inheritance with a common su-

perclass.
Default
3.100. COMPLETE GENERALISATION: NO OTHER SUB-CLASS 241
3.100 Complete Generalisation: No other Sub-class
Person
{complete}
Man Woman
Can NOT have any further subclasses at that level.
Default: incomplete; can add

3.101 Dependency Relationship
<<friend>>
Class A Class B
Stereotype of dependency could be other than “friend”.
Java Package scope access
Parameter class
Importing from a package
Accessing global object of another class
Calling class scope operations of another class
Class level NOT Object level

3.102. REFINEMENT RELATIONSHIP 243
3.102 Refinement Relationship
Refinement ) Realisation
Analysis Class Design Class
Type Class
Use Case Collaboration
B A
B modifies to A
A does what B promises
B (input), A (result)
A refinement of B (A refines B)
3.103 Commentary
Refinement is a relationship between two abstraction lev-

els, e.g., design class is a refinement of the corresponding
analysis class. Class refines Type. Collaboration refines
use cases. Refinement is same as realization. So Design
class realizes Analysis class, Class realizes type and col-
laboration realizes use case.
3.104. DERIVED ASSOCIATION 245
3.104 Derived Association
Receipt
0..1
is expressed in
1
Car Hire has Hire refers to Rental Car
Company 1 0..*Contract {abstract}
0..1
0..* {disjoint}
Kind of car
signs
1
Customer Sports Car Truck Saloon

*
/VIP Customers
3.105 Commentary
Derived attribute is denoted by /derived attribute name,

e.g., /age, /VIP Customer.
3.106. CONSTRAINT ASSOCIATION 247
3.106 Constraint Association
Member of 1
1..*
Politician {subset} Party
1
Party leader of 1
Or-association
f orderedg
f overlappingg, fdisjointg, fcompleteg
constraint on attribute property list: enumerated

3.107 Commentary
A constrained association may be shown as a {subset},

e.g.: Association Party leader of is a {subset} of
the association Member of.
3.108. CONSTRAINT ATTRIBUTE 249
3.108 Constraint Attribute
Invoice
+amount: Real
+date: Date = Current date
+customer: String
+specification: String
-administrator: String = "Unspecified"
-number of invoices: Integer
+status: Status = unpaid{unpaid, paid}
3.109 Commentary
Static attribute number of invoices is updated auto-

matically as each invoice object is created. Enumerated
type value range is given as a property-list,
3.110. DERIVED ATTRIBUTE 251
3.110 Derived Attribute
Article
costPrice
salesPrice
/profit
{profit = salesPrice - costPrice}
OCL expresses UML constraints syntax and semantics

3.111 Commentary
UML uses OCL to express constraints. /profit is the

derived attibute. Derivation formula is shown at the bot-
tom of the class diagram. Derived attributes are always
calculated and never read from previously stored values.
1. Draw a class for each of the following:
(a) name: Shape, attribute: origin, operations: move(),

resize() and display();
(b) name: CourseOffering, attribute: location, op-
erations: getOfferings() and addLecturer().
(c) name: LecturerCourseManager, attributes: lecturerName
and courseCode, operations: getOfferings()
and setOfferings().
2. For a class with the following structure:
name: Figure,
attributes: size of class Size, pos of class Position,
figCounter of type Integer and of class scope, x
and y both of Integer type and of default value 0
with private visibility,
operations: draw() with public visibility, getCounter()
returning Integer value and of class scope, scaleFigure
of public visibility and with an Integer parameter percent
defaulted to 25, reSize of public visibility and with
2 Integer parameters percentX and percentY both
defaulted to 25, returnPos() of class Position
and of public visibility,
show classes for each of the following:
(a) Figure class with attributes and operations along

with their signatures and return types (if any) that
describe the size, position and count of the figure
drawn;
(b) Figure class with attributes and operations along
with their signatures, return types (if any) and visi-
bilities that describe the scaled figure drawn;
(c) Figure class with attributes and operations along
with their signature, return types (if any) and visibil-
ities that describe the resized figure drawn;
(d) Figure class with attributes and operations with
signatures and visibilities that describe the persis-
tent storing of the figure drawn.
3. Give a specification for each of the following stereo-

typed classes:
(a) Entry Class Course;

(b) Entity Class CourseOffering;
(c) Entity Class LecturerInformation;
(d) Entity Class LecturerCourseOptions;
(e) Boundary Class AddACourseOffering;
(f) Control Class LecturerCourseManager.
4. Show qualified association between an Order with sev-

eral Products each with 0 or 1 Order Line.
5. Show the “married to” relationship on a Person with

“husband” and “wife” roles as a reflexive association.
6. Assuming that a Lecturer teaches at most 4 Course-

Offerings and that a CourseOffering is taught by only
1 Lecturer draw a class diagram to show the associa-
tion between the Lecturer and CourseOffering classes
including muliplicities and suitable role names.
7. Draw a class diagram showing aggregation relation-

ship between the classes Remix and SoundClips such
that a Remix may contain 0 or more ordered sound
clips and a sound clip may belong to 0 or more Remix.
8. In the class diagram of Fig. 1 give the UML names for

the model elements labelled (a), (b), and (c):
9. Draw a class diagram to model an Insurance Business

with the following class relationships:
An insurance company has insurance contracts which

refer to 1 or more customers
A customer has insurance contracts (zero or more),
which refer to one insurance company.
An insurance contract is between an insurance com-
<<Boundary>>
name (b)
attributes
operations
(a) (c)
Figure 3.1: Class Diagram
pany and one or more customers. The insurance

contract refers to both a customer (or customers)
and an insurance company
The insurance contract is expressed in an (zero or
more) insurance policy (a written contract of insur-
ance)
The insurance policy refers to the insurance con-
tract.
10. For the Motor Race Information System draw the main
Class diagrams giving appropriate class attributes, op-
erations and specifications and making appropriate use
of association, dependency and generalisation relation-

ships between between the classes. Also give appro-
priate package diagrams.
Lecture 3: Sequences, Collaborations, Activities, States,

and corresponding Diagrams Ananda Amatya
3.113. SEQUENCES, COLLABORATIONS, ACTIVITIES, STATES AND DIAGRAMS 259
3.113 Sequences, Collaborations, Activities, States and Diagrams
Sequence Diagrams
Collaboration Diagrams
Activity Diagrams
State Diagrams
3.114 Commentary
Interaction diagrams describe object behaviour in interac-

tions between objects in a running system. They provide
the dynamic modelling in analysis and design (both what &
how) of the system by describing how objects cooperate
to manage tasks performed by the system. These tasks
achieve the system services (use cases)for its users. Com-
munication between objects in the system takes place in
the form of message passing between them. Message pass-
ing amounts to operation calls by objects. This will cause
state changes of the calling object and the called object.
A sequence diagram describes how different objects send

and receive messages as time progresses in an orderly
manner in order to provide a system service to the user.
As a consequence of an object receiving a message an
activity takes place causing other messages to be sent to
other objects causing a chain of events to take place in sub-
sequent times. The result of such a chain of events occur-
ring is a particular task to be performed by the system for
the user. A sequence diagram describes this sequence of
events to do the work required for achieving the user task.
A collaboration diagram describes the chain of activities

as objects interact with each other. The emphasis is on

the message passing links between objects, and the order
in which these links are established. What is important
is the object context, i.e., which link is established next.
So while sequence diagram emphasises the sequence of
events, collaboration diagram emphasises the object link-
age sequence.
An activity diagram describes the successive activities that

take place when the system performs a user service. This
flow of activities is done by interactions between the ob-
jects in the system. The order of these activities describes
the sort of actions that objects do to accomplish the user
service. A bit like flow chart showing the sequence of ac-
tivities.
A state diagram describes the different possible states of

an object during its life time and how transitions take place
from one state to another due to events that occur. For
example, an invoice object will go from an unpaid state to
a paid state when the payment event takes place.
Depending on the application some interaction diagrams

are more useful than others. Sequence and Collaboration
diagrams are semantically equivalent. AlsoState and Activ-
ity diagrams are related the former being concerned with
sequence of events and the latter with sequence of activ-

ities. The purpose of dynamic modelling is to study the
runtime behaviour of the system from the point of view of
the messages being passed between objects to achieve
the services (use cases) and to ensure that the static model
class diagram has this behaviour. This has the effect of
refining the static model by including new classes and re-
moving or changing classes that were introduced in earlier
iterations on purely structural grounds. Study of interac-
tions between objects in dynamic models determine the
class operations more precisely. Due to the many system
services (use cases) there may be many dynamic models
that all correspond to the same static model.
3.115. SEQUENCE DIAGRAMS 263
3.115 Sequence Diagrams
Time ordering of flow of control in object interactions

for a particular scenario (an instance of a use case);
Initial objects involved at the top, horizontally (under-

lined Class names), more important objects to the left;
Created objects shown horizontally at creation time;
Objects destroyed indicated by a cross at the time it

ceases to exist;
Sequence of messages between objects shown by hori-

zontal lines (sending and receiving) with arrows;
Message activation in an object shown by a vertical

thin rectangle with a start and finish (Focus of Control);
Arrows show source and destination of message, and

whether synchronous, asynchronous or return;
Time flows vertically downwards: events flow sequence

top to bottom
3.116 Sequence Diagrams Cont’d.
Generic form shows several scenarios in the same dia-

gram by using guards, branches and loops in the mes-
sages ([...], *); clutter??
Instance form shows a particular scenario with no branches,

guards or loops; too many??
Returned messages may optionally be shown by dashed

lines with solid arrow heads;
Concurrently running objects are shown by activations,

asynchronous messages and active objects in parallel;
Labels are used for timing marks, iterations, descrip-

tions of actions, constraints, etc.;
Recursions are shown by message loop to the same

object;
Dynamic modelling of system behaviour using several

sequence diagrams (a package): primary (main flow)
& secondary (sub-flows and exceptions).
3.117. EXAMPLE: PRINTER SERVICE 265
3.117 Example: Printer Service
:Computer :Queue
:Printer- :Printer
Server
Registrar
1: Print (file)
anonymous
2: Print(file) object
3.1: [printer free] Print (file)

Message
branch
condition
life line
GENERIC
Message Numbering Optional
Activation Return
Return Message Not Always shown
Synchronous Messages
3.118 Example: Use of Label for Time Constraint
:Computer :Printer- :Printer :Queue

Server
Registrar
1: Print (file)
a
{b-a <5} 2: Print(file)
b
{c-b<1}
c 3.1: [printer free] Print (file)
Timing constraint:
Message must be sent within the time interval
e.g., Print Server must respond within 5 secs.
3.119. EXAMPLE: USE OF LABEL FOR ITERATION 267
3.119 Example: Use of Label for Iteration
C1:C D1:D D2:D
Registrar
op1()
{send op2()
message
op2 op3()
until...}
Iteration controlled by timing constraint:

messages op2() sent repeatedly until time expires
3.120 Example: Recursion
oper() objectName:Class
oper()
recursion
activation
Activation
self
delegation
when exit condition satisfied

3.121. EXAMPLE: CREATING A COURSE 269
3.121 Example: Creating a Course
courseForm theManager aCourse

:CourseForm :CurriculumManager : Course
Registrar
object
name &
1:set Course type
info
2:process
3:add course
4:new course
Return messages elided

3.122 Example: Add a Course Offering
:Lecturer :AddACourse :Lecturer CS223: :Course

CourseOptionsOffering CourseManager Course Offering
Lecturer
1:enter a password
2:verify password
3:enter term
4:addAOffering5:display
6:select cs223 7:getOfferings
8:getOfferings
9:getOfferings
10:displayOfferings
11:selectOffering
12:setOffering
13:addLecturer
14:addLecturer
self delegation
3.123. EXAMPLE: ORDER SEQUENCE 271
3.123 Example: Order Sequence
an order entry an order an order line stock item

window
object name
prepare() * [for all order lines] class elided
prepare() hasStock:=check()
[hasStock]
remove()
needReorder:=
needsToReorder()
<<create>> object
iteration [needsReorder] creation
new() a reorderitem
<<create>>
[hasStock]new() a deliveryitem
return
activations elided; some returns elided; <<create>> stereotype

iteration: e.g., prepare() message sent for each of the order line object
Task:
if in stock supply it for delivery; check if stock needs replensishing,
if so order (reorder); iterate throug all order lines
3.124 Example: Transaction Sequence
new
new
a Transaction
object
new a Transaction creation
Coordinator
<<create>>
new a first
<<create>> transaction
checker
a second
new transaction
<<create>>
checker
stop & ok
<<destroy>>
resume
all
activation done?
ok
<<destroy>>
all
be valid done?
object destruction
asynchronous
3.125. EXAMPLE: TRANSACTION CHECK 273
3.125 Example: Transaction Check
transaction
created
new
new
a Transaction
<<create>>
transaction new a Transaction
coordinator Coordinator
created <<create>>
new a first
Coordinator transaction
creates first <<create>>
checker
checker a second
Coordinator new transaction
<<create>>
creates second checker
checker fail
first checker <<destroy>>
fails checkers
all checkers
killed <<destroy>>
Transaction be invalid
informed
of invalid
checks
Optional Comments
3.126 Commentary
Time is shown vertically downwards. Objects are shown

horizontally to the right. An instance form of sequence di-
agram corresponds to a scenario. Messages passed (syn-
chronous/ asynchronous) and received are shown between
objects as time passes. Generic form using conditions,
loops, branches and recursion describe many related sce-
narios. Many sequence diagrams are needed to describe
all the possible flows of controls. This is its weak point
(cf. collaboration diagram). An object needs to remain ac-
tive only when doing the work or waiting for a result from
another object. This is shown by its activation (thin ver-
tical rectangle). Sequence number of messages can be
determined or shown if desired. Objects may be created
or destroyed during the service (shown by new and dele-
tion) or be present throughout. Message lines have ar-
rows (synchronous/asynchronous). Dotted message lines
are used for message returns. Returns (and less relevant
lines) may be elided to improve readability. Labels are used
for conditions, timing constraints, loops, descriptions of ac-
tions, message name and signature. Comments to describe
the sequence of events are usually given on the left or the
right. Concurrent message passing can be handled.
3.127. COLLABORATION DIAGRAM 275
3.127 Collaboration Diagram
Focussed on Object linkage
Used to show how objects interact during an operation
Used to show how a particular use case is realized
Messages passed between objects along the linkages

are labelled
Shows the network of objects and their linkages in a

scenario.
3.128 Commentary
Semantically equivalent to Sequence diagrams, but difficult

to show concurrency and asynchronous messages. Ob-
ject context is brought out clearly (cf. sequence diagram).
Sequence labels must be present to show the sequence of
links. Sequence numbering shows nesting.
3.129. MESSAGE FLOW: MESSAGE LABEL SYNTAX 277
3.129 Message Flow: message label syntax
Message label syntax:
predecessor guard-condition sequence-expression

return-value := signature
e.g.: 1.1a, 1.1b / [mode = evaluate] 1.2 *[z:=1..
Predecessor is specified as :
sequence-number ’,’ ... ’/’

e.g.: 1.1a, 1.1b /
Predecessor specifies the sequence numbers (separated

by commas) of messages that must be performed be-
fore the current message is sent. This determines the
sequence (not the time) and is used to synchronize
threads.
3.130 Message Flow: message label syntax (cont’d.)
Guard-condition:
’[’ condition-clause ’]’
e.g.: [mode = evaluate]
Sequence-expression:
[integer | name] [recurrence] ’:’
e.g.: 2 *[n := 1..z]:
[integer | name]
e.g.: 1.2.3.7:
1.1a, 1.1b/1.2:
[recurrence]
conditional: ’[’ condition-clause ’]’
e.g.: [x<0]
iteration: ’*’ ’[’ iteration-clause ’]’
e.g.: *[x=1..10] (
Return-value := Signature:
return-value := signature
eg.g.: x := calc(n)
prim := nextPrim(prim)
3.131. LINKS 279
3.131 Links
Role names at objects
Qualifier: Id to associate 1 or more of “many end” with

1 of the “qualified end”
Stereotypes: global (variable scope), local (within an

operation), parameter (within an operation), self, vote
(majority vote of the returned values), broadcast (mes-
sage order immaterial)
Instance of Association
3.132 Lifetime of Object
Creation of object: new
Killing an object: destroyed
Created and Killed during the same collaboration: tran-

sient
3.133. EXAMPLE: PRINT SERVICE 281
3.133 Example: Print Service
print (file) :Computer
Registrar
object
1: Print(file)
message
:PrinterServer
sequence no.
[printer free]
2:Print(file)
condition
:Printer
print(file) message from Computer to PrinterServer

If Printer free print(file) message to Printer from PrinterServer
3.134 Example: Iteration and Return value
calcPrime(n) :Calculator
1*[z:=1..n]:prime:=nextPrime(prime)
iterator
:Prime module
Repeatedly send nextPrime to the PrimeModule from

Calculator until number of primes becomes n
3.135. EXAMPLE: ELEVATOR - CALLING A LIFT BY PRESSING A BUTTON 283
3.135 Example: Elevator - Calling a Lift by pressing a button
push() :Button
1:getElevator(floorid)
:elevator
:order {new} 1.2: <<create>>
control
job
{local}nextjob {parameter} job

1.1 *[allqueues]: len:=length() {broadcast}
1.3:invoke(job)
done
concurrently
2:nextjob=GetJob() :Queue
:Elevator
active object (own thread: concurrent)

3.136 Example: Elevator - Explanation
1. push() Button sends getElevator(toAppropriateFloor) mes-

sage to the elevatorControl
1.1 elevatorControl repeatedly checks all Queues (of jobs)

to find shortest job queue
1.2 creates a new job for the getElevator message
1.3 Invokes next job in the Queue to be done
2. Elevator works concurrently to do the next Job in the

Queue
3.137. EXAMPLE: SUMMARISING SALES RESULT 285
3.137 Example: Summarising Sales Result
1:show()
:Sales Statistics
Window
1.1: <<create>> 1.2 *[while any lines left]:

GetResultLine()
:Statistics :order
Summary
{new} 1.1.1.1 *[for all orders]:
GetOrderAmount()
1.1.1 *[for all salespersons]:
ordersum=GetTotalOrderSum()
:SalesPerson
1.1.2 *[for all salespersons]:
budget=GetBudget()
1.1.2.1:GetBudgetAmount()
:Budget Sales
3.138 Example: Sales Result Explanation
1. show() SalesStatisticsWindow
1.1 Create() sales StatisticsSummary

1.1.1 Get total sales for all SalesPersons
1.1.1.1 Get each SalesPerson total
1.1.2 Get BudgetSales for all SalesPersons
1.1.2.1 Get each SalesPerson Budget
1.2 Read all results from StatisticSummaryLineByLine
to display
3.139. EXAMPLE: ADD A STUDENT 287
3.139 Example: Add A Student
1: new student
sof:StudentOptionsForm
3: enter student info

Registrar 2: display
sf:StudentForm
4: new student
5: save
successFlag
s:Student
3.140 Example: Add A Student Explanation
1. create new student in StudentOptiosForm
2. display StudentForm
3. enter new student info
4. create new student record
5. save in Student database

3.141. EXAMPLE: ADD A COURSE OFFERING 289
3.141 Example: Add a Course Offering
1: add a course
cof:CourseOfferingForm
3: select course offering

Lecturer
2: display
cf: CourseForm
4: add lecturer (id)
5: get lecturer (id)

c: Course
6: add lecturer (lecturer)
co: CourseOffering
3.142 Example: Add Course Offering Explanation
1. add a course for the Lecturer in CourseOfferingForm
2. display CourseForm
3. select course offering
4. select add lecturer option for Course
5. get lecturer id for Course
6. add lecturer to CourseOffering

3.143. EXAMPLE: CREATE A COURSE 291
3.143 Example: Create A Course
1: set course info

cf:CourseForm
2: process
Registrat
3:addCourse
cm:CurriculumMananger
4:newCourse
c:Course
3.144 Example: Create A Course Explanation
1. set course info in CourseForm
2. process CourseForm
3. add Course to CurriculumManager
4. create the new Course

3.145. EXAMPLE: ORDERS WITH SIMPLE NUMBERING 293
3.145 Example: Orders with Simple Numbering
:Order Entry Window

1:prepare()
:Order
2 *[for all order lines]:prepare()
3:hasStock()=check() 5:needsReorder:=
4 [hasStock]:remove() needToReorder()
:Order Line :Stock Item
7[hasStock]:new 6 [needsReorder]:new
:Delivery Item :Reorder Item

3.146 Example: Orders Simple Numbering Explanation
1. prepare order (for processing)
2. do prepare for all order lines
3. check if each order line in stock
4. if so remove it from stock for delivery
5. check if reordering needed
6. if so reorder
7. deliver item
3.147. ACTIVITY DIAGRAMS 295
3.147 Activity Diagrams
Actions and their Results (outcomes) as they are per-

formed in a particular scenario
Activities to implement operations, objects, use case

instances
Action states and their transitions under the actions
Swim-lanes for grouping activities by responsibility
Interaction diagram
3.148 Commentary
Activity diagrams show actions and their results. These

help in implementing methods for the class operations. Ac-
tivity diagrams are useful to show the activities in a use
case scenario. Related to state diagrams. Action states
are used. Transition from one action state to another takes
place automatically when the action in the action state fin-
ishes. Duality: control flows from Object to Object in In-
teraction diagrams while it flows from Activity to Activity in
Activity (& State) diagrams.
3.149. TRANSITIONS 297
3.149 Transitions
Event attached only to the transition from start to first

Action state.
Arrow show the transition direction and may be labelled

with guard-condition, send-clause and an action-expression.
If nothing is specified the transition takes place when
the activities in the action state is performed.
Parallel actions: concurrent activities
Objects may be attached to action states
Signals may be sent or received

3.150 Commentary
There are no events in the links between action states. The

start state is a pseudo-state. There may be an event in
the link between it and the first action state. There may be
guards, send-clauses and action expressions attached to the
links. When no link label is present, as soon as the “from”
action state finishes the “to” action state starts. Guard con-
ditions on the links may stop this happening. Decisions
(“diamond-shaped” symbol) are controlled by guards.
3.151. ACTIVITY DIAGRAM: CONCURRENT ACTIONS 299
3.151 Activity Diagram: Concurrent actions
Sampler.Run(channel, frequency)
Initiate
(fork)
synchronisation bar Updating Measuring

displayer
(join)
must combine before exiting
3.152 Commentary
Following a fork at a transition, parallell actions may take

place concurrently. All the parallel transitions must be per-
formed before they join again. Bold horizontal lines are
used to show forking and joining.
3.153. ACTIVITY DIAGRAM: SWIM LANES 301
3.153 Activity Diagram: Swim Lanes
Displayer Sampler
Initiate
Measuring
Updating
displayer
swim lanes
3.154 Commentary
Swim lanes show action states of the same object. All the
activities in the same swim lane refer to the same object.
3.155. ACTIVITY DIAGRAM: USING OBJECTS WITH ACTIVITY DIAGRAM 303
3.155 Activity Diagram: Using Objects with Activity Diagram
Displayer Sampler
Initiate
Updating Measured
Measuring
displayer value
Object
Object sent to Updating displayer action by Measuring action
3.156 Commentary
Objects input to or output from actions can be shown in

activity diagrams. Shows which objects are affected by
the actions; e.g., Printer action state will affect the Printer
object.
3.157. ACTIVITY DIAGRAM: PASSING SIGNALS IN ACTIVITY DIAGRAM 305
3.157 Activity Diagram: Passing Signals in Activity Diagram
Postscript Creator Printer

CustomerWindow.PrintAllCustomers()
Show
MessageBox aPrinter
"Printing" :Printer
on screen
Create
postscript Print
file
Print(file) Print(file)
Print Signal
Remove
Message Box
Signal to send Print file from

postscript createor to printer
3.158 Commentary
Signals may be sent or received in an activity diagram. Send-

clause is attached to the transition that sends a signal. Sim-
ilarly receive signals may be attached to transitions that re-
ceive the signal. Convex pentagon is used for send symbol
and concave pentagon for receive symbol. Dashed arrow
line connects the send and receive symbols.
3.159. ACTIVITY DIAGRAM: RECEIVING AN ORDER 307
3.159 Activity Diagram: Receiving An Order
Receive
Order
multiple
trigger
*[for each line

item on order]
Cancel Authorize Check
Order [failed] Payment LineItem
[in stock]
[succeeded]
Assign to
Order
[stock assigned to
all line items and
payment authorized]
[need to order]
Reorder
Dispatch Item
synchronisation Order
condition
3.160 Activity Diagram: Receiving A Supply
Receive
Supply
Choosing
Outstanding multiple trigger
Order Items
*[for each chosen order]
Assign
Goods to
Order
[stock assigned
to all line items and [all outstanding
payment authorized] order items filled]
Dispatch Add
Order Remainder
to Stock
3.161. ACTIVITY DIAGRAM: SWIM LANE FOR ORDER PROCESSING 309
3.161 Activity Diagram: Swim Lane for Order Processing
Finance Receive Order Processing Stock Manager

Order
*[for each line
item on order] Receive
[failed] Supply
Authorize Check
Payment LineItem
Cancel
Order
[in stock] Choosing
Outstanding
Assign to Order Items
[succeeded] Order
*[for each chosen order]
[need to order] Assign
Goods to
Reorder Order
Item
[stock assigned to
all line items and
[all outstanding
payment authorized] order items filled]
Dispatch Add
Remainder
Order
to Stock
Process receieved order and received reordered stock
3.162 Activity Diagram: Decomposing Activity Diagram
[credit card] Determine

payment type
[cheque] [invoice]
failed
[failed] Clear Regular Value
[no] [yes]
Cheque Customer? of Order
>$1,000?
[OK] [yes]
[failed] [no]
Request
Authorize Check [failed] Pre- [not receivd]
Credit Payment Payment
Card history
failed
[OK] [failed]
Credit
[OK]
Check
Open
Customer
[OK]
succeeded Account
Complex method using activity diagram (algorithm flow chart!)
3.163 Commentary
Activity diagrams are useful to express algorithmic steps

for a complex operation (flow-chart).
3.164 State
Name
State Variable
Activities:
event-name argument-list ’/’ action-expression
Standard event names: entry, exit, do
Name
State Variables
Activities
Describes object life-cycle

3.165 Commentary
State diagrams capture the life cycles of objects, subsys-

tems and systems.Transitions from one state to another in
a state diagram are due to events (e.g., message received,
time elapsed, errors, conditions being true). All classes
whose objects change over time will have state diagrams
which show such state changes. The attributes and links
(to other objects) of an object determine the state of the ob-
ject. There may be a special attribute to record the state of
the object. Alternatively no such attribute may be present
and the values of other attributes are used to determine the
state of the object. Example: salesman status (true/false);
invoice (paid/unpaid); car (stationary/moving), engine (run-
ning/stalled), marital status (married/unmarried). Event:
something happens(car started, invoice paid, gets mar-
ried). Events cause internal state changes. Initial state is
starting point. End point when the object dies. Entry spec-
ifies action on entry of the state (assigning an attribute,
sending a message); exit specifies action performed on
the exit from a state; do specifies action performed while in
the state.
3.166 State Activities
Login
Login time=currentTime
entry/type "login"
exit/login(userName, password)
do/get userName
do/get password
help/display help
entry: done on entry

do: do during
exit: on exit
3.167 Commentary
Action-expression: action to be performed, e.g., operation

calls that increment attribute values. Events may take argu-
ments (entry, exit, do take no arguments). Triggerless
transitions have no event between two states in the state
diagram; state change occurring when the internal actions
in a state is completed. When all the actions in a state are
performed a transition without an external event will auto-
matically be triggered. Action-expressions follow the “/” in
state diagrams.
3.168 State Transitions without Events
Boot Starting OS
do/run bios program do/load OS
triggerless transition
Starting Application
do/load applications
3.169. TRANSITIONS 317
3.169 Transitions
Syntax for State Transition:
event-signature ’[’ guard-condition ’]’ ’/’

action-expression ’send’ send-clause
Event signature: event name with comma separated

parameters in parentheses:
event-name ’(’ parameter ’,’ ...’)’

e.g.: draw (f: Figure, c: Colour)
Guard condition within square brackets, ’[’ and ’]’:
e.g.: [balance >= amount]
Action expression preceded by ’/’;
e.g.: increase () / n := n+1 / m := m+1
Send clause preceded by send, may have a destination

expression followed by ’.’ and the destination event
name with comma separated argument list in paren-
theses:
’send’ destination-expression ’.’

destination-event-name ’(’ argument ’,’ ...’)’
e.g.: send self.go down (first floor)
Syntax for parameter:
Parameter-name ’:’ type-expression,

Parameter-name ’:’ type-expression ...
3.170 Commentary
Transitions are shown by lines with arrow heads between

states. Event causing the transition shown on the transition
line. Transition is said to be “fired” or “triggered” by the
event. If no state attached to the transition it is “triggerless”.
State transition with only an action-expression: /flash.
3.171 Events for a transition: 4 kinds
Guard Condition: Condition becoming true;
Event Signature: Receipt of an explicit signal from an-

other object (message);
Event Signature: Receipt of a call on an operation by

another object (or by the object itself (message));
Passage of a designated period of time.

3.172. STATE DIAGRAMS 321
3.172 State Diagrams
State: object state and behaviour, life of object
Transition: change from one state to another
Event: causes State Transition
Start (always exists, may not be shown)
Stop (optional)
3.173 Example State Diagram: Invoice
invoice created Unpaid

paying
Paid
invoice
destroying
3.174. EXAMPLE STATES: COURSEOFFERING 323
3.174 Example States: CourseOffering
Initialisation (Activity: do: Initialise CourseOffering

data)
Cancelled
Open (Activities: entry: registerStudent; exit:

send CourseReport.addStudent(student))
Closed (Activity: do: Finalise Course; exit: send Cours-

eReport.create Report)
3.175 Example Transition: Add Student/Set Count=0
Event Signature: addStudent from Initialization to Open
Guard Condition:
Action Expression: setCount = 0
Send Clause: send CourseReport.createReport

3.176 Commentary
Send-clause: send message to another object during state

transition. Destination object and event sent are shown.
Destination object may be the object itself self. Exam-
ple send-clauses:
send CourseReport.createReport()
[timer=Time-out] send self.goDown(firstfloor)
out-of-paper() send indicator.light()
leftMouseButtonDown(location)/color:=
pickColor(location) send pen.set(color)
3.177 Example Transitions: CourseOffering
Add Student from Open to Open
– Event Signature: addStudent

– Guard Condition: Count < 10
Cancel from Open to Cancelled
– Event Signature: Cancel from Open to Cancelled
Cancel from Closed to Cancelled
– Event Signature: Cancel from Closed to Cancelled
from Open to Closed
– Guard Condition: Count = 10
from Cancelled to Stop
– Send Clause: send CourseReport.delete
from Start to Initialisation
from Closed to Stop

3.178. EXAMPLE STATE DIAGRAM: COURSEOFFERING 327
3.178 Example State Diagram: CourseOffering
Initialisation
do:Initialise
CourseOffering data
add student/set count = 0
add student [Count < 10]
Open
entry: Register Student

exit: send
CourseReport.
addStudent (student)
[Count=10]
cancel course
Cancelled Closed
cancel course do: Finalise course
do: send exit: send
cancellation notices
Course Report.
Create Report
<<send>>
CourseReport.delete
3.179 Sending message between State Diagrams
Dashed arrowed line between objects enclosing substates.

The Event signatures of the transitions in the two ob-
jects must match
Dashed line from transitions between states of an ob-

ject to the box enclosing its sub-states with correspond-
ing event signatures.
Sub-states may be or-substates (disjoint) or and-substates

(concurrent)
History indicator will allow resumption of activities held

in its memory.
3.180. SENDING MESSAGES TO STATES 329
3.180 Sending Messages to States
Remote Control
on()
Off On
off()
play() stop()
on() off() play() stop()
CD Player
on() play()
Off On/Play
On/Stop
off() stop()
off()/stop()
3.181 Commentary
Remote control on() will trigger the on() on the CD-Player.

Similarly for off(), play() and stop().
3.182. SIGNALS & STATES 331
3.182 Signals & States
The signal could be an object of the following classes:

<<signal>>
Input Keyboard, Left Mouse Button, Right Mouse Button
{abstract} and Voice Recognition
device: Device
time: Time Send
Input
Idle
do/send(input) to
corresponding class
<<signal>> <<signal>> <<signal>>

Mouse Keyboard VoiceRecognition
{abstract}
up: Boolean character: Char commando: String
down: Boolean up: Boolean
xPos: Int down: Boolean
yPos: Int
<<signal>> <<signal>>
Left Mouse Button Right Mouse Button
signal hierarchy
3.183 Or State
Running
Forward Backward
3.184. AND STATE 333
3.184 And State
Running
Forward Backward
Low Speed High speed

3.185 Install State
Install
OS running restart()
create()
Restart OS
send Self.Restart()
Install
Start Install shield
entry/ask installing
questions
H
do/Install software
[alternative=try again]
[alternative=continue]
out of memory()
disc error()
Memory Error
Disk Error
entry/fix disk entry/show question dialog
do/show question dialog
do/ask alternative
dp/ask alternative
[alternative=stop]
Internal state is remembered by History state and is
returned to when resumed after interruption
3.186. ORDER PROCESSING 335
3.186 Order Processing
/get first item
[Not all items checked]/ Checking

get netxt item
do/check item
[All items checked &&

all items available]
Dispatching some items not in stock]
do/initiate delivery
Items received [all items available]
Delivered
Delivered Waiting
Items Received[some items not in stock]

3.187 Order Processing with Cancellation
/get first item
[Not all items checked]/ Checking

get netxt item
do/check item

all items available] cancel
Dispatching some items not in stock]
cancel
Delivered
Cancelled cancel
Delivered Waiting
Items Received[some items not in stock]

3.188. ORDER PROCESSING WITH SUPERSTATE 337
3.188 Order Processing with SuperState
/get first item
[Not all items checked]/ Checking Active

get netxt item
do/check item
all items available]
some items not in stock]
Dispatching
Items Received
[Some items not Waiting
in stock]
Delivered
cancel
Delivered Cancelled
3.189 Authorising Order
Authorising
do/check
[payment not OK]
payment
[payment OK]
Authorised Rejected
Delivered
3.190. CONCURRENT STATES IN ORDER PROCESSING 339
3.190 Concurrent States in Order Processing
canelled
Waiting
Cancelled
Checking Dispatching
Delivered
Authorising Authorised
Rejected
1. Draw a sequence diagram to show the sequence of

event that occur when change(CustomerData) mes-
sage is passed to a CustomerWindow which in turn
passes the message updateCustomer(CustomerData)
to Customer Return message should be shown by a
simple arrow back to CustomerWindow.
2. Modify the sequence diagram in Exercise 1 above for

the message newCustomer(Data) to CustomerWindow
which causes a message Customer(Data) to be passed
to create a new Customer.
3. Modify the sequence diagram in Exercise 1 above for

the message removeCustomer() to CustomerWindow
which causes a message deleteCustomer() to be
passed to delete a Customer.
4. Draw a collaboration digram to show message passing

between MainWindow, CustomerWindow and Customer
to create of new customer data and to update(Data)
existing customer data.
5. For the collaboration diagram example on Orders with

Simple Numbering renumber the message sequence
using Dewy decimal numbers.
6. Draw an activity diagram to make cups of coffee using

the following activities:
(a) Find Coffee,

(b) Put Coffee in filter,
(c) Add water in Reservoir,
(d) Get cups,
(e) Put Filter in Machine,
(f) Turn on Machine,
(g) Brew Coffee,
(h) Pour Coffee into cup,
the following guard conditions:
(a) [found coffee]

(b) [no coffee]
(c) [coffeePot light goes out]
and the send-clause:
(a) send coffeePot.TurnOn.
7. The activity diagram in Fig. 2 specifies the algorithm of

the operation intersection() of the class Line. Its
signature includes one parameter l of class Length
and one return value of class Point. The class Line
has two attributes of interest slope (giving the slope of
the line) and delta (giving the offset of the line relative
to the origin). Give the corresponding Java implemen-
tation for intersection().
[slope=l.slope]
return
Point(0,0)
else
x=(l.delta-delta)/(slope-l.slope);
y=(slope*x)+delta;
return
Point(x,y)
Figure 3.2: Intersection Operation
8. For the state diagram in Fig. 1 describe all the 6 state

transitions giving for each case its event signature, guard
condition, action expression and send clauses, if any.
go up (floor) Moving up
On first floor
do/moving to floor
arrived
go up (floor)
Idle
Moving down timer=0
arrived
do/moving to floor
do/increase timer
go down (floor)
[timer=time-out]/go down (first floor)
Figure 3.3: Lift State Diagram
9. Draw a state diagram for a digital watch which has

a modeButton() operation to select display (to display
current time), setHours (to set hours), or setMinutes
(to set minute) and another operation inc() which incre-
ments hours by 1 modulo 24 and minutes by 1 modulo
60. The setHours and setMinutes modes should re-
spectively display hours and minutes.
10. For the Motor Race Information System draw the rel-
evant Sequential, Collaboration, Activity and State Di-

agrams to give the dynamic models that capture the
behaviour of the system.
Lecture 4: Components, Deployment, Collaborations, Pat-

terns, Frameworks Ananda Amatya
3.192 Components, Deployment, Patterns, Frameworks
Architectural Views
Logical Views
Components
Processes
Deployment
Collaborations
Patterns and Frameworks

3.193. ARCHITECTURAL VIEWS 347
3.193 Architectural Views
Design View
(Logical) Implementation View
structure (Component)
behaviour system assembly
configuration
manage,ment
Use-Case View
functionalities
system services
actors
Process View
(Concurrency) Deployment View
threads system topology
processes distribution
performance delivery
scaling installation
throughput
3.194 Logical View
Addresses functional requirements (System services

for user)
Logical architecture: class diagrams: classes & rela-

tionships
Determined at elaboration phase: classes & packages
Key mechanisms: tactical design
– implementation language
– database
– GUI
– error handling
– communication mechanism
– object distribution & migration
– networking
3.195. LOGICAL VIEW OF PACKAGE IN COURSE REGISTRATION 349
3.195 Logical View of Package in Course Registration
Interfaces
University Artifacts
GUI Controls
People
Databases
Foundations (Fc: global)
Error Handling (global)

3.196 Logical View of Package in Course Registration
Interfaces UniversityArtifacts People
GUI Controls
Database
ErrorHandling Foundations
3.197. COMPONENT VIEW & DIAGRAMS 351
3.197 Component View & Diagrams
Physical (codes that reside in a deployment node);
Implementation of logical Classes, Interfaces and Col-

laborations;
Mapping from logical view to component view;
Dependencies between components via interfaces;
Realises or conforms to a set of interfaces;
Packages of components;
Replaceable (better component);
Component-based operating System facilities for build-

ing physical systems using components: COM+, En-
terprise Java Beans, Object Libraries;
Example Components:
– executables (executable codes)

– libraries (binary codes)
– tables
– files (source codes)
– documents
3.198 Component Name, Tagged Value, Realized Interfaces
Agent.java FraudAgent.dll
Realizes
FraudAgent
FraudPolicy
PatternSearch
System::dialog.dll
{version=2.0.1.75}
3.199. COMPONENT AND CLASSES 353
3.199 Component and Classes
FraudAgent.dll
FraudAgent FraudPolicy PatternSearch
Classes
Classes (logical, conceptual) have direct access to oper-

ations (and attributes);
Components (Physical, resides in nodes) access opera-

tions via interfaces;
Components implement classes & collaborations.

3.200 Components and Interfaces
Army.java SecretAgent.java
Decoder
realization
dependency
Army.java SecretAgent.java
<<interface>>
Decoder
breakCode()
3.201. COMPONENTS AND INTERFACES CONT’D. 355
3.201 Components and Interfaces Cont’d.
Interfaces contain operations to specify class/component

services and to bind them into physical implementa-
tions of systems;
Components are built to realise the interfaces (export

interfaces)
Components are built to conform to interfaces in order

to use component services through them (import inter-
faces);
The same interface may act as export interface for one

component and an import interface for another compo-
nent;
The same component may import many interfaces and

export many others;
Binding components must ensure that all the import in-

terfaces areprovided by the exported interfaces.
3.202 Binary Replaceability
Assembly of a physical system from binary replaceable

parts;
Physical system evolution amounts to adding and re-

placing such parts without the need for rebuilding;
Interfaces for new services provided by components are

used to extend the system
3.203. KINDS OF COMPONENTS 357
3.203 Kinds of Components
3 kinds of components:
Deployment components: executables (.dll, .exe)
Workproduct components: source code files, data files
Execution components: COM+ objects

3.204 Component View of Package in Course Registration
Interfaces
University Artifacts
Databases
Foundations
Error Handling
Interfaces UniversityArtifacts ErrorHandling
Foundations Databases
3.205. SOFTWARE COMPONENTS OF UNIVERSITY CLASS 359
3.205 Software Components of University Class
Course
CourseOffering
UserInformation
LecturerInformation
StudentInformation
UserInformation
3.206 Process View of Lecturer Executables
Physical architecture of hardware & software in the Sys-

tem
Computers, devices (nodes), connections
Connection types
Executable software inside nodes
Component dependencies
Processes and Threads (Active classes)
Performance, Scaling, Throughput (non-functional)

3.207. PROCESS VIEW OF LECTURER EXECUTABLES 361
3.207 Process View of Lecturer Executables
Lecturer.exe
Course.dll
Database.dll
LecturerCourseOption
LecturerInformation
AddACourseOffering
Course.dll Lecturer.exe Database.dll
LecturerInformation AddACourseOffering
LecturerCourseOption
3.208 Deployment View of Course Registration
Registration (Lecturer.exe)
Database Server
Dorm (student.exe)
Main Building (student.exe)
Library (student.exe)
Registration DatabaseServer Dorm
lecturer.exe student.exe
Library
Main Building
student.exe
student.exe
3.209. COLLABORATION 363
3.209 Collaboration
Conceptual (not physical) model building blocks
Realises operations, use-cases and other classifiers (classes,

interfaces, ...)
Represented by dashed oval
Collaborations are named
Refers to static structures and dynamic interactions that

are used for the realisations.
collaborations use design patterns (common solutions

to common problems in a context)
Resilient to change in design: use design patterns
Common mechanisms (design patterns in classes) are

represented as collaborations
Several collaborations can work together and one col-

laboration may be refined to another
Inter-node messaging
3.210 Patterns and Frameworks
Patterns: Common solutions to common problems in a

context.
Design patterns of classes: Mechanisms
Architectural Patterns: Frameworks (extendible tem-

plates for applications in a domain)
Patterns specifycommon Mechanisms and Frameworks.
Patterns are reused by adapting them to the context of

an application.
Idioms: common ways of programming (Implementa-

tion pattern)
<<framework>>
Design Pattern
Architectural Pattern
Gamma et. al. Buschmann et. al.
"Design Patterns" "A System of Patterns"
(1995) (1996)
3.211. DESIGN PATTERNS 365
3.211 Design Patterns
Design pattern give class structure (class diagram) and

behaviour (interaction diagrams)
Design patterns are modelled by templates of Collab-

orations, role parameters appropriate to the context of
application being passed to obtain the design for the
application
Example design pattern: Model-View-Controller pat-

tern for user interfaces design in a document prepa-
ration software:
Receiver Client
Document Command
Invoker
Client Receiver
Application
Command
Command
PasteCommand
Command
OpenCommand
MenuItem Invoker
3.212 Mechanisms
Mechanisms are design pattern for classes.
Collaboration models mechanism: a template collabo-

ration with role parameters for the template is used.
Example of Mechanism: Adapter pattern: adapting a

class to respond to a slightly different set of events from
knowledge of its responses to a set of events.
Example Mechanism: Observer pattern
TaskQueue Subject
Subject
Observer
Observer
SliderBar Observer
3.213. ARCHITECTURAL PATTERNS – FRAMEWORKS 367
3.213 Architectural Patterns – Frameworks
Architectural patterns give structure and behaviour of

the entire system for an application in a domain.
Architectural patterns provide extendible templates for

applications within a domain
Architectural patterns (Frameworks) are modelled by

Stereotyped packages.
Frameworks are larger than mechanisms.
Frameworks are micro architectures with a set of Mech-

anisms which work together to solve a common prob-
lem for a common domain.
A framework providesa skeleton of an architecture with

slots, tabs, knobs and dials that are adjusted by the
user to adapt it to a particular application context in the
same domain.
3.214 Frameworks
Example Architectural Pattern (Framework): Blackboard

Architecture pattern for Cryptograms design
Layer Pattern: ISO abstraction levels
Pipes & Fiilters (I/O)
Broker Pattern (Remote Service: CORBA)
Model View Controller (GUI)
...
3.214. FRAMEWORKS 369
<<framework>>
Blackboard
KnowledgeSource
Blackboard
Control
Blackboard
KnowledgeSource
Reasoning Engine
apply new knowledge source

Introduction To Software Engineering: UML: Ananda Amatya Department of Computer Science University of Warwick

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Introduction To Software Engineering: UML: Ananda Amatya Department of Computer Science University of Warwick

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction To Software Engineering: UML: Ananda Amatya Department of Computer Science University of Warwick

Uploaded by

Copyright:

Available Formats

Introduction to Software Engineering: UML

November 26, 1999

1 Lecture 0: Introduction to UML 27

1.1 UML Introduction Topics . . . . . . . . . . . 28

1.2 Recommended Books . . . . . . . . . . . . 30

1.5 Modelling Elements: Components . . . . . 36

1.6 Modelling Elements: Relationships . . . . . 38

1.7 Modelling Elements: States & Interactions . 40

1.8 Modelling Element Diagrams . . . . . . . . 42

1.9 Modelling Elements: Notes . . . . . . . . . 43

1.10 Modelling Mechanisms: Adornments . . . . 45

1.12 Extending Notation: Stereotype . . . . . . . 48

1.13 Extending Notation: Tagged Values . . . . . 50

1.14 Extending Notation: Constraints . . . . . . 52

1.16 Use Case Diagram . . . . . . . . . . . . . . 56

1.17 Class Diagram . . . . . . . . . . . . . . . . 58

1.18 State Diagram . . . . . . . . . . . . . . . . 60

1.19 Sequence Diagram . . . . . . . . . . . . . . 62

1.20 Collaboration Diagram . . . . . . . . . . . . 64

1.21 Activity Diagram . . . . . . . . . . . . . . . 66

1.22 Package Diagram . . . . . . . . . . . . . . . 68

1.23 Component Diagram . . . . . . . . . . . . . 69

1.24 Deployment Diagram . . . . . . . . . . . . . 70

1.26 UML Views . . . . . . . . . . . . . . . . . . 72

1.27 Use Case View . . . . . . . . . . . . . . . . 74

1.28 Logical View . . . . . . . . . . . . . . . . . 75

1.29 Concurrency View . . . . . . . . . . . . . . 76

1.30 Concurrency View . . . . . . . . . . . . . . 77

1.31 Component View . . . . . . . . . . . . . . . 78

1.32 Deployment View . . . . . . . . . . . . . . . 79

1.33 Analysis: Requirements, Risks, Constraints 80

1.34 Design: Package, Class, Relationships, User-

1.35 Design (Dynamic): Sequence, Collaboration,

1.36 Implementation:Components, Codes, Deploy-

1.38 Lecture 0 Exercise . . . . . . . . . . . . . . 85

2 Lecture 1: Use Cases and Use Case Diagrams 89

2.1 Lecture 1: Use Case Topics . . . . . . . . . 90

2.7 Actor Icon & Stereotyped Class . . . . . . . 96

2.8 Actor Interactions with a System . . . . . . 97

2.9 Actor Generalisation . . . . . . . . . . . . . 98

2.10 Example: Actors in a University Course Reg-

2.11 Actors for Course Registration System . . . 100

2.12 Use Case . . . . . . . . . . . . . . . . . . . 101

2.13 Use Case Icon . . . . . . . . . . . . . . . . 102

2.14 Documentation Property of Use Case . . . 103

2.15 Use Case Relationships . . . . . . . . . . . 104

2.16 << in lude >> Relationship . . . . . . . . 105

2.17 << extend >> Relationship . . . . . . . . . 106

2.18 Commentary . . . . . . . . . . . . . . . . . 108

2.19 Use Case Diagrams . . . . . . . . . . . . . 109

2.20 Use Case Diagrams . . . . . . . . . . . . . 110

2.21 Example: University Course Registration . . 111

2.22 Actors in University Course Registration . . 112

2.23 Actors . . . . . . . . . . . . . . . . . . . . . 113

2.24 Use Cases in University Course Registration 114

2.25 Use Case Names . . . . . . . . . . . . . . . 115

2.26 Use Cases . . . . . . . . . . . . . . . . . . 116

2.27 Use Case Documentations . . . . . . . . . 117