Object-Oriented and Classical Software Engineering

(1)

(2)

Object-Oriented and Classical Software

Engineering

Eighth Edition

Stephen R. Schach

Vanderbilt University

(3)

OBJECT-ORIENTED AND CLASSICAL SOFTWARE ENGINEERING, EIGHTH EDITION

Published by McGraw-Hill, a business unit of The McGraw-Hill Companies, Inc., 1221 Avenue of the Americas, New York, NY 10020. Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Previous editions © 2007, 2005, and 2002. 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.

Some ancillaries, including electronic and print components, may not be available to customers outside the United States.

This book is printed on acid-free paper.

1 2 3 4 5 6 7 8 9 0 DOC/DOC 1 0 9 8 7 6 5 4 3 2 1 0 ISBN 978-0-07-337618-9

MHID 0-07-337618-3

Vice President & Editor-in-Chief: Marty Lange Publisher: Raghothaman Srinivasan

Vice President EDP & Central Publishing Services: Kimberly Meriwether David Development Editor: Lora Neyens

Senior Marketing Manager: Curt Reynolds Project Manager: Melissa M. Leick Buyer: Kara Kudronowicz

Design Coordinator: Brenda A. Rolwes

Cover Designer: Studio Montage, St. Louis, Missouri Cover Image: © Photodisc/Getty Images

Compositor: Glyph International Typeface: 10/12 Times Roman Printer: R. R. Donnelley

All credits appearing on page or at the end of the book are considered to be an extension of the copyright page.

Library of Congress Cataloging-in-Publication Data Schach, Stephen R.

Object-oriented and classical software engineering / Stephen R. Schach. — 8th ed.

p. cm.

ISBN-13: 978-0-07-337618-9 (alk. paper) ISBN-10: 0-07-337618-3 (alk. paper)

1. Software engineering. 2. Object-oriented programming (Computer science) 3. UML (Computer science) 4. C++ (Computer program language) I.

Title.

QA76.758.S318 2010 005.1’17—dc22

2010020995

www.mhhe.com

sch76183_FM-i-xx.indd ii

sch76183_FM-i-xx.indd ii 10/06/10 2:36 PM10/06/10 2:36 PM

(4)

To Jackson and Mikaela

(5)

The following are registered trademarks:

ADF

Analyst/Designer Ant

Apache Apple AS/400 AT&T

Bachman Product Set Bell Laboratories Borland

Bugzilla

Capability Maturity Model Chrome

ClearCase ClearQuest CMM Cocoa Coca-Cola CORBA CppUnit CVS DB2 Eclipse e-Components Emeraude

Enterprise JavaBeans eServer

Excel Firefox Focus Ford

Foundation Class Library FoxBASE

GCC

Hewlett-Packard IBM

IMS/360

Jackpot Source Code Metrics Java

JBuilder JUnit Linux Lotus 1-2-3

Lucent Technologies MacApp

Macintosh

Macintosh Toolbox MacProject Microsoft Motif MS-DOS MVS/360 Natural Netscape New York Times Object C Objective-C

ObjectWindows Library 1-800-fl owers.com Oracle

Oracle Developer Suite OS/360

OS/370 OS/VS2 Palm Pilot Parasoft Post-It Note PowerBuilder PREfi x PREfast Project PureCoverage PVCS QARun

Rational Requisite Pro Rhapsody Rose

SBC Communications SilkTest

SLAM

Software through Pictures Solaris

SourceSafe SPARCstation Sun

Sun Enterprise Sun Microsystems Sun ONE Studio System Architect Together UNIX VAX

Visual Component Library Visual C++

Visual J++

VM/370 VMS

Wall Street Journal WebSphere

Win32 Windows 95 Windows 2000 Windows NT Word X11 Xrunner XUnit Zip disk ZIP Code z10

sch76183_FM-i-xx.indd iv

sch76183_FM-i-xx.indd iv 10/06/10 2:36 PM10/06/10 2:36 PM

(6)

PART A

SOFTWARE ENGINEERING CONCEPTS 35

Chapter 2

Software Life-Cycle Models 37 Learning Objectives 37

2.1 Software Development in Theory 37 2.2 Winburg Mini Case Study 38

2.3 Lessons of the Winburg Mini Case Study 42

2.4 Teal Tractors Mini Case Study 42 2.5 Iteration and Incrementation 43 2.6 Winburg Mini Case Study Revisited 47 2.7 Risks and Other Aspects of Iteration and

Incrementation 48 2.8 Managing Iteration and

Incrementation 51

2.9 Other Life-Cycle Models 52

2.9.1 Code-and-Fix Life-Cycle Model 52 2.9.2 Waterfall Life-Cycle Model 53 2.9.3 Rapid-Prototyping Life-Cycle

Model 55

2.9.4 Open-Source Life-Cycle Model 56 2.9.5 Agile Processes 59

2.9.6 Synchronize-and-Stabilize Life-Cycle Model 62

2.9.7 Spiral Life-Cycle Model 62 2.10 Comparison of Life-Cycle Models 66

Chapter 3

The Software Process 74 Learning Objectives 74 3.1 The Unifi ed Process 76

3.2 Iteration and Incrementation within the Object-Oriented Paradigm 76

3.3 The Requirements Workfl ow 78 3.4 The Analysis Workfl ow 80 3.5 The Design Workfl ow 82

3.6 The Implementation Workfl ow 83 3.7 The Test Workfl ow 84

3.7.1 Requirements Artifacts 84 3.7.2 Analysis Artifacts 84 3.7.3 Design Artifacts 85 3.7.4 Implementation Artifacts 85

3.8 Postdelivery Maintenance 87

v

(7)

vi Contents

3.9 Retirement 88

3.10 The Phases of the Unifi ed Process 88 3.10.1 The Inception Phase 89

3.10.2 The Elaboration Phase 91 3.10.3 The Construction Phase 92 3.10.4 The Transition Phase 92

3.11 One- versus Two-Dimensional Life-Cycle Models 92

3.12 Improving the Software Process 94 3.13 Capability Maturity Models 95 3.14 Other Software Process Improvement

Initiatives 98

3.15 Costs and Benefi ts of Software Process Improvement 99

Problems 103 References 104 Chapter 4

