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.
30 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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).
32 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
34 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
36 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
38 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
40 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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
42 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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()
44 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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
46 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
48 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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>>
50 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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=...}
52 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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}
54 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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).
56 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
58 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
60 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
62 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
64 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
66 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
68 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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
70 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
72 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
74 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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

76 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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

78 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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

80 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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

82 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
84 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
86 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML

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.
88 CHAPTER 1. LECTURE 0: INTRODUCTION TO UML
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.
92 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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.
94 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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.

96 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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
98 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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
100 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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.

102 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

2.13 Use Case Icon

Sales Statistics Customer Statistics

Signing an insurance policy

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
104 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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
106 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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)
108 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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.
110 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

2.20 Use Case Diagrams

Signing an insurance policy

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

112 CHAPTER 2. LECTURE 1: USE CASES AND 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
114 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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.
116 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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.

 ....
118 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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
120 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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.
122 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

2.32 Main Use Case Diagram

Register for Courses

Student
Billing System

Select Course to Teach

Lecturer
Request Course Roster

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

Request Course Roster

Select Course to Teach Lecturer

<<include>> <<include>>

Validate User
124 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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.
126 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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)
128 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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
130 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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

6. Determine 5 use cases and 2 actors for a Cellular Tele-

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

7. Determine 5 actors and 4 use cases for a Credit Card

Validation System and draw a use case diagram show-
ing communication, <<include>> and <<extend>>
relationships. Also show any generalisation relation-
132 CHAPTER 2. LECTURE 1: USE CASES AND USE CASE DIAGRAMS

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-
ing communication, <<include>> and <<extend>>
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.
136CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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,
138CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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.
140CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
142CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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.
144CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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.
146CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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 147

3.12 Commentary

Sequence diagrams for use-cases determine the class op-

erations (methods).
148CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
150CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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 151

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.
152CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
154CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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.
156CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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 157

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.
158CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

3.23 Class Relationships

 Association

 Dependency

 Specialisation, Generalisation

 Packaging

 Refinement, Realisation
3.24. COMMENTARY 159

3.24 Commentary

Association is a connection between classes. A link is an

instance of an association: Objects are connected by links.
160CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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 161

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.
162CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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 163

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).
164CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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 165

3.30 Commentary

Default multiplicity is 1.
166CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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 167

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.
168CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

170CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

3.35 Aggregation

 Example Aggregation: CourseOffering being part of

Course

Course CourseOffering
3.36. COMMENTARY 171

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.
172CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
174CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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..*
176CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
178CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
180CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
182CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
184CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

*
186CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
188CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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..*
190CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
192CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
194CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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:

196CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
198CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

200CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

.
202CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
204CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
206CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
208CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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:

Interfaces UniversityArtifacts

People

 Semantically related grouping

 Owned by package: import

 No instantiation; no aggregation/association

 Dependency & inheritance: Yes

 Visibility of components
210CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
3.72. COMMENTARY 211

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

212CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
214CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

3.74 Package Classes: Example

Course CourseOffering
(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
216CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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)

Interfaces UniversityArtifacts
3.77. COMMENTARY 217

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.
218CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
220CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
222CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

224CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
226CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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 227

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-
228CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

230CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

3.89 Example: Hierarchy with attribs. and assocs. for children

 Parent: UserInformation

 Child1: LecturerInformation

– Attributes:
 tenureStatus
 name
 IDNumber
– Association:
 Association: to CourseOffering
 Multiplicity at LecturerInformation: 1
 Multiplicity at CourseOffering: 0..4
 Role at LecturerInformation: Teacher Information

 Child2: StudentInformation

– Attributes:
 major
 name
 IDNumber
– Association: to CourseOffering
 Multiplicity at StudentInformation: 3..10
 Multiplicity at CourseOffering: 0..4
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
232CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

3.91 Example: Hierarchy with relocated attribs. and opers.

 Parent: UserInformation

– Attributes:
 name
 IDNumber

 Child1: LecturerInformation

– Attributes:
 tenureStatus
– Association:
 Association: to CourseOffering
 Multiplicity at LecturerInformation: 1
 Multiplicity at CourseOffering: 0..4
 Role at LecturerInformation: Teacher Information

 Child2: StudentInformation

