Object oriented analysis and design

Object-Oriented
Analysis and Design
Understanding System Development
with UML 2.0

Mike O’Docherty



Object-Oriented
Analysis and Design



Object-Oriented
Analysis and Design
Understanding System Development
with UML 2.0

Mike O’Docherty


Copyright  2005

John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester,
West Sussex PO19 8SQ, England
Telephone (+44) 1243 779777

Email (for orders and customer service enquiries):
Visit our Home Page on www.wiley.com

All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system or
transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or
otherwise, except under the terms of the Copyright, Designs and Patents Act 1988 or under the terms of a
licence issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1T 4LP, UK,
without the permission in writing of the Publisher. Requests to the Publisher should be addressed to the
Permissions Department, John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex
PO19 8SQ, England, or emailed to , or faxed to (+44) 1243 770620.
This publication is designed to provide accurate and authoritative information in regard to the subject
matter covered. It is sold on the understanding that the Publisher is not engaged in rendering professional
services. If professional advice or other expert assistance is required, the services of a competent
professional should be sought.
Other Wiley Editorial Offices
John Wiley & Sons Inc., 111 River Street, Hoboken, NJ 07030, USA
Jossey-Bass, 989 Market Street, San Francisco, CA 94103-1741, USA
Wiley-VCH Verlag GmbH, Boschstr. 12, D-69469 Weinheim, Germany
John Wiley & Sons Australia Ltd, 33 Park Road, Milton, Queensland 4064, Australia
John Wiley & Sons (Asia) Pte Ltd, 2 Clementi Loop #02-01, Jin Xing Distripark, Singapore 129809
John Wiley & Sons Canada Ltd, 22 Worcester Road, Etobicoke, Ontario, Canada M9W 1L1
Wiley also publishes its books in a variety of electronic formats. Some content that appears
in print may not be available in electronic books.
Library of Congress Cataloging-in-Publication Data
O’Docherty, Mike.
Object-oriented analysis and design : understanding system development
with UML 2.0 / Mike O’Docherty.
p. cm.
Includes bibliographical references and index.
ISBN-13 978-0-470-09240-8
ISBN-10 0-470-09240-8 (pbk. : alk. paper)
1. Object-oriented programming (Computer science) 2. Computer
software–Development. I. Title.

QA76.64.O35 2005
005.1 17 – dc22
2005004182
British Library Cataloguing in Publication Data
A catalogue record for this book is available from the British Library
ISBN-13 978-0-470-09240-8
ISBN-10 0-470-09240-8
Typeset in 10/14 Berkeley-Medium by Laserwords Private Limited, Chennai, India
Printed and bound in Great Britain by Biddles Ltd, King’s Lynn
This book is printed on acid-free paper responsibly manufactured from sustainable forestry
in which at least two trees are planted for each one used for paper production.


For Alice and George



Contents

1 Introduction
1.1 Background
1.2 A Brief History of Programming
1.3 Methodologies
1.4 About this Book
1.4.1 Content Overview
1.4.2 Case Studies
1.4.3 Navigation

2
4

4
5
5
6
7
7

Part I Setting the Scene

9

2 Object Concepts
2.1 Introduction
2.2 What Is an Object?
2.3 Identical or Equal?
2.4 Depicting Objects
2.5 Encapsulation
2.6 Association and Aggregation
2.7 Graphs and Trees
2.8 Links and Navigability
2.9 Messages
2.10 Invoking an Operation
2.11 An Example Collaboration
2.12 How an Object-Oriented Program Works
2.13 Garbage Collection
2.14 Classes
2.15 What Does a Class Define?
2.16 Shared Data and Shared Operations
2.17 Types
2.18 Terminology

2.19 Reusing Code

10
12
13
16
19
20
21
23
25
27
28
30
32
32
34
37
39
40
41
43


viii

Contents

2.20 Summary
Further Reading

Review Questions
Answers to Activity 1
Answers to Review Questions

48
48
48
50
50