Teams 107

Learning Objectives 107 4.1 Team Organization 107

4.2 Democratic Team Approach 109 4.2.1 Analysis of the Democratic Team

Approach 110

4.3 Classical Chief Programmer Team Approach 110

4.3.1 The New York Times Project 112 4.3.2 Impracticality of the Classical Chief

Programmer Team Approach 113 4.4 Beyond Chief Programmer and

Democratic Teams 113

4.5 Synchronize-and-Stabilize Teams 117 4.6 Teams for Agile Processes 118 4.7 Open-Source Programming Teams 118 4.8 People Capability Maturity Model 119 4.9 Choosing an Appropriate Team

Organization 120 Chapter Review 121 For Further Reading 121 Key Terms 122

Chapter 5

The Tools of the Trade 124 Learning Objectives 124 5.1 Stepwise Refi nement 124

5.1.1 Stepwise Refi nement Mini Case Study 125

5.2 Cost–Benefi t Analysis 130 5.3 Divide-and-Conquer 132 5.4 Separation of Concerns 132 5.5 Software Metrics 133 5.6 CASE 134

5.7 Taxonomy of CASE 135 5.8 Scope of CASE 137

5.9 Software Versions 141 5.9.1 Revisions 141 5.9.2 Variations 142 5.10 Confi guration Control 143

5.10.1 Confi guration Control during Postdelivery Maintenance 145 5.10.2 Baselines 145

5.10.3 Confi guration Control during Development 146

5.11 Build Tools 146

5.12 Productivity Gains with CASE Technology 147

Testing 154

Learning Objectives 154

6.1 Quality Issues 155

6.1.1 Software Quality Assurance 156 6.1.2 Managerial Independence 156 6.2 Non-Execution-Based Testing 157

6.2.1 Walkthroughs 158

6.2.2 Managing Walkthroughs 158 6.2.3 Inspections 159

6.2.4 Comparison of Inspections and Walkthroughs 161

sch76183_FM-i-xx.indd vi

sch76183_FM-i-xx.indd vi 10/06/10 2:36 PM10/06/10 2:36 PM

(8)

6.2.5 Strengths and Weaknesses of Reviews 162

6.2.6 Metrics for Inspections 162 6.3 Execution-Based Testing 162 6.4 What Should Be Tested? 163

6.4.1 Utility 164 6.4.2 Reliability 164 6.4.3 Robustness 165 6.4.4 Performance 165 6.4.5 Correctness 166

6.5 Testing versus Correctness Proofs 167 6.5.1 Example of a Correctness Proof 167 6.5.2 Correctness Proof Mini Case Study 171 6.5.3 Correctness Proofs and Software

Engineering 172

6.6 Who Should Perform Execution-Based Testing? 175

6.7 When Testing Stops 176 Chapter Review 176 For Further Reading 177 Key Terms 177

From Modules to Objects 183 Learning Objectives 183

7.1 What Is a Module? 183 7.2 Cohesion 187

7.2.1 Coincidental Cohesion 187 7.2.2 Logical Cohesion 188 7.2.3 Temporal Cohesion 189 7.2.4 Procedural Cohesion 189 7.2.5 Communicational Cohesion 190 7.2.6 Functional Cohesion 190 7.2.7 Informational Cohesion 191 7.2.8 Cohesion Example 191 7.3 Coupling 192

7.3.1 Content Coupling 192 7.3.2 Common Coupling 193 7.3.3 Control Coupling 195 7.3.4 Stamp Coupling 195 7.3.5 Data Coupling 196 7.3.6 Coupling Example 197

7.3.7 The Importance of Coupling 198

7.4 Data Encapsulation 199 7.4.1 Data Encapsulation and

Development 201 7.4.2 Data Encapsulation and

Maintenance 202 7.5 Abstract Data Types 207 7.6 Information Hiding 209 7.7 Objects 211

7.8 Inheritance, Polymorphism, and Dynamic Binding 215

7.9 The Object-Oriented Paradigm 217 Chapter Review 220

For Further Reading 221 Key Terms 221

Reusability and Portability 225 Learning Objectives 225 8.1 Reuse Concepts 226 8.2 Impediments to Reuse 228 8.3 Reuse Case Studies 229

8.3.1 Raytheon Missile Systems Division 230

8.3.2 European Space Agency 231 8.4 Objects and Reuse 232

8.5 Reuse during Design and Implementation 232 8.5.1 Design Reuse 232

8.5.2 Application Frameworks 234 8.5.3 Design Patterns 235 8.5.4 Software Architecture 236 8.5.5 Component-Based Software

Engineering 237

8.6 More on Design Patterns 237 8.6.1 FLIC Mini Case Study 238 8.6.2 Adapter Design Pattern 239 8.6.3 Bridge Design Pattern 240 8.6.4 Iterator Design Pattern 241 8.6.5 Abstract Factory Design Pattern 241 8.7 Categories of Design Patterns 245 8.8 Strengths and Weaknesses of Design

Patterns 247

8.9 Reuse and the World Wide Web 248

(9)

viii Contents

8.10 Reuse and Postdelivery Maintenance 249 8.11 Portability 250

8.11.1 Hardware Incompatibilities 250 8.11.2 Operating System

Incompatibilities 251 8.11.3 Numerical Software

Incompatibilities 251

8.11.4 Compiler Incompatibilities 253 8.12 Why Portability? 255

8.13 Techniques for Achieving Portability 256 8.13.1 Portable System Software 257 8.13.2 Portable Application Software 257 8.13.3 Portable Data 258

8.13.4 Model-Driven Architecture 259 Chapter Review 259

Problems 261 References 263 CHAPTER 9

Planning and Estimating 268 Learning Objectives 268

9.1 Planning and the Software Process 268 9.2 Estimating Duration and Cost 270

9.2.1 Metrics for the Size of a Product 272 9.2.2 Techniques of Cost Estimation 275 9.2.3 Intermediate COCOMO 278 9.2.4 COCOMO II 281

9.2.5 Tracking Duration and Cost Estimates 282

9.3 Components of a Software Project Management Plan 282

9.4 Software Project Management Plan Framework 284

9.5 IEEE Software Project Management Plan 286

9.6 Planning Testing 288

