Object-Oriented Software Engineering

Object-Oriented Software Engineering

Practical software development using UML and Java

Second edition

Lethbridge.book Page i Tuesday, November 16, 2004 12:22 PM

Lethbridge.book Page ii Tuesday, November 16, 2004 12:22 PM

Object-Oriented Software

Engineering

Practical Software Development using UML and Java

Second edition

Timothy C. Lethbridge

Robert Laganière

London • Burr Ridge, IL • New York • St. Louis • San Francisco •Auckland

Bogotá • Caracas • Lisbon • Madrid • Mexico • Milan • Montreal • New Delhi

Panama • Paris• San Juan • São Paulo • Singapore •Tokyo • Toronto

Lethbridge.book Page iii Tuesday, November 16, 2004 12:22 PM

Object-Oriented Software Engineering

Timothy C Lethbridge

Robert Laganière

ISBN 0-07-70109082

Published by McGraw-Hill Education

Shoppenhangers Road

Maidenhead

Berkshire SL62QL

Telephone: 44 (0) 1628 502 500

Fax: 44 (0) 1628 770 224

Website: http://www.mcgraw-hill.co.uk

British Library Cataloguing in Publication Data

A catalogue record for this book is available from the British Library

Library of Congress Cataloguing in Publication Data

The Library of Congress data for this book has been applied for from the Library of

Congress

Publishing Director: Catriona King

Development Editor: Karen Mosman

Marketing Manager: Alice Duijser

Senior Production Manager: Max Elvey

Text Design by Mike Cotterell

Cover design by Ego Creative

Typeset at Neuadd Bwll, Llanwrtyd Wells

Printed and bound in the UK by Bell & Bain Ltd, Glasgow

Published by McGraw-Hill Education (UK) Limited an imprint of The McGraw-Hill

Companies, Inc., 1221 Avenue of the Americas, New York, NY 10020. Copyright © 2005

by McGraw-Hill Education (UK) Limited. All rights reserved. No part of this

publication may be reproduced or distributed in any form or by any means, or stored in

a database or retrieval system, without the prior written consent of The McGraw-Hill

Companies, Inc., including, but not limited to, in any network or other electronic

storage or transmission, or broadcast for distance learning.

ISBN 0-07-70109082 © 2005. Exclusive rights by The McGraw-Hill Companies, Inc. for

manufacture and export. This book cannot be re-exported from the country to which it

is sold by McGraw-Hill.

Lethbridge.book Page iv Tuesday, November 16, 2004 12:22 PM

iContents

Foreword xi

Preface xv

Guided tour xxii

Technology to enhance learning and teaching xxiv

1 Software and software engineering 1

1.1 The nature of software 1

1.2 What is software engineering? 6

1.3 Software engineering as a branch of the engineering profession 8

1.4 Stakeholders in software engineering 10

1.5 Software quality 11

1.6 Software engineering projects 14

1.7 Activities common to software projects 16

1.8 The themes emphasized in this book 20

1.9 Difficulties and risks in software engineering as a whole 24

1.10 Summary 26

1.11 For more information 26

2 Review of object orientation 29

2.1 What is object orientation? 29

2.2 Classes and objects 31

2.3 Instance variables 36

2.4 Methods, operations and polymorphism 38

2.5 Organizing classes into inheritance hierarchies 39

2.6 The effect of inheritance hierarchies on polymorphism and variable declarations 45

2.7 Concepts that define object orientation 52

2.8 A program for manipulating postal codes 55

2.9 Classes for representing geometric points 57

2.10 Measuring the quality and complexity of a program 60

2.11 Difficulties and risks in programming language choice and OO programming 62

2.12 Summary 63

2.13 For more information 63

Lethbridge.book Page v Tuesday, November 16, 2004 12:22 PM

vi Contents

3 Basing software development on reusable technology 67

3.1 Reuse: building on the work and experience of others 68

3.2 Incorporating reusability and reuse into software engineering 69

3.3 Frameworks: reusable subsystems 71

3.4 The client–server architecture 77

3.5 Technology needed to build client–server systems 87

3.6 The Object Client–Server Framework (OCSF) 91

3.7 Basic description of OCSF – client side 92

3.8 Basic description of OCSF – server side 95

3.9 An instant messaging application using the OCSF 99

3.10 Difficulties and risks when considering reusable technology and

client–server systems 101

3.11 Summary 102

3.12 For more information 103

4 Developing requirements 109

4.1 Domain analysis 109

4.2 The starting point for software projects 114

4.3 Defining the problem and the scope 115

4.4 What is a requirement? 119

4.5 Types of requirements 119

4.6 Use cases: describing how the user will use the system 127

4.7 Some techniques for gathering requirements 138

4.8 Types of requirements document 145

4.9 Reviewing requirements 148

4.10 Managing changing requirements 155

4.11 GPS-based Automobile Navigation Assistant (GANA) 156

4.12 Requirements for a feature of the SimpleChat instant messaging program 160

4.13 Difficulties and risks in domain and requirements analysis 164

4.14 Summary 165

4.15 For more information 166

5 Modeling with classes 169

5.1 What is UML? 169