3 Inheritance
3.1 Introduction
3.2 Designing a Class Hierarchy
3.3 Adding Implementations to a Class Hierarchy
3.4 Abstract Classes
3.5 Redefining Methods
3.6 Implementing a Stack Class
3.6.1 Implementing a Stack using Inheritance
3.6.2 Implementing a Stack using Composition
3.6.3 Inheritance versus Composition
3.7 Multiple Inheritance
3.8 Guidelines for Using Inheritance
3.9 Summary
Further Reading
Review Questions
Answers to Review Questions

52
54
55

58
59
63
64
65
66
68
69
73
73
74
74
75

4 Type Systems
4.1 Introduction
4.2 Dynamic and Static Type Systems
4.3 Polymorphism
4.3.1 Polymorphic Variables
4.3.2 Polymorphic Messages
4.4 Dynamic Binding
4.5 Polymorphism Guideline
4.6 Type Casting
4.7 Explicit Casts
4.8 Genericity with Templates
4.9 Summary
Further Reading
Review Questions
Answers to Activity 2
Answers to Activity 3

Answers to Review Questions

78
80
80
82
82
83
85
87
88
89
91
93
93
93
95
95
96


Contents

5 Software Development Methodologies
5.1 Introduction
5.2 Classical Phases in Software Production
5.2.1 Requirements
5.2.2 Analysis
5.2.3 Design
5.2.4 Specification

5.2.5 Implementation
5.2.6 Testing
5.2.7 Deployment
5.2.8 Maintenance
5.2.9 Key Questions
5.3 Software Engineering and the Waterfall Methodology
5.4 New Methodologies
5.4.1 Spiral Methodology
5.4.2 Iterative Methodology
5.4.3 Incremental Methodology
5.4.4 Combining the Methodologies
5.5 Object-Oriented Methodologies
5.5.1 UML, RUP and XP
5.5.2 The Need for Development Tools
5.6 Ripple Overview
5.6.1 Use Case Diagram
5.6.2 Class Diagram (Analysis Level)
5.6.3 Communication Diagram
5.6.4 Deployment Diagram
5.6.5 Class Diagram (Design Level)
5.6.6 Sequence Diagram
5.7 Summary
Further Reading
Review Questions
Answers to Review Questions

Part II Understanding the Problem
6 Gathering Requirements
6.1 Introduction
6.2 The Birth of a System

98
100
102
102
102
103
103
104
104
104
104
105
106
110
110
111
112
113
114
115
116
117
120
121
122
123
124
125
126

126
127
128

129
130
132
133

ix


x

Contents

6.3
6.4

Use Cases
Business Perspective
6.4.1 Identifying Business Actors
6.4.2 Writing the Project Glossary
6.4.3 Identifying Business Use Cases
6.4.4 Illustrating Use Cases on a Communication Diagram
6.4.5 Illustrating Use Cases on an Activity Diagram
6.5 Developer Perspective
6.5.1 Specializing Actors
6.5.2 Use Case Relationships
6.5.3 System Use Case Details

6.5.4 Preconditions, Postconditions and Inheritance
6.5.5 Supplementary Requirements
6.5.6 User Interface Sketches
6.5.7 Prioritizing System Use Cases
6.6 Summary
Further Reading
Review Questions
Answers to Review Questions
7 Analyzing the Problem
7.1 Introduction
7.2 Why Do Analysis?
7.3 Overview of the Analysis Process
7.4 Static Analysis
7.4.1 Finding Classes
7.4.2 Identifying Class Relationships
7.4.3 Drawing Class and Object Diagrams
7.4.4 Drawing Relationships
7.4.5 Attributes
7.4.6 Association Classes
7.4.7 Tangible versus Intangible Objects
7.4.8 Good Objects
7.5 Dynamic Analysis
7.5.1 Drawing Use Case Realizations
7.5.2 Boundaries, Controllers and Entities
7.5.3 Communication Diagram Elements
7.5.4 Adding Operations to Classes
7.5.5 Responsibilities

135
136

137
138
139
141
143
145
149
150
155
156
158
158
159
162
162
163
165
166
168
168
169
170
170
171
172
173
178
182
183
188

188
189
191
192
194
194


Contents