9.7 Planning Object-Oriented Projects 289 9.8 Training Requirements 290

9.9 Documentation Standards 291 9.10 CASE Tools for Planning and

Estimating 292

9.11 Testing the Software Project Management Plan 292

PART B

THE WORKFLOWS OF THE SOFTWARE LIFE CYCLE 299 Chapter 10

Key Material from Part A 301 Learning Objective 301

10.1 Software Development: Theory versus Practice 301

10.2 Iteration and Incrementation 302 10.3 The Unifi ed Process 306 10.4 Workfl ow Overview 307 10.5 Teams 307

10.6 Cost–Benefi t Analysis 308 10.7 Metrics 308

10.8 CASE 308

10.9 Versions and Confi gurations 309

10.10 Testing Terminology 309

10.11 Execution-Based and Non-Execution- Based Testing 309

10.12 Modularity 310 10.13 Reuse 310

10.14 Software Project Management Plan 310 Chapter Review 311

Key Terms 311 Problems 312 Chapter 11

Requirements 313

11.1 Determining What the Client Needs 313 11.2 Overview of the Requirements

Workfl ow 314

11.3 Understanding the Domain 315 11.4 The Business Model 316

11.4.1 Interviewing 316 11.4.2 Other Techniques 317 11.4.3 Use Cases 318

sch76183_FM-i-xx.indd viii

sch76183_FM-i-xx.indd viii 10/06/10 2:36 PM10/06/10 2:36 PM

(10)

11.5 Initial Requirements 319

11.6 Initial Understanding of the Domain:

The MSG Foundation Case Study 320 11.7 Initial Business Model: The MSG

Foundation Case Study 322 11.8 Initial Requirements: The MSG

Foundation Case Study 326

11.9 Continuing the Requirements Workfl ow:

The MSG Foundation Case Study 328 11.10 Revising the Requirements: The MSG

11.11 The Test Workfl ow: The MSG Foundation Case Study 338

11.12 The Classical Requirements Phase 347

11.13 Rapid Prototyping 348 11.14 Human Factors 349

11.15 Reusing the Rapid Prototype 351

11.16 CASE Tools for the Requirements Workfl ow 353

11.17 Metrics for the Requirements Workfl ow 353

11.18 Challenges of the Requirements Workfl ow 354

Case Study Key Terms 357 Problems 357

References 358 Chapter 12

Classical Analysis 360 Learning Objectives 360

12.1 The Specifi cation Document 360

12.2 Informal Specifi cations 362

12.2.1 Correctness Proof Mini Case Study Redux 363

12.3 Structured Systems Analysis 364 12.3.1 Sally’s Software Shop Mini Case

Study 364

12.4 Structured Systems Analysis: The MSG Foundation Case Study 372

12.5 Other Semiformal Techniques 373 12.6 Entity-Relationship Modeling 374

12.7 Finite State Machines 376

12.7.1 Finite State Machines: The Elevator Problem Case Study 378

12.8 Petri Nets 382

12.8.1 Petri Nets: The Elevator Problem Case Study 385

12.9 Z 387

12.9.1 Z: The Elevator Problem Case Study 388

12.9.2 Analysis of Z 390 12.10 Other Formal Techniques 392 12.11 Comparison of Classical Analysis

Techniques 392

12.12 Testing during Classical Analysis 393 12.13 CASE Tools for Classical Analysis 394 12.14 Metrics for Classical Analysis 395 12.15 Software Project Management Plan: The

MSG Foundation Case Study 395 12.16 Challenges of Classical Analysis 396

Case Study Key Terms 398 Problems 398

References 400 Chapter 13

Object-Oriented Analysis 404 Learning Objectives 404

13.1 The Analysis Workfl ow 405 13.2 Extracting the Entity Classes 406 13.3 Object-Oriented Analysis: The Elevator

Problem Case Study 407

13.4 Functional Modeling: The Elevator Problem Case Study 407

13.5 Entity Class Modeling: The Elevator Problem Case Study 410

13.5.1 Noun Extraction 411 13.5.2 CRC Cards 413

13.6 Dynamic Modeling: The Elevator Problem Case Study 414

13.7 The Test Workfl ow: Object-Oriented Analysis 417

13.8 Extracting the Boundary and Control Classes 424

(11)

x Contents

13.9 The Initial Functional Model: The MSG Foundation Case Study 425

13.10 The Initial Class Diagram: The MSG Foundation Case Study 428

13.11 The Initial Dynamic Model: The MSG Foundation Case Study 430

13.12 Revising the Entity Classes: The MSG Foundation Case Study 432

13.13 Extracting the Boundary Classes: The MSG Foundation Case Study 434 13.14 Extracting the Control Classes: The MSG

Foundation Case Study 435 13.15 Use-Case Realization: The MSG

13.15.1 Estimate Funds Available for Week Use Case 436 13.15.2 Manage an Asset Use Case 442 13.15.3 Update Estimated Annual

Operating Expenses Use Case 446

13.15.4 Produce a Report Use Case 449 13.16 Incrementing the Class Diagram: The

MSG Foundation Case Study 454 13.17 The Test Workfl ow: The MSG Foundation

Case Study 456

13.18 The Specifi cation Document in the Unifi ed Process 456

13.19 More on Actors and Use Cases 457

13.20 CASE Tools for the Object-Oriented Analysis Workfl ow 458

13.21 Metrics for the Object-Oriented Analysis Workfl ow 459

13.22 Challenges of the Object-Oriented Analysis Workfl ow 459

Design 465

Learning Objectives 465 14.1 Design and Abstraction 466 14.2 Operation-Oriented Design 466

14.3 Data Flow Analysis 467

14.3.1 Mini Case Study Word Counting 468 14.3.2 Data Flow Analysis Extensions 473 14.4 Transaction Analysis 473

14.5 Data-Oriented Design 475 14.6 Object-Oriented Design 476

14.7 Object-Oriented Design: The Elevator Problem Case Study 477

14.8 Object-Oriented Design: The MSG Foundation Case Study 481 14.9 The Design Workfl ow 483 14.10 The Test Workfl ow: Design 487

14.11 The Test Workfl ow: The MSG Foundation Case Study 488