5.2 Essentials of UML class diagrams 172

5.3 Associations and multiplicity 173

5.4 Generalization 182

5.5 Object diagrams 186

5.6 More advanced features of class diagrams 188

5.7 The basics of Object Constraint Language (OCL) 193

5.8 A class diagram for genealogy 196

5.9 The process of developing class diagrams 199

5.10 Implementing class diagrams in Java 216

5.11 Difficulties and risks when creating class diagrams 218

5.12 Summary 218

5.13 For more information 219

Lethbridge.book Page vi Tuesday, November 16, 2004 12:22 PM

Contents vii

6 Using design patterns 221

6.1 Introduction to patterns 221

6.2 The Abstraction–Occurrence pattern 223

6.3 The General Hierarchy pattern 226

6.4 The Player–Role pattern 228

6.5 The Singleton pattern 231

6.6 The Observer pattern 232

6.7 The Delegation pattern 234

6.8 The Adapter pattern 236

6.9 The Façade pattern 238

6.10 The Immutable pattern 239

6.11 The Read-Only Interface pattern 240

6.12 The Proxy pattern 241

6.13 The Factory pattern 243

6.14 Enhancing OCSF to employ additional design patterns 246

6.15 Difficulties and risks when using design patterns 250

6.16 Summary 251

6.17 For more information 251

7 Focusing on users and their tasks 253

7.1 User-centered design 254

7.2 Characteristics of users 256

7.3 The basics of user interface design 258

7.4 Usability principles 262

7.5 Evaluating user interfaces 273

7.6 Implementing a simple GUI in Java 276

7.7 Difficulties and risks in user-centered design 280

7.8 Summary 280

7.9 For more information 281

8 Modeling interactions and behavior 285

8.1 Interaction diagrams 285

8.2 State diagrams 292

8.3 Activity diagrams 301

8.4 Implementing classes based on interaction and state diagrams 302

8.5 Difficulties and risks in modeling interactions and behavior 306

8.6 Summary 307

8.7 For more information 307

9 Architecting and designing software 309

9.1 The process of design 310

9.2 Principles leading to good design 314

Design Principle 1: Divide and conquer 314

Design Principle 2: Increase cohesion where possible 315

Design Principle 3: Reduce coupling where possible 321

Design Principle 4: Keep the level of abstraction as high as possible 329

Lethbridge.book Page vii Tuesday, November 16, 2004 12:22 PM

viii Contents

Design Principle 5: Increase reusability where possible 330

Design Principle 6: Reuse existing designs and code where possible 331

Design Principle 7: Design for flexibility 331

Design Principle 8: Anticipate obsolescence 332

Design Principle 9: Design for portability 333

Design Principle 10: Design for testability 334

Design Principle 11: Design defensively 334

9.3 Techniques for making good design decisions 336

9.4 Model Driven Development 340

9.5 Software architecture 342

9.6 Architectural patterns 347

The Multi-Layer architectural pattern 347

The Client–Server and other distributed architectural patterns 349

The Broker architectural pattern 351

The Transaction Processing architectural pattern 352

The Pipe-and-Filter architectural pattern 353

The Model–View–Controller (MVC) architectural pattern 355

The Service-Oriented architectural pattern 358

The Message-Oriented architectural pattern 360

9.7 Writing a good design document 362

9.8 Design of a feature for the SimpleChat instant messaging application 365

9.9 Difficulties and risks in design 366

9.10 Summary 367

9.11 For more information 368

10 Testing and inspecting to ensure high quality 371

10.1 Basic definitions 371

10.2 Effective and efficient testing 373

10.3 Defects in ordinary algorithms 380

10.4 Defects in numerical algorithms 388

10.5 Defects in timing and co-ordination: deadlocks, livelocks and critical races 391

10.6 Defects in handling stress and unusual situations 394

10.7 Documentation defects 398

10.8 Writing formal test cases and test plans 398

10.9 Strategies for testing large systems 402

10.10 Inspections 409

10.11 Quality assurance in general 413

10.12 Test cases for phase 2 of the SimpleChat instant messaging system 416

10.13 Difficulties and risks in quality assurance 420

10.14 Summary 421

10.15 For more information 422

11 Managing the software process 425

11.1 What is project management? 425

11.2 Software process models 428

Lethbridge.book Page viii Tuesday, November 16, 2004 12:22 PM

Contents ix

11.3 Cost estimation 435

11.4 Building software engineering teams 445

11.5 Project scheduling and tracking 449

11.6 Contents of a project plan 452

11.7 Difficulties and risks in project management 453

11.8 Summary 455

11.9 For more information 456

12 Review 459

12.1 Theme 1: Understanding the customer and user 459

12.2 Theme 2: Basing development on solid principles and reusable technology 459

12.3 Theme 3: Object orientation 464

12.4 Theme 4: Visual modeling using UML 464

12.5 Theme 5: Evaluation of alternatives in requirements and design 465

12.6 Theme 6: Incorporating quantitative and logical thinking 465

12.7 Theme 7: Iterative and agile development 466

12.8 Theme 8: Communicating effectively using documentation 467