7.5.6 State Modeling
7.6 Summary
Further Reading
Review Questions
Answers to Activity 4
Answers to Review Questions

Part III Designing the Solution

195
197
197
197
201
201

203

8 Designing the System Architecture
8.1 Introduction

8.2 Design Priorities
8.3 Steps in System Design
8.4 Choosing a Networked System Topology
8.4.1 The History of Network Architectures
8.4.2 Three-Tier Architecture
8.4.3 Personal Computers
8.4.4 Network Computers
8.4.5 The Internet and the World Wide Web
8.4.6 Intranets
8.4.7 Extranets and Virtual Private Networks
8.4.8 Client–Server versus Distributed Architectures
8.4.9 Depicting Network Topology in UML
8.5 Designing for Concurrency
8.6 Designing for Security
8.6.1 Digital Encryption and Decryption
8.6.2 General Security Rules
8.7 Partitioning Software
8.7.1 Systems and Subsystems
8.7.2 Layers
8.7.3 Java Layers: Applet plus RMI
8.7.4 Message Flow in Layers
8.8 Summary
Further Reading
Review Questions
Answers to Review Questions

204
206
207
207

208
208
210
212
213
214
215
215
216
218
220
222
223
225
225
226
227
230
233
237
238
238
239

9 Choosing Technologies
9.1 Introduction

240
242

xi


xii

Contents

9.2
9.3
9.4
9.5
9.6
9.7

Client Tier Technologies
Client Tier to Middle Tier Protocols
Middle Tier Technologies
Middle Tier to Data Tier Technologies
Other Technologies
Typical Front-End Configurations
9.7.1 HTML/CGI-with-Scripts
9.7.2 HTML/CGI-with-Servlets
9.7.3 RMI
9.7.4 CORBA
9.7.5 EJB
9.8 Back-End Configurations
9.9 Java E-Commerce Configuration
9.10 UML Packages
9.11 Summary
Further Reading

Review Questions
Answers to Review Questions
10 Designing the Subsystems
10.1 Introduction
10.2 Mapping the Analysis Class Model into the Design Class Model
10.2.1 Mapping Operations
10.2.2 Variable Types
10.2.3 Visibility of Fields
10.2.4 Accessors
10.2.5 Mapping Classes, Attributes and Compositions
10.2.6 Mapping Other Types of Association
10.2.7 Universal Identifier
10.3 Handling Persistence with a Relational Database
10.3.1 Database Management Systems
10.3.2 The Relational Model
10.3.3 Mapping Entity Classes
10.3.4 Mapping Associations
10.3.5 Mapping Object State
10.4 Finalizing the User Interfaces
10.5 Designing the Business Services
10.5.1 Using Proxies and Copies
10.5.2 Classifying Business Services

242
244
246
247
248
250
250

252
254
255
256
258
258
262
267
267
267
268
270
272
273
273
274
274
275
276
277
282
284
285
286
288
289
292
298
304
305

307


Contents

10.5.3 Session Identifiers
10.5.4 Business Service Realization
10.6 Using Patterns, Frameworks and Libraries
10.7 Transactions
10.7.1 Pessimistic and Optimistic Concurrency
10.7.2 General Guidelines for Using Transactions with Objects
10.7.3 Transactions in Upper Layers
10.8 Handling Multiple Activities
10.8.1 Controlling Multiple Tasks
10.8.2 Controlling Multiple Threads
10.8.3 Thread Safety
10.9 Summary
Further Reading
Review Questions
Answers to Review Questions
11 Reusable Design Patterns
11.1 Introduction
11.1.1 A Brief History of Patterns
11.1.2 Software Patterns Today
11.2 A Pattern Template
11.3 Common Design Patterns
11.3.1 Observer
11.3.2 Singleton
11.3.3 Multiton
11.3.4 Iterator

11.3.5 Factory Method and Abstract Factory
11.3.6 State
11.3.7 Facade
11.3.8 Adapter
11.3.9 Strategy and Template Method
11.3.10 Flyweight
11.3.11 Composite
11.3.12 Proxy
11.4 Using Patterns
11.5 Discovering, Combining and Adapting Patterns
11.6 Summary
Further Reading