14.12 Formal Techniques for Detailed Design 488

14.13 Real-Time Design Techniques 488 14.14 CASE Tools for Design 490 14.15 Metrics for Design 490

14.16 Challenges of the Design Workfl ow 491 Chapter Review 492

Implementation 498

15.1 Choice of Programming Language 498

15.2 Fourth-Generation Languages 501 15.3 Good Programming Practice 504

15.3.1 Use of Consistent and Meaningful Variable Names 504

15.3.2 The Issue of Self-Documenting Code 505

15.3.3 Use of Parameters 507 15.3.4 Code Layout for Increased

Readability 507 15.3.5 Nested if Statements 507 15.4 Coding Standards 509

15.5 Code Reuse 510

15.6 Integration 510

15.6.1 Top-down Integration 511 15.6.2 Bottom-up Integration 513 15.6.3 Sandwich Integration 513

sch76183_FM-i-xx.indd x

sch76183_FM-i-xx.indd x 10/06/10 2:36 PM10/06/10 2:36 PM

(12)

15.6.4 Integration of Object-Oriented Products 514

15.6.5 Management of Integration 515

15.7 The Implementation Workfl ow 516 15.8 The Implementation Workfl ow: The MSG

15.9 The Test Workfl ow: Implementation 516 15.10 Test Case Selection 517

15.10.1 Testing to Specifi cations versus Testing to Code 517

15.10.2 Feasibility of Testing to Specifi cations 517

15.10.3 Feasibility of Testing to Code 518

15.11 Black-Box Unit-Testing Techniques 520 15.11.1 Equivalence Testing and Boundary

Value Analysis 521 15.11.2 Functional Testing 522 15.12 Black-Box Test Cases: The MSG

15.13 Glass-Box Unit-Testing Techniques 525 15.13.1 Structural Testing: Statement,

Branch, and Path Coverage 526 15.13.2 Complexity Metrics 527

15.14 Code Walkthroughs and Inspections 528 15.15 Comparison of Unit-Testing Techniques 528 15.16 Cleanroom 529

15.17 Potential Problems When Testing Objects 530

15.18 Management Aspects of Unit Testing 533 15.19 When to Reimplement Rather than Debug

a Code Artifact 533 15.20 Integration Testing 535 15.21 Product Testing 535 15.22 Acceptance Testing 536

15.23 The Test Workfl ow: The MSG Foundation Case Study 537

15.24 CASE Tools for Implementation 537 15.24.1 CASE Tools for the Complete

Software Process 538 15.24.2 Integrated Development

Environments 538 15.24.3 Environments for Business

Applications 539

15.24.4 Public Tool Infrastructures 540 15.24.5 Potential Problems with

Environments 540

15.25 CASE Tools for the Test Workfl ow 540 15.26 Metrics for the Implementation

Workfl ow 541

15.27 Challenges of the Implementation Workfl ow 542

Postdelivery Maintenance 551 Learning Objectives 551

16.1 Development and Maintenance 551

16.2 Why Postdelivery Maintenance Is Necessary 553

16.3 What Is Required of Postdelivery Maintenance Programmers? 553 16.4 Postdelivery Maintenance Mini Case

Study 555

16.5 Management of Postdelivery Maintenance 557

16.5.1 Defect Reports 557 16.5.2 Authorizing Changes to the

Product 558

16.5.3 Ensuring Maintainability 559 16.5.4 Problem of Repeated Maintenance 559

16.6 Maintenance of Object-Oriented Software 560

16.7 Postdelivery Maintenance Skills versus Development Skills 563

16.8 Reverse Engineering 563 16.9 Testing during Postdelivery

Maintenance 564

16.10 CASE Tools for Postdelivery Maintenance 565

16.11 Metrics for Postdelivery Maintenance 566

16.12 Postdelivery Maintenance: The MSG Foundation Case Study 566 16.13 Challenges of Postdelivery

Maintenance 566 Chapter Review 566 For Further Reading 567

(13)

xii Contents

Key Terms 567 Problems 567 References 568 Chapter 17

More on UML 571

Learning Objectives 571 17.1 UML Is Not a Methodology 571 17.2 Class Diagrams 572

17.2.1 Aggregation 573 17.2.2 Multiplicity 574 17.2.3 Composition 575 17.2.4 Generalization 576 17.2.5 Association 576 17.3 Notes 577

17.4 Use-Case Diagrams 577 17.5 Stereotypes 577

17.6 Interaction Diagrams 579 17.7 Statecharts 581

17.8 Activity Diagrams 583

17.9 Packages 585

17.10 Component Diagrams 586 17.11 Deployment Diagrams 586 17.12 Review of UML Diagrams 587 17.13 UML and Iteration 587

Emerging Technologies 590 Learning Objectives 590

18.1 Aspect-Oriented Technology 591 18.2 Model-Driven Technology 593 18.3 Component-Based Technology 594 18.4 Service-Oriented Technology 594 18.5 Comparison of Service-Oriented and

Component-Based Technology 595 18.6 Social Computing 596

18.7 Web Engineering 596

18.8 Cloud Technology 597 18.9 Web 3.0 598

18.10 Computer Security 598 18.11 Model Checking 598 18.12 Present and Future 599

References 600 Bibliography 601 Appendix A

Term Project: Chocoholics Anonymous 627

Appendix B

Software Engineering Resources 630 Appendix C

Requirements Workfl ow: The MSG Foundation Case Study 632

Appendix D

Structured Systems Analysis: The MSG Foundation Case Study 633

Appendix E

Analysis Workfl ow: The MSG Foundation Case Study 636

Appendix F

Software Project Management Plan: The MSG Foundation Case Study 637

Appendix G

Design Workfl ow: The MSG Foundation Case Study 642

Appendix H

Implementation Workfl ow: The MSG Foundation Case Study (C++ Version) 647

Appendix I

Implementation Workfl ow: The MSG Foundation Case Study (Java Version) 648

Appendix J

Test Workfl ow: The MSG Foundation Case Study 649

Author Index 651 Subject Index 654

sch76183_FM-i-xx.indd xii

sch76183_FM-i-xx.indd xii 10/06/10 2:36 PM10/06/10 2:36 PM

(14)

xiii

Preface