12.9 Theme 9: Risk management in all software engineering activities 467

12.10 Where next? 469

Appendix A: Summary of the UML notation used in this book 471

Appendix B: Summary of the documentation types recommended in this book 475

Appendix C: System descriptions 479

Glossary 485

Lethbridge.book Page ix Tuesday, November 16, 2004 12:22 PM

Lethbridge.book Page x Tuesday, November 16, 2004 12:22 PM

iiForeword

If a builder build a house for someone, and does not construct

it properly, and the house which he built falls in and kills its

owner, then that builder shall be put to death

Article 229 of the Code of Hammurabi (1780 BC).

This earliest recorded attempt to regulate the engineering profession reminds

us, in the bluntest way possible, that the paramount purpose of engineering and

engineering design is to serve the user. One would assume that the engineer’s

responsibility to users is so self evident that it goes without saying. Various

professional engineering societies have inculcated this into the core of the rules

that regulate the conduct of their members.

However, in the relatively young discipline of software engineering, this has

not yet fully permeated the professional culture. Part of it is due to the essential

nature of the software: like no other engineering medium, software provides the

shortest path from concept to reality. With no metal to bend, heavy weights to

lift, or large teams of people to mobilize, creativity is practically unhampered. In

the heady and seductive process of embodying ideas through software, users are

often forgotten or relegated to secondary status. In some cases, they are even

seen as a distraction whose idiosyncrasies merely get in the way of ‘elegant and

clean’ design. Software developers are notorious for their impatience with

anything that separates them from programming – the medium has become the

message. Symptomatically, the terms ‘hacking’ and ‘hacker’ have no equivalent

in any other engineering discipline.

It is interesting to note the dramatic impact that the concept of ‘use case’ has

had on the software community. This idea, introduced by Ivar Jacobson and his

colleagues a little over a decade ago, was lauded as revolutionary. Its essence lies

in the formal introduction of the concept of a user (an ‘actor’) into the software

design process. (The layperson can hardly be blamed for wondering ‘what took

them so long?’ Hammurabi knew this almost 4000 years ago.)

Lethbridge.book Page xi Tuesday, November 16, 2004 12:22 PM

xii Foreword

Clearly, there is an imbalance of motivations here that needs to be set right:

the creative urge needs to be made subservient to the need to support the user.

This is something that has to be instilled from the first steps in a software

engineering education, and the book by Tim Lethbridge and Robert Laganière

is an important contribution to this.

The authors build the book around nine ‘themes’, auspiciously starting with

‘understanding the customer and user’. (Many software practitioners do not

even differentiate between customers and users.) The themes are not dry

theorems but distillations of practical and proven domain knowledge drawn

from a wealth of experience in industrial software development. The book

abounds with pragmatic detail that is rarely found in textbooks. In fact, it is the

kind of textbook that, as a young engineering student, I wished I had, because it

describes the proverbial ‘real world’.

The book does not shirk theory, quite to the contrary. However, the theory

comes alive because it is set in its full and proper context, comprising not only

the technical but the social and cultural aspects that often play an important role

in molding the theory. The reader not only learns why a particular technological

approach is good, but also its drawbacks and, perhaps equally importantly, its

history. (Some things – like the QWERTY keyboard – can only be understood

properly if one is familiar with their history.) They carefully point out the

controversial issues in modern software engineering without taking sides,

meticulously listing the arguments for each viewpoint.

The ‘engineering’ side of software engineering is extremely well represented

here and not just because the authors emphasize a user-centric approach.

Themes such as ‘incorporating quantitative thinking’, ‘evaluation of alternatives

in requirements and design’, ‘risk management’, or ‘communicating effectively’

are all proven and effective techniques evolved from centuries of engineering

experience and which, unfortunately, are still not adequately applied in software

engineering. Yes, software is different from other forms of engineering in many,

many ways, but not so different that it cannot benefit from these lessons learned.

For example, the lack of quantitative thinking, including elementary risk

analysis, is probably one of the most common causes of software project failures.

And, no matter which statistics you read, more software projects fail than

succeed. (Thankfully, the engineers who design buildings and airplanes have a

much better record than their software counterparts.)

Model-driven development is another important thread throughout the

book. This relatively new approach to software development, which promises

to be the first true technological generational advance since the invention of

the compiler, is covered in detail, from the basic principles of object

orientation to the latest modeling languages and their use. The way of the

future lies here.

So, from the nuts and bolts of objects to the high vistas of software

architecture, from writing code to testing, from software development processes

to project management – it’s all gathered here. The breadth and depth of the

material covered is striking and impressive, yet it has been brought together

Lethbridge.book Page xii Tuesday, November 16, 2004 12:22 PM

Foreword xiii

quite seamlessly, all the pieces in their rightful places, in balance. Although

primarily conceived as a textbook, it will undoubtedly serve its readers as a

reference for years to come.

If a builder build a program for someone, and does not

construct it properly…

Bran Selic

August, 2004

Ottawa, Canada

Lethbridge.book Page xiii Tuesday, November 16, 2004 12:22 PM

Lethbridge.book Page xiv Tuesday, November 16, 2004 12:22 PM