– Attributes:
 major
– Association: to CourseOffering
 Multiplicity at StudentInformation: 3..10
 Multiplicity at CourseOffering: 0..4
3.92. INHERITANCE RELATIONSHIP WITH REALLOCATED ATTRIBS. AND OPS. 233

3.92 Inheritance Relationship with reallocated attribs. and ops.

UserInformation
name
IDNumber

LecturerInformation StudentInformation

tenureStatus major

1 3..10
Teacher
Information
0..4 0..4
CourseOffering
234CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
236CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

238CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

240CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

242CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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)
244CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
246CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

248CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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}
250CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

252CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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.
3.112. LECTURE 2 EXERCISES: 253

3.112 Lecture 2 Exercises:

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,
254CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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.
3.112. LECTURE 2 EXERCISES: 255

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-
256CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

<<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
3.112. LECTURE 2 EXERCISES: 257

of association, dependency and generalisation relation-

ships between between the classes. Also give appro-
priate package diagrams.
258CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

Lecture 3: Sequences, Collaborations, Activities, States,

and corresponding Diagrams Ananda Amatya
Department of Computer Science
University of Warwick
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
260CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING 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

3.114. COMMENTARY 261

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
262CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
264CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
3.2: [printer busy] Store (file)
branch

condition

life line
GENERIC
Message Numbering Optional
Activation Return
Return Message Not Always shown
Synchronous Messages
266CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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)

3.2: [printer busy] Store (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
268CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

270CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
272CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
274CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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.
276CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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.
278CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
280CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
282CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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)

284CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
286CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
288CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
290CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
292CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

294CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
296CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

298CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
300CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

Sampler.Run(channel, frequency)

Initiate

Measuring
Updating
displayer

swim lanes
302CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

Sampler.Run(channel, frequency)

Initiate

Updating Measured
Measuring
displayer value

Object
Object sent to Updating displayer action by Measuring action
304CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
306CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
308CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
310CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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 311

3.163 Commentary

Activity diagrams are useful to express algorithmic steps

for a complex operation (flow-chart).
312CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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 313

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.
314CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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 315

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.
316CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING 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)
318CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

 Syntax for parameter:

Parameter-name ’:’ type-expression,

Parameter-name ’:’ type-expression ...
3.170. COMMENTARY 319

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.
320CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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)
322CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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)
324CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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 325

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)
326CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
328CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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()
330CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
332CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

3.183 Or State

Running

Forward Backward
3.184. AND STATE 333

3.184 And State

Running

Forward Backward

Low Speed High speed

334CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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]
[All items checked &&
Dispatching some items not in stock]
do/initiate delivery
Items received [all items available]

Delivered

Delivered Waiting

Items Received[some items not in stock]

336CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

3.187 Order Processing with Cancellation

/get first item

[Not all items checked]/ Checking

get netxt item
do/check item

[All items checked &&

all items available] cancel
[All items checked &&
Dispatching some items not in stock]
do/initiate delivery
Items received [all items available]
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 checked &&
all items available]
[All items checked &&
some items not in stock]
Dispatching
do/initiate delivery
Items received [all items available]

Items Received
[Some items not Waiting
in stock]

Delivered
cancel
Delivered Cancelled
338CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
340CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

3.191 Lecture 3 Exercises:

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.
3.191. LECTURE 3 EXERCISES: 341

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
342CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
3.191. LECTURE 3 EXERCISES: 343

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-
344CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

evant Sequential, Collaboration, Activity and State Di-

agrams to give the dynamic models that capture the
behaviour of the system.
3.191. LECTURE 3 EXERCISES: 345

Lecture 4: Components, Deployment, Collaborations, Pat-

terns, Frameworks Ananda Amatya
Department of Computer Science
University of Warwick
346CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
348CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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)

350CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
352CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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.

354CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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.
356CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

358CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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

Course CourseOffering
UserInformation

LecturerInformation StudentInformation
360CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
362CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
364CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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
366CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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.
368CHAPTER 3. LECTURE 2: CLASSES, OBJECTS, PACKAGES AND CORRESPONDING DIAGRAMS

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