Almost every computer science and computer engineering curriculum now includes a required team-based software development project. In some cases, the project is only one semester or quarter in length, but a year-long team-based software development project is fast becoming the norm.

In an ideal world, every student would complete a course in software engineering before starting his or her team-based project (“two-stage curriculum”). In practice, however, many students have to start their projects partway through their software engineering course, or even at the beginning of the course (“parallel curriculum”).

As explained in the next section, this book is organized in such a way that it can be used for both curricula.

How the Eighth Edition Is Organized

The book comprises two main parts: Part B teaches the students how to develop a software product; Part A provides the necessary theoretical background for Part B. The 18 chapters are organized as follows:

Chapter 1 Introduction to software engineering Part A Chapters 2 through 9 Software engineering concepts Part B Chapters 10 through 17 Software engineering techniques

Chapter 18 Emerging technologies

Chapter 10 is new. It contains a summary of the key material of Part A. When the two-stage curriculum is followed, the instructor teaches fi rst Part A and then Part B (omitting Chapter 10, because the material of Chapter 10 will have been covered in depth in Part A). For the parallel curriculum, the instructor fi rst teaches Part B (so that the students can start their projects as soon as possible), and then Part A. The material of Chapter 10 enables the students to understand Part B without fi rst covering Part A.

This latter approach seems counterintuitive: Surely theory should always be taught before practice. In fact, curricular issues have forced many of the instructors who have used the seventh edition of this book to teach the material of Part B before Part A. Surpris- ingly, they have been most satisfi ed with the outcome. They report that their students have a greater appreciation of the theoretical material of Part A as a consequence of their project work. That is, team-based project work makes students more receptive to and understanding of the theoretical concepts that underlie software engineering.

In more detail, the material of the eighth edition may be taught in the following two ways:

1. Two-Stage Curriculum

Chapter 1 (Introduction to software engineering) Part A Chapters 2 through 9 (Software engineering concepts) Part B Chapters 11 through 17 (Software engineering techniques)

Chapter 18 (Emerging technologies)

The students then commence their team-based projects in the following semester or quarter.

(15)

2. Parallel Curriculum

Chapter 1 (Introduction to software engineering) Chapter 10 (Key material from Part A)

The students now commence their team-based projects, in parallel with studying the material of Part B.

Part B Chapters 11 through 17 (Software engineering techniques) Part A Chapters 2 through 9 (Software engineering concepts)

Chapter 18 (Emerging technologies)

New Features of the Eighth Edition

• The book has been updated throughout.

• I have added two new chapters. As previously explained, Chapter 10, a summary of key points of Part A, has been included so that this book can be used when students start their team-based term projects in parallel with their software engineering course. The other new chapter, Chapter 18, gives an overview of 10 emerging technologies, including

• Aspect-oriented technology

• Model-driven technology

• Component-based technology

• Service-oriented technology

• Social computing

• Web engineering

• Cloud technology

• Web 3.0

• Computer security

• Model checking

• I have considerably expanded the material on design patterns in Chapter 8, including a new mini case study.

• Two theoretical tools have been added to Chapter 5: divide-and-conquer, and separation of concerns.

• The object-oriented analysis of the elevator problem of Chapter 13 now refl ects a modern distributed, decentralized architecture.

• The references have been extensively updated, with an emphasis on current research.

• There are well over 100 new problems.

• There are new Just in Case You Wanted to Know boxes.

Features Retained from the Seventh Edition

• The Unifi ed Process is still largely the methodology of choice for object-oriented soft-

ware development. Throughout this book, the student is therefore exposed to both the theory and the practice of the Unifi ed Process.

• In Chapter 1, the strengths of the object-oriented paradigm are analyzed in depth.

xiv Preface

sch76183_FM-i-xx.indd xiv

sch76183_FM-i-xx.indd xiv 10/06/10 2:36 PM10/06/10 2:36 PM

(16)

• The iterative-and-incremental life-cycle model has been introduced as early as possible, namely, in Chapter 2. Furthermore, as with all previous editions, numerous other life-cycle models are presented, compared, and contrasted. Particular attention is paid to agile processes.

• In Chapter 3 (“The Software Process”), the workfl ows (activities) and processes of the Unifi ed Process are introduced, and the need for two-dimensional life-cycle models is explained.

• A wide variety of ways of organizing software teams are presented in Chapter 4 (“Teams”), including teams for agile processes and for open-source software development.

• Chapter 5 (“The Tools of the Trade”) includes information on important classes of CASE tools.

• The importance of continual testing is stressed in Chapter 6 (“Testing”).

• Objects continue to be the focus of attention in Chapter 7 (“From Modules to Objects”).

• Design patterns remain a central focus of Chapter 8 (“Reusability and Portability”).

• The IEEE standard for software project management plans is again presented in Chapter 9 (“Planning and Estimating”).

• Chapter 11 (“Requirements”), Chapter 13 (“Object-Oriented Analysis”), and Chapter 14 (“Design”) are largely devoted to the workfl ows (activities) of the Unifi ed Process. For obvious reasons, Chapter 12 (“Classical Analysis”) is largely unchanged.

• The material in Chapter 15 (“Implementation”) clearly distinguishes between implementation and integration.

• The importance of postdelivery maintenance is stressed in Chapter 16.

• Chapter 17 provides additional material on UML to prepare the student thoroughly for employment in the software industry. This chapter is of particular use to instructors who utilize this book for the two-semester software engineering course sequence. In the second semester, in addition to developing the team-based term project or a capstone project, the student can acquire additional knowledge of UML, beyond what is needed for this book.

• As before, there are two running case studies. The MSG Foundation case study and the Elevator Problem case study have been developed using the Unifi ed Process. As usual, Java and C++ implementations are available online at www.mhhe.com/schach.

• In addition to the two running case studies that are used to illustrate the complete life cycle, eight mini case studies highlight specifi c topics, such as the moving target problem, stepwise refi nement, design patterns, and postdelivery maintenance.

• In all the previous editions, I have stressed the importance of documentation, maintenance, reuse, portability, testing, and CASE tools. In this edition, all these concepts are stressed equally fi rmly. It is no use teaching students the latest ideas unless they appreciate the importance of the basics of software engineering.