309
310
312
312
313
314
315
315
315
316
318
321
321
322
323
326
328

328
329
330
331
331
337
341
342
346
347
352
354
356
358
361
364
367
367
370
371

xiii


xiv

Contents

12 Specifying the Interfaces of Classes
12.1 Introduction

12.2 What Is a Specification?
12.3 Formal Specification
12.4 Informal Specification
12.5 Dynamic Checking
12.6 Object-Oriented Specification
12.6.1 Formal Specification in OCL
12.6.2 Informal Specification in Eiffel
12.7 Design by Contract
12.7.1 Contracts and Inheritance
12.7.2 Reducing Error-Checking Code
12.7.3 Enforcing the Contract
12.7.4 Application Firewalls
12.8 Informal Specification in Java
12.8.1 Documenting a Contract using Comments
12.8.2 Checking Conditions Dynamically
12.8.3 Signaling Contract Violations using RuntimeExceptions
12.8.4 External Systems
12.8.5 Enabling and Disabling Dynamic Checks
12.9 Summary
Further Reading
Review Questions
Answers to Review Questions

372
374
375
376
378
380
382

383
384
385
389
391
394
395
396
396
396
397
398
400
402
403
403
404

13 Continuous Testing
13.1 Introduction
13.2 Testing Terminology
13.2.1 Black-Box Testing
13.2.2 White-Box Testing
13.3 Types of Test
13.3.1 Unit Testing
13.3.2 Integration Testing
13.3.3 Alpha Testing
13.3.4 Beta Testing
13.3.5 Use Case Testing
13.3.6 Component Testing

13.3.7 Build Testing
13.3.8 Load Testing
13.3.9 Installation Testing

406
408
408
409
410
411
412
412
413
413
414
414
415
417
418


Contents

13.3.10 Acceptance Testing
13.3.11 Regression Tests
13.3.12 Documentation Tests
13.3.13 Testing for Security
13.3.14 Metrics
13.4 Automating Tests
13.5 Preparing for Testing

13.6 Testing Strategies
13.6.1 Testing During Development
13.6.2 Testing During the Testing Phase
13.6.3 Testing After Release
13.7 What to Test For
13.8 Test-Driven Development
13.9 An Example of Test-Driven Development using JUnit
13.9.1 Testing the Car Class
13.9.2 Implementing the Car Class
13.9.3 Refactoring Tests
13.9.4 Creating a Test Suite for Regression Testing
13.9.5 Testing Across Methods
13.9.6 Completing the Store Class
13.10 Summary
Further Reading

418
419
419
419
420
421
422
424
424
425
426
426
430
431

433
434
435
439
441
442
445
445

A Ripple Summary

446

B iCoot Case Study
B.1 Business Requirements
B.1.1 Customer’s Mission Statement
B.1.2 Actor List
B.1.3 Use Case List
B.1.4 Use Case Communication Diagrams
B.1.5 Use Case Activity Diagrams
B.1.6 Use Case Details
B.2 System Requirements
B.2.1 User Interface Sketches
B.2.2 Actor List
B.2.3 Use Case List
B.2.4 Use Case Diagram
B.2.5 Use Case Survey

450
450

450
450
451
452
452
452
456
456
460
460
460
461

xv


xvi

Contents

B.3

B.4

B.5

B.6

B.7

B.2.6 Use Case Details
B.2.7 Supplementary Requirements
B.2.8 Use Case Priorities
Analysis
B.3.1 Class Diagram
B.3.2 Attributes
B.3.3 Operation List
B.3.4 State Machine for a Reservation
B.3.5 Use Case Realization
System Design
B.4.1 Technology Choices
B.4.2 Layer Diagram
B.4.3 Layer Interaction Policy
B.4.4 Packages
B.4.5 Deployment Diagram
B.4.6 Security Policy
B.4.7 Concurrency Policy
Subsystem Design
B.5.1 Business Services
B.5.2 ServletsLayer Class Diagram
B.5.3 ServletsLayer Field List
B.5.4 ServletsLayer Message List
B.5.5 ServerLayer Class Diagram
B.5.6 ServerLayer Field List
B.5.7 ServerLayer Message List
B.5.8 BusinessLayer Class Diagram
B.5.9 BusinessLayer Field List
B.5.10 Protocol Objects Class Diagram
B.5.11 Database Schema
B.5.12 User Interface Design