• As in the seventh edition, particular attention is paid to object-oriented life-cycle models, object-oriented analysis, object-oriented design, management implications of the object-oriented paradigm, and the testing and maintenance of object-oriented software.

Metrics for the object-oriented paradigm also are included. In addition, many briefer references are made to objects, a paragraph or even only a sentence in length. The reason is that the object-oriented paradigm is not just concerned with how the various phases are performed but rather permeates the way we think about software engineering. Object technology again pervades this book.

(17)

• The software process is still the concept that underlies the book as a whole. To control the process, we have to be able to measure what is happening to the project. Accordingly, the emphasis on metrics continues. With regard to process improvement, the material on the capability maturity model (CMM), ISO/IEC 15504 (SPICE), and ISO/IEC 12207 has been retained.

• The book is still language independent. The few code examples are presented in C++

and Java, and I have made every effort to smooth over language-dependent details and ensure that the code examples are equally clear to C++ and Java users. For example, instead of using cout for C++ output and System.out.println for Java output, I have utilized the pseudocode instruction print . (The one exception is the new case study, where complete implementation details are given in both C++ and Java, as before.) • As in the seventh edition, this book contains over 600 references. I have selected current

research papers as well as classic articles and books whose message remains fresh and relevant. There is no question that software engineering is a rapidly moving fi eld, and students therefore need to know the latest results and where in the literature to fi nd them. At the same time, today’s cutting-edge research is based on yesterday’s truths, and I see no reason to exclude an older reference if its ideas are as applicable today as they originally were.

• With regard to prerequisites, it is assumed that the reader is familiar with a high-level programming language such as C, C#, C++, or Java. In addition, the reader is expected to have taken a course in data structures.

Why the Classical Paradigm Is Still Included

There is now almost unanimous agreement that the object-oriented paradigm is superior to the classical paradigm. Accordingly, many instructors who adopted the seventh edition of Object-Oriented and Classical Software Engineering chose to teach only the object- oriented material in that book. However, when asked, instructors indicated that they prefer to adopt a text that includes the classical paradigm.

The reason is that, even though more and more instructors teach only the object-oriented paradigm, they still refer to the classical paradigm in class; many object-oriented techniques are hard for the student to understand unless that student has some idea of the classical techniques from which those object-oriented techniques are derived. For example, understanding entity- class modeling is easier for the student who has been introduced, even superfi cially, to entity- relationship modeling. Similarly, a brief introduction to fi nite state machines makes it easier for the instructor to teach statecharts. Accordingly, I have retained classical material in the eighth edition, so that instructors have classical material available for pedagogical purposes.

The Problem Sets

As in the seventh edition, this book has fi ve types of problems. First, there are running object-oriented analysis and design projects at the end of Chapters 11, 13, and 14. These have been included because the only way to learn how to perform the requirements, analysis, and design workfl ows is from extensive hands-on experience.

Second, the end of each chapter contains a number of exercises intended to highlight key points. These exercises are self-contained; the technical information for all the exercises can be found in this book.

xvi Preface

sch76183_FM-i-xx.indd xvi

sch76183_FM-i-xx.indd xvi 10/06/10 2:36 PM10/06/10 2:36 PM

(18)

Third, there is a software term project. It is designed to be solved by students working in teams of three, the smallest number of team members that cannot confer over a standard telephone. The term project comprises 15 separate components, each tied to the relevant chapter. For example, design is the topic of Chapter 14, so in that chapter the component of the term project is concerned with software design. By breaking a large project into smaller, well-defi ned pieces, the instructor can monitor the progress of the class more closely. The structure of the term project is such that an instructor may freely apply the 15 components to any other project that he or she chooses.

Because this book has been written for use by graduate students as well as upper-class undergraduates, the fourth type of problem is based on research papers in the software engineering literature. In each chapter, an important paper has been chosen; wherever possible, a paper related to object-oriented software engineering has been selected. The student is asked to read the paper and answer a question relating to its contents. Of course, the instructor is free to assign any other research paper; the For Further Reading section at the end of each chapter includes a wide variety of relevant papers.

The fi fth type of problem relates to the case study. This type of problem was fi rst introduced in the third edition in response to a number of instructors who felt that their students learn more by modifying an existing product than by developing a new product from scratch.

Many senior software engineers in the industry agree with that viewpoint. Accordingly, each chapter in which the case study is presented has problems that require the student to modify the case study in some way. For example, in one chapter the student is asked to redesign the case study using a different design technique from the one used for the case study. In another chapter, the student is asked what the effect would have been of performing the steps of the object-oriented analysis in a different order. To make it easy to modify the source code of the case study, it is available on the Web at www.mhhe.com/schach.

The website also has material for instructors, including a complete set of PowerPoint lecture notes and detailed solutions to all the exercises as well as to the term project.

Material on UML

This book makes substantial use of UML (Unifi ed Modeling Language). If the students do not have previous knowledge of UML, this material may be taught in two ways. I prefer to teach UML on a just-in-time basis; that is, each UML concept is introduced just before it is needed.

The following table describes where the UML constructs used in this book are introduced.

Section in Which the Corresponding

Construct UML Diagram Is Introduced

Class diagram, note, inheritance (generalization), Section 7.7 aggregation, association, navigation triangle

Use case Section 11.4.3

Use-case diagram, use-case description Section 11.7

Stereotype Section 13.1

Statechart Section 13.6

Interaction diagram (sequence diagram, Section 13.15 communication diagram)

(19)

Alternatively, Chapter 17 contains an introduction to UML, including material above and beyond what is needed for this book. Chapter 17 may be taught at any time; it does not depend on material in the fi rst 16 chapters. The topics covered in Chapter 17 are as follows:

Section in Which the Corresponding

Construct UML Diagram Is Introduced

Class diagram, aggregation, multiplicity, Section 17.2 composition, generalization, association

Note Section 17.3

Use-case diagram Section 17.4

Stereotype Section 17.5

Interaction diagram Section 17.6

Statechart Section 17.7

Activity diagram Section 17.8

Package Section 17.9

Component diagram Section 17.10

Deployment diagram Section 17.11

Online Resources

A website to accompany the text is available at www.mhhe.com/schach. The website features Java and C++ implementations as well as source code for the MSG case study for students. For instructors, lecture PowerPoints, detailed solutions to all exercises and the term project, and an image library are available. For details, contact your sales representative.

Electronic Textbook Options

E-books are an innovative way for students to save money and create a greener environment at the same time. An e-book can save students about half the cost of a traditional textbook and offers unique features like a powerful search engine, highlighting, and the ability to share notes with classmates using e-books.

McGraw-Hill offers this text as an e-book. To talk about the e-book options, contact your McGraw-Hill sales representative or visit the site www.coursesmart.com to learn more.

Acknowledgments

I greatly appreciate the constructive criticisms and many helpful suggestions of the reviewers of the seven previous editions. Special thanks go to the reviewers of this edition, including

xviii Preface

Ramzi Bualuan

University of Notre Dame Ruth Dameron

University of Colorado, Boulder Werner Krandick

Drexel University

Mike McCracken

Georgia Institute of Technology Nenad Medvidovic

University of Southern California Saeed Monemi

California Polytechnic University, Pomona

sch76183_FM-i-xx.indd xviii

sch76183_FM-i-xx.indd xviii 10/06/10 2:36 PM10/06/10 2:36 PM

(20)

With regard to my publishers, McGraw-Hill, I am most grateful to copyeditor Kevin Camp- bell and designer Brenda Rolwes. A special word of thanks goes to Melissa Welch of Studio Montage, who transformed a photograph of Sydney Harbour Bridge at night into the stun- ning cover.

Special thanks also go to Jean Naudé (Vaal University of Technology, Secunda Campus) for co-authoring the Instructor’s Solution Manual. In particular, Jean provided a complete solution for the term project, including implementing it in both Java and C++. In the course of working on the ISM, Jean made numerous constructive suggestions for improving this book. I am most grateful to Jean.

Finally, as always, I thank my wife, Sharon, for her continual support and encourage- ment. As with all my previous books, I did my utmost to ensure that family commitments took precedence over writing. However, when deadlines loomed, this was not always possible. At such times, Sharon always understood, and for this I am most grateful.

It is my privilege to dedicate my fi fteenth book to my grandchildren, Jackson and Mikaela, with love.

Stephen R. Schach

Taehyung Wang

California State University, Northridge Jie Wei

City University of New York—City College

Xiaojun Qi

Utah State University

(21)

This page intentionally left blank

(22)

1

Chapter

1 The Scope of Software Engineering

Learning Objectives

After studying this chapter, you should be able to • Defi ne what is meant by software engineering.

• Describe the classical software engineering life-cycle model.

• Explain why the object-oriented paradigm is now so widely accepted.

• Discuss the implications of the various aspects of software engineering.

• Distinguish between the classical and modern views of maintenance.

• Discuss the importance of continual planning, testing, and documentation.

• Appreciate the importance of adhering to a code of ethics.

A well-known story tells of an executive who received a computer-generated bill for $0.00.

After having a good laugh with friends about “idiot computers,” the executive tossed the bill away. A month later, a similar bill arrived, this time marked 30 days. Then came the third bill. The fourth bill arrived a month later, accompanied by a message hinting at possible legal action if the bill for $0.00 was not paid at once.

The fi fth bill, marked 120 days, did not hint at anything—the message was rude and forthright, threatening all manner of legal actions if the bill was not immediately paid.

Fearful of his organization’s credit rating in the hands of this maniacal machine, the executive called an acquaintance who was a software engineer and related the whole sorry story.

Trying not to laugh, the software engineer told the executive to mail a check for $0.00. This had the desired effect, and a receipt for $0.00 was received a few days later. The executive meticulously fi led it away in case at some future date the computer might allege that $0.00 was still owed.

(23)

This well-known story has a less well-known sequel. A few days later, the executive was summoned by his bank manager. The banker held up a check and asked, “Is this your check?”

The executive agreed that it was.

“Would you mind telling me why you wrote a check for $0.00?” asked the banker.

So the whole story was retold. When the executive had fi nished, the banker turned to him and she quietly asked, “Have you any idea what your check for $0.00 did to our com- puter system?”

A computer professional can laugh at this story, albeit somewhat nervously. After all, every one of us has designed or implemented a product that, in its original form, would have resulted in the equivalent of sending dunning letters for $0.00. Up to now, we have always caught this sort of fault during testing. But our laughter has a hollow ring to it, because at the back of our minds is the fear that someday we will not detect the fault before the product is delivered to the customer.

A decidedly less humorous software fault was detected on November 9, 1979. The Strategic Air Command had an alert scramble when the worldwide military command and control system (WWMCCS) computer network reported that the Soviet Union had launched missiles aimed toward the United States [Neumann, 1980]. What actu- ally happened was that a simulated attack was interpreted as the real thing, just as in the movie WarGames some 5 years later. Although the U.S. Department of Defense understandably has not given details about the precise mechanism by which test data were taken for actual data, it seems reasonable to ascribe the problem to a software fault. Either the system as a whole was not designed to differentiate between simula- tions and reality or the user interface did not include the necessary checks for ensuring that end users of the system would be able to distinguish fact from fiction. In other words, a software fault, if indeed the problem was caused by software, could have brought civilization as we know it to an unpleasant and abrupt end. (See Just in Case You Wanted to Know Box 1.1 for information on disasters caused by other software faults.)

Whether we are dealing with billing or air defense, much of our software is delivered late, over budget, and with residual faults, and does not meet the client’s needs. Software engineering is an attempt to solve these problems. In other words, software engineering is a discipline whose aim is the production of fault-free software, delivered on time and within budget, that satisfi es the client’s needs. Furthermore, the software must be easy to modify when the user’s needs change.

The scope of software engineering is extremely broad. Some aspects of software engineering can be categorized as mathematics or computer science; other aspects fall into the areas of economics, management, or psychology. To display the wide-reaching realm of software engineering, we now examine fi ve different aspects.

1.1 Historical Aspects

It is a fact that electric power generators fail, but far less frequently than payroll products. Bridges sometimes collapse but considerably less often than operating systems. In the belief that software design, implementation, and maintenance could be put on the same

2 Chapter 1 The Scope of Software Engineering

sch76183_ch01_001-034.indd 2