B.5.13 Business Service Realization
Class Specification
B.6.1 Server Class Specification
B.6.2 Business Logic Class Specification
Outline Test Plan
B.7.1 Introduction
B.7.2 The Impact of Spirals and Increments
B.7.3 Testing of Non-Code Artifacts
B.7.4 Code Reviews

462
465
465
466
466
467
467
469
470
476
476
477
479
479
479
482
482
483
483
483

484
484
485
486
486
487
488
492
494
494
494
508
508
509
512
512
512
513
513


Contents

B.7.5 Test-Driven Development
B.7.6 Assertions
B.7.7 Testing Phase
B.7.8 Documentation Testing
B.7.9 Build Testing
B.7.10 Test Documentation and Logging
B.7.11 Testing Activities by Phase

B.8 Glossary

513
514
514
515
515
515
516
517

C Summary of UML Notation Used

526

Bibliography

538

Index

541

xvii



1
Introduction

T

he aim of this book is to give you a broad understanding of the processes and techniques
used in object-oriented software development, the production of computer programs using
object-oriented techniques. The Unified Modeling Language (UML) comes into play as the
standard notation used in industry for software documentation.
You may be a student at a university or on a commercial training course. Or you may
be an experienced software developer, moving into object orientation for the sake of your
career. In either case, this book is for you. Little prior knowledge is required on your
part and there is no attempt to teach you everything there is to know. Instead, you will
be guided through the essential parts of the process, so that you can do your job more
effectively.
Although this book is broad, it only goes as deep as the point where you would normally
start writing lines of code. Describing how to write code would mean choosing a particular
programming language; the decision about the most appropriate language is for you to
make. You should consider this book as a generic front-end that will work for any pure,
object-oriented programming language.
The objectives of this first chapter are to describe the background to this book, to give
you an idea of the content and to describe how to navigate your way around.



Chapter Outline
1.1 Background
1.2 A Brief History of Programming
1.3 Methodologies
1.4 About this Book

1

4

Chapter 1

1.1 BACKGROUND
These days, new software is usually object-oriented. That is, the software is written using an
abstraction called an object. There is, naturally, much more to commercial software development than simply writing lines of code: there is investigation of the business requirements,
analysis of the problem, design of the solution, and so on. Objects should be used at every
stage of the development because they reduce the amount of information that has to be
understood and improve the communication between members of the development team.

1.2 A BRIEF HISTORY OF PROGRAMMING
Commercial programming has had a number of generations, of which ‘object-oriented’ is
just the latest:
• Machine code: Programming using binary numbers.
• Assembly language: Programming using alphanumeric symbols, or mnemonics, as shorthand for machine code. Assembly language is translated into machine code by a program
called an assembler.
• High-level languages: Programming using languages (such as Fortran and COBOL) that
have high-level constructs such as types, functions, loops and branches. High-level
languages (and later generations of programming languages) are translated into machine
code using a program called a compiler.
• Structured programming: Programming using cleaner high-level languages (such as Pascal,
Modula and Ada) that are characterized by fewer pitfalls for the programmer and more
discipline in the way a program is broken down into sub-tasks and sub-systems.
• Object-oriented programming: Programming using independent modules of data and
functions that correspond to concepts in the problem domain, such as Customer or
ScrollBar. This modularity leads to even fewer pitfalls for the programmer and encourages
the reuse of code across separate programs. Good object-oriented programming languages
include Java and Eiffel, because they’re well designed, pure and portable (available on

many platforms). Other examples include Smalltalk, C# and, in general, any language that
started life as a structured language and grew up with object-oriented extensions (C++
and various dialects of Pascal, for example).
You may also have heard of functional programming and logic programming. So far they
have had little commercial impact.
All the generations above survive today, to a greater or lesser extent. Which one we end
up using depends on the situation we walk into; personal preference; and the constraints of