sch76183_ch01_001-034.indd 2 04/06/10 12:30 PM04/06/10 12:30 PM

(24)

Just in Case You Wanted to Know ^{Box 1.1}

In the case of the WWMCCS network, disaster was averted at the last minute. However, the consequences of other software faults have been fatal. For example, between 1985 and 1987, at least two patients died as a consequence of severe overdoses of radiation delivered by the Therac-25 medical linear accelerator [Leveson and Turner, 1993]. The cause was a fault in the control software.

Also, during the 1991 Gulf War, a Scud missile penetrated the Patriot antimissile shield and struck a barracks near Dhahran, Saudi Arabia. In all, 28 Americans were killed and 98 wounded. The software for the Patriot missile contained a cumulative timing fault. The Patriot was designed to operate for only a few hours at a time, after which the clock was reset. As a result, the fault never had a signifi cant effect and therefore was not detected.

In the Gulf War, however, the Patriot missile battery at Dhahran ran continuously for over 100 hours. This caused the accumulated time discrepancy to become large enough to render the system inaccurate.

During the Gulf War, the United States shipped Patriot missiles to Israel for protection against the Scuds. Israeli forces detected the timing problem after only 8 hours and immediately reported it to the manufacturer in the United States. The manufacturer corrected the fault as quickly as it could, but tragically, the new software arrived the day after the direct hit by the Scud [Mellor, 1994].

Fortunately, it is extremely rare for death or serious injury to be caused by a software fault. However, one fault can cause major problems for thousands and thousands of people.

For example, in February 2003, a software fault resulted in the U.S. Treasury Department mailing 50,000 Social Security checks that had been printed without the name of the benefi ciary, so the checks could not be deposited or cashed [St. Petersburg Times Online, 2003]. In April 2003, borrowers were informed by SLM Corp. (commonly known as Sallie Mae) that the interest on their student loans had been miscalculated as a consequence of a software fault from 1992 but detected only at the end of 2002. Nearly 1 million borrowers were told that they would have to pay more, either in the form of higher monthly payments or extra interest payments on loans extending beyond their original 10-year terms [GJSenti- nel.com, 2003]. Both faults were quickly corrected, but together they resulted in nontrivial fi nancial consequences for about a million people.

The Belgian government overestimated its 2007 budget by €883,000,000 (more than

$1,100,000,000 at time of writing). This mistake was caused by a software fault compounded by the manual overriding of an error-detection mechanism [La Libre Online, 2007a;

2007b]. The Belgian tax authorities used scanners and optical character recognition software to process tax returns. If the software encountered an unreadable return, it recorded the taxpayer’s income as €99,999,999.99 (over $125,000,000). Presumably, the “magic number” €99,999,999.99 was chosen to be quickly detected by employees of the data processing department, so that the return in question would then be processed manually. This worked fi ne when the tax returns were analyzed for tax assessment purposes, but not when the tax returns were reanalyzed for budgetary purposes. Ironically, the software product did have fi lters to detect this sort of problem, but the fi lters were manually bypassed to speed up processing.

There were at least two faults in the software. First, the software engineers assumed that there would always be adequate manual scrutiny before further processing of the data.

Second, the software allowed the fi lters to be manually overridden.

(25)

footing as traditional engineering disciplines, a NATO study group in 1967 coined the term software engineering . The claim that building software is similar to other engineering tasks was endorsed by the 1968 NATO Software Engineering Conference held in Garmisch, Germany [Naur, Randell, and Buxton, 1976]. This endorsement is not too surprising; the very name of the conference refl ected the belief that software production should be an engineering-like activity (but see Just in Case You Wanted to Know Box 1.2). A conclusion of the conferees was that software engineering should use the philosophies and paradigms of established engineering disciplines to solve what they termed the software crisis , namely, that the quality of software generally was unacceptably low and that deadlines and budgets were not being met.

Despite many software success stories, an unacceptably large proportion of software products still are being delivered late, over budget, and with residual faults. For example, the Standish Group is a research fi rm that analyzes software development projects.

Their study of development projects completed in 2006 is summarized in Figure 1.1 [Rubenstein, 2007]. Only 35 percent of the projects were successfully completed, whereas 19 percent were canceled before completion or were never implemented. The remaining 46 percent of the projects were completed and installed on the client’s computer. How- ever, those projects were over budget, late, or had fewer features and functionality than initially specifi ed. In other words, during 2006, just over one in three software development projects was successful; almost half the projects displayed one or more symptoms of the software crisis.

As stated in Section 1.1, the aim of the Garmisch conference was to make software development as successful as traditional engineering. But by no means are all traditional engineering projects successful. For example, consider bridge building.

In July 1940, construction of a suspension bridge over the Tacoma Narrows, in Wash- ington State, was completed. Soon after, it was discovered that the bridge swayed and buckled dangerously in windy conditions. Approaching cars would alternately disappear into valleys and then reappear as that part of the bridge rose again. From this behavior, the bridge was given the nickname “Galloping Gertie.” Finally, on November 7, 1940, the bridge collapsed in a 42 mile per hour wind; fortunately, the bridge had been closed to all traffi c some hours earlier. The last 15 minutes of its life were captured on fi lm, now stored in the U.S. National Film Registry.

A somewhat more humorous bridge construction failure was observed in January 2004. A new bridge was being built over the Upper Rhine River near the German town of Laufenberg, to connect Germany and Switzerland. The German half of the bridge was designed and constructed by a team of German engineers; the Swiss half by a Swiss team. When the two parts were connected, it immediately became appar- ent that the German half was some 21 inches (54 centimeters) higher than the Swiss half. Major reconstruction was needed to correct the problem, which was caused by wrongly correcting for the fact that “sea level” is taken by Swiss engineers to be the average level of the Mediterranean Sea, whereas German engineers use the North Sea.

To compensate for the difference in sea levels, the Swiss side should have been raised 10.5 inches. Instead, it was lowered 10.5 inches, resulting in the gap of 21 inches [Spiegel Online, 2004].

Just in Case You Wanted to Know ^{Box 1.2}

sch76183_ch01_001-034.indd 4

sch76183_ch01_001-034.indd 4 04/06/10 12:30 PM04/06/10 12:30 PM