Software Fundamentals Collected Papers by David L. Parnas

by Hoffman, Daniel M.; Weiss, David M.

ISBN13: 9780201703696
ISBN10: 0201703696
Edition: 1st
Format: Paperback
Copyright: 2001-04-09
Publisher: Addison-Wesley Professional

Your order must be $35 or more to qualify for free economy shipping. Bulk sales, PO's, Marketplace items, eBooks and apparel do not qualify for this offer.
1. Software Fundamentals Collected Papers by David L. Parnas > ISBN13: 9780201703696

List Price: $49.95

Summary

Daniel M. Hoffman and David M. Weiss

Why Create a Book Around Dave Parnas's Work?

It is sometimes said that progress in a scientific discipline can be measured by how quickly its founders are forgotten. Software development, sometimes called software engineering, is not a scientific discipline and is still young: Many of those who formulated fundamental principles in the field are still active in it. Unfortunately, we have the worst of both worlds: Our founders seem dimly remembered, and we are making little progress towards becoming a discipline. Fundamental ideas, such as information hiding and abstraction, are only vaguely understood by those who need them most and are constantly reinvented. Those who practice software development and those who teach software engineering seem uneducated in, and unaware of, the history of their profession.

This book is our attempt to provide a view of the work of one of the grandmasters of our field, highlighting the fundamental ideas that he and his colleagues invented and expounded. We hope to provide a reference for those who teach and those who do, giving them both an historical record, a clear explanation of fundamental ideas that will help them in their work, and a set of examples to use and emulate. David L. Parnas is both a clear and creative thinker and an extraordinary expositor of seminal ideas. The issues that he addresses are at the heart of software engineering today; his explanations are still relevant and his solutions, trialed on real systems, transfer to today's software development organizations and environments.

Do you need to understand how to organize your software into modules so it can be easily maintained and so that your modules are reusable, whether they are expressed as classes, packages, or other forms? Dave Parnas identified the information hiding principle and showed how to to use it to construct workable, reusable modular structures that are stable over time. (See Chapters 2 and 16.)

Are you struggling to create APIs to make your software useful to application programmers? Dave Parnas devised the idea (and coined the term) for abstract interfaces, and showed how to design interfaces that provide services without revealing their implementations. (See Chapter 15.) Languages like C++ and Java directly support this idea with abstract classes.

Are you wondering how to create your software as a set of layers that define a hierarchical structure that meets your requirements, lets you build your system a few layers at a time, and lets others add to the structure that you have created? Dave Parnas clearly explained what a hierarchical structure is, what some of the important hierarchical structures that we use are, why people often confuse them, and how to create a layered structure that meets your needs. (See Chapter 8.)

Do you know that your software is going to exist in many different versions, but are having difficulty designing your software not just to accommodate the different versions, but to take advantage of your situation to make your development process more efficient? Dave Parnas defined program families to help with just this situation and showed how to create them in a cost-effective way. (See Chapters 10 and 14.)

Dave has been busy in more than just technical areas. His work includes commentary on the social responsibility of software engineers, both by exposition and by example. His stance on our inability to create trustworthy software for the Strategic Defense Initiative is represented (Chapters 26 and 27), as well as his thoughts on how to teach software engineering (Chapter 31 and 32), and how to make software engineering a profession (Chapters 28 and 33).

Why Did We Pick These Papers?

The preceding are just a few examples of the ideas described in the papers that constitute this book. Out of the more than two hundred papers that Dave has published, we selected thirty-two, plus one special one that he did not write, but strongly influenced. We picked technical papers that expressed fundamental ideas that were groundbreaking when they were published, that have an enduring message, and that are models of exposition, and nontechnical papers that had an influence on the opinions of the time. Some were controversial when published and remain so.

An outstanding aspect of Dave's career is his insistence that his ideas be tested on real problems, where one cannot define away the complexity of the world in the interest of devising an elegant solution. Perhaps the best known examples are the operational flight program (OFP) for the U.S. Navy's A-7E aircraft and the shut-down software for the Darlington nuclear power plant.

The A-7E project, also known as the Software Cost Reduction (SCR) project, was conducted by Dave and colleagues at the U.S. Naval Research Laboratory (NRL). It was a demonstration of how to apply ideas such as information hiding, abstraction, cooperating sequential processes, deterministic scheduling, program families, formal specification, hierarchical structuring, and undesired event handling to the design of a hard-real-time system. Many of the same approaches now appear in modern designs and modern languages under different names; a few diverse examples are exception handling (Chapter 12) and the observer pattern (Chapter 22).

Several years of Dave's time and effort were directed at making the SCR software and its documentation an engineering model of how to develop and document software. The papers derived from the project that appeared in the research literature; such as Chapters 6, 12, 15, 16, 17, 18, and 22, only tell part of the story. The complete set of requirements and design documentation (including what we now term architecture), was published as technical reports by NRL and serve as detailed guides and templates for those wishing to use the ideas.

How Is the Book Organized?

This book contains thirty-three papers divided into four sections. Dave has written a short introduction to each section and we have invited a guest author to write an introduction to each paper.

Specification and Description contains six papers, focusing on the most important kinds of software engineering documentation and the roles that they play. Relational and tabular documentation are presented in depth, including both the underlying mathematical basis and practical notations suitable for use by working programmers.

Design contains thirteen papers, covering the principles and techniques that have been central to Dave's work for the past three decades. Information hiding is emphasized, including the role of information hiding in abstract interfaces, its application in complex systems, and its implications in the design of program families.

Concurrency and Scheduling contains two early papers on the use of semaphores and two more recent papers on new approaches to synchronization and scheduling. The latter focus on achieving bo

Author Biography

Daniel Hoffman is an Associate Professor of Computer Science at the University of Victoria in British Columbia.

David M. Weiss is the Director of the Software Production Research Department at Avaya Laboratories. His technical work has evolved into the invention of processes that incorporate ideas from families, design for change, measurement, precise specification, and technology transfer. The result has been a software production process based on family-oriented abstraction, specification, and translation, known as FAST.

0201703696AB04062001

Foreword

Preface

PART I DESCRIPTION AND SPECIFICATION

(136)

David Lorge Parnas

Introduction

(22)

John McLean

Using Assertions About Traces to Write Abstract Specifications for Software Modules

(1)

Wolfram Bartussek

David L. Parnas

Introduction

(3)

A Formal Notation for Specification Based on Traces

(3)

Some Simple Examples

(2)

Discussion of the Simple Examples

(2)

A Compressed History of the Development of an Abstract Specification

(7)

Conclusions

(3)

Introduction

(20)

William Wadge

Less Restrictive Constructs for Structured Programs

(1)

David L. Parnas

William Wedge

Abstract

(1)

Introduction

(1)

The State of a Computing Machine

(1)

Programs

(1)

Program Specifications

(1)

Primitive Programs

(1)

Control Constructs and Constructed Programs

(1)

Defining the Semantics of Constructed Programs

(1)

The Value of a Program

(1)

The Syntax of the Constructs

(1)

Notation

(1)

Guard Semantics

(1)

The Semantics of a Limited Component

(1)

The Semantics of Limited Component Lists

(1)

The Semantics of ``;''

(1)

The Semantics of ``stop'', ``go'' and ``init''

(1)

Semantics of the Iterative Construct (it ti)

(1)

The Semantics of Parentheses

(1)

The Value of ``#''

(1)

The Value Stack

(1)

Exists and Entrances

(1)

A Very Simple Example Done Three Ways

(1)

The DEED Problem

(1)

Conclusions

(7)

Introduction

(18)

Martin van Emden

Predicate Logic for Software Engineering

(1)

David Lorge Parnas

Abstract

(1)

Introduction

(1)

The Structure of This Paper

(1)

Comparison with Other Work

(2)

Basic Definitions

(2)

The Syntax of Logical Expressions

(1)

The Meaning of Logical Expressions

(2)

Examples of the Use of This Logic in Software Documentation

(3)

Conclusions

(4)

Introduction

(22)

Joanne Atlee

Tabular Representations in Relational Documents

(1)

Ryszard Janicki

David Lorge Parnas

Jeffery Zucker

Abstract

(1)

A Relational Model of Documentation

(2)

Industrial Experience with Relational Documentation

(2)

Why Use Tabular Representations of Relations?

(2)

Formalisation of a Wide Class of Tables

(5)

Transformations of Tables of One Kind to Another

(3)

Conclusions

(4)

Introduction

(18)

Ali Mili

Precise Description and Specification of Software

(1)

D.L. Parnas

Abstract

(1)

On Foundational Research

(1)

Language Is Not the Issue

(1)

A Polemic About Four Words

(2)

Four Types of Software Products

(1)

Programs and Executions

(1)

A Mathematical Interlude: LD-Relations

(1)

Program Construction Tools

(1)

Describing Programs

100

(2)

Specifying Programs

102

(2)

Objects Versus Programs

104

(1)

Descriptions and Specifications of Objects

104

(1)

Conclusions

105

(2)

Introduction

107

(30)

Kathyrn Heninger Britton

Specifying Software Requirements for Complex Systems: New Techniques and Their Application

111

(1)

Kathryn L. Heninger

Abstract

111

(1)

Introduction

111

(1)

A-7 Program Characteristics

112

(1)

Requirements Document Objectives

113

(1)

Requirements Document Design Principles

114

(2)

Techniques for Describing Hardware Interfaces

116

(5)

Techniques for Describing Software Functions

121

(9)

Techniques for Specifying Undesired Events

130

(1)

Techniques for Characterizing Types of Changes

131

(1)

Discussion

131

(1)

Conclusions

132

(5)

PART II SOFTWARE DESIGN

137

(246)

David Lorge Parnas

Introduction

143

(14)

David M. Weiss

On the Criteria to Be Used in Decomposing Systems into Modules

145

(1)

D.L. Parnas

Abstract

145

(1)

Introduction

145

(1)

A Brief Status Report

146

(1)

Expected Benefits of Modular Programming

146

(1)

What Is Modularization?

146

(1)

Example System 1: A KWIC Index Production System

146

(7)

Hierarchical Structure

153

(1)

Conclusions

154

(3)

Introduction

157

(14)

Paul C. Clements

On a ``Buzzword'': Hierarchical Structure

161

(1)

David Parnas

Abstract

161

(1)

Introduction

161

(1)

General Properties of All Uses of the Phrase ``Hierarchical Structure''

161

(7)

Summary

168

(3)

Introduction

171

(20)

Daniel Siewiorek

Use of the Concept of Transparency in the Design of Hierarchically Structured Systems

173

(1)

D.L. Parnas

D.P. Siewiorek

Abstract

173

(1)

Introduction

173

(1)

The ``Top Down'' or ``Outside In'' Approach

173

(2)

``Transparency'' of an Abstraction

175

(1)

Preliminary Example

175

(3)

``Register'' for Markov Algorithm Machine

178

(4)

A Hardware Example

182

(4)

An Unsolved Transparency Problem from the Operating System Area

186

(2)

``Suggestive Transparency''

188

(1)

``Misleading Transparency''

188

(1)

Outside In and Bottom Up Procedures in Combination

189

(2)

Introduction

191

(24)

Ralph Johnson

On the Design and Development of Program Families

193

(1)

David L. Parnas

Abstract

193

(1)

Introduction

193

(1)

Motivation for Interest in Families

194

(1)

Classical Method of Producing Program Families

194

(2)

New Techniques

196

(1)

Representing the Intermediate Stages

197

(1)

Programming by Stepwise Refinement

198

(2)

Technique of Module Specification

200

(1)

Comparison Based on the KWIC Example

201

(1)

Comparative Remarks Based on Dijkstra's Prime Program

202

(1)

Comparative Remarks Based on an Operating System Problem

202

(2)

Design Decisions in Stage 1

204

(1)

Stage 3

205

(3)

How the Module Specifications Define a Family

208

(1)

Which Method to Use

209

(1)

Relation of the Question of Program Families to Program Generators

210

(1)

Conclusions

210

(1)

Historical Note

211

(4)

Introduction

215

(14)

John Shore

Abstract Types Defined as Classes of Variables

217

(1)

D.L. Parnas

J.E. Shore

D.M. Weiss

Introduction

217

(1)

Previous Approaches

217

(1)

Motivations for Type Extensions

218

(2)

A New Approach

220

(6)

Applying These Concepts to Designing a Language

226

(3)

Introduction

229

(26)

Stuart Faulk

Response to Undesired Events in Software Systems

231

(1)

D.L. Parnas

H. Wurges

Abstract

231

(1)

Introduction

231

(2)

Difficulties Introduced by a ``Leveled Structure''

233

(1)

The Effect of Undesired Events on Code Complexity

233

(1)

Impossible Abstractions

234

(1)

Error Types and Direction of Propogation

235

(1)

Continuation After UE ``Handling''

236

(1)

Specifying the Error Indications

237

(3)

Redundancy and Efficiency

240

(1)

Degrees of Undesired Events

241

(3)

Examples

244

(1)

Conclusions

244

(11)

Annotated Example of Module Design in Light of Errors

247

(8)

Introduction

255

(12)

James Horning

Some Software Engineering Principles

257

(1)

David L. Parnas

Abstract

257

(1)

Introduction

257

(1)

What Is a Well-Structured Program?

258

(1)

What Is a Module?

259

(1)

Two Techniques for Controlling the Structure of Systems Programs

260

(1)

Results

261

(1)

Error Handling

262

(1)

Hierarchical Structure and Subsetable Systems

263

(1)

Designing Abstract Interfaces

263

(1)

Conclusions

264

(3)

Introduction

267

(24)

Barry Boehm

Designing Software for Ease of Extension and Contraction

269

(1)

David L. Parnas

Abstract

269

(1)

Introduction

269

(1)

Software as a Family of Programs

270

(1)

How Does the Lack of Subsets and Extensions Manifest Itself?

271

(2)

Steps Toward a Better Structure

273

(6)

Example: An Address-Processing Subsystem

279

(7)

Some Remarks on Operating Systems: Why Generals Are Superior to Colonels

286

(1)

Summation

286

(5)

Introduction

291

(24)

James Waldo

A Procedure for Designing Abstract Interfaces for Device Interface Modules

295

(1)

Kathryn Heninger Britton

R. Alan Parker

David L. Parnas

Abstract

295

(1)

Introduction

295

(1)

Objectives

296

(3)

Definitions

299

(2)

Design Approach

301

(6)

Design Problems

307

(6)

Summary

313

(2)

Introduction

315

(22)

David M. Weiss

The Modular Structure of Complex Systems

319

(1)

D.L. Parnas

P.C. Clements

D.M. Weiss

Abstract

319

(1)

Introduction

319

(2)

Background and Guiding Principles

321

(4)

A-7E Module Structure

325

(10)

Conclusions

335

(2)

Introduction

337

(16)

Kathryn Heninger Britton

Active Design Reviews: Principles and Practices

339

(1)

David L. Parnas

David M. Weiss

Abstract

339

(1)

Introduction

339

(1)

Objectives of Design Reviews

340

(1)

Conventional Design Reviews

341

(2)

A More Effective Review Process

343

(7)

Conclusions

350

(3)

Introduction

353

(16)

Barry Boehm

A Rational Design Process: How and Why to Fake It

355

(1)

David Lorge Parnas

Paul C. Clements

Abstract

355

(1)

The Search for the Philosopher's Stone: Why Do We Want a Rational Design Process?

355

(1)

Why Will a Software Design ``Process'' Always Be an Idealization?

356

(1)

Why Is a Description of a Rational Idealized Process Useful Nonetheless?

357

(1)

What Should the Description of the Development Process Tell Us?

358

(1)

What Is the Rational Design Process?

358

(6)

What Is the Role of Documentation in This Process?

364

(2)

Faking the Ideal Process

366

(1)

Conclusion

367

(2)

Introduction

369

(14)

A. John van Schouwen

Inspection of Safety-Critical Software Using Program-Function Tables

371

(1)

David Lorge Parnas

Abstract

371

(1)

Introduction

371

(2)

Safety-Critical Software in the Darlington Nuclear Power Generating Station

373

(1)

Why Is Software Inspection Difficult?

374

(1)

Functional Documentation

375

(1)

Program-Function Tables

376

(2)

The Inspection Process

378

(2)

Hazard Analysis Using Functional Documentation

380

(1)

Conclusions

380

(3)

PART III CONCURRENCY AND SCHEDULING

383

(84)

David Lorge Parnas

Introduction

387

(6)

Pierre-Jacques Courtois

Concurrent Control with ``Readers'' and ``Writers''

389

(1)

P.J. Courtois

F. Heymans

D.L. Parnas

Abstract

389

(1)

Introduction

389

(1)

Problem 1

389

(1)

Problem 2

390

(1)

Final Remarks

391

(2)

Introduction

393

(10)

Stuart Faulk

On a Solution to the Cigarette Smoker's Problem (without conditional statements)

395

(1)

D.L. Parnas

Abstract

395

(1)

Introduction

395

(2)

Comments

397

(1)

On Patil's Proof

397

(1)

Patil's Result

397

(1)

On a Complication Arising from the Introduction of Semaphore Arrays

398

(1)

On the Yet Unsolved Problem

398

(1)

On More Powerful Primitives

399

(4)

Introduction

403

(34)

Stuart Faulk

On Synchronization in Hard-Real-Time Systems

407

(1)

Stuart R. Faulk

David L. Parnas

Abstract

407

(1)

Introduction

407

(1)

The Need for a Separation of Concerns

408

(2)

A Two-Level Approach to Synchronization

410

(1)

Considerations at the Lower Level

410

(1)

The Lower-Level Synchronization Primitives

411

(2)

Considerations at the Upper Level

413

(5)

The STE Synchronization Mechanisms

418

(8)

Implementation in Terms of the Lower-Level Mechanism

426

(2)

The Pre-Run-Time Scheduler

428

(2)

Why Another Synchronization Mechanism?

430

(1)

Experience and Results

430

(2)

Summary

432

(5)

Introduction

437

(30)

Aloysius Mok

Scheduling Processes with Release Times, Deadlines, Precedence, and Exclusion Relations

439

(1)

Jia Xu

David Lorge Parnas

Abstract

439

(1)

Introduction

439

(3)

Overview of the Algorithm

442

(2)

Notation and Definitions

444

(3)

How to Improve on a Valid Initial Solution

447

(2)

Searching for an Optimal or Feasible Solution

449

(2)

Empirical Behavior of the Algorithm

451

(1)

Conclusions

452

(15)

An Implementation of the Procedure for Computing a Valid Initial Solution

455

(2)

An Implementation of the Main Algorithm

457

(3)

Examples 1--5

460

(7)

PART IV COMMENTARY

467

(140)

David Lorge Parnas

Introduction

471

(6)

James Horning

Building Reliable Software in Blowhard

473

(1)

David L. Parnas

Introduction

473

(1)

On ``Building In''

473

(1)

Four Views of a Programming Language

474

(1)

Resolving Conflicts of Viewpoints in the Design of Blowhard

474

(1)

What Is Blowhard?

475

(1)

Why This Farce?

475

(2)

Introduction

477

(16)

John Shore

The Impact of Money-Free Computer Assisted Barter Systems

479

(1)

David L. Parnas

Introduction

479

(1)

Money Versus Barter as a Mechanism for Exchanging Our Current Goods and Services

480

(4)

Money Versus Barter for Future Sales?

484

(2)

What Would Barter Mean for Foreign Trade?

486

(1)

Are CABS a Dream or Are They Current Technology?

487

(1)

Turning Theory into Practice

488

(2)

What Would Be the Net Effect of the Use of CABS?

490

(1)

Can a Materialistic, ``Rational'', System Be Humane?

490

(1)

CABS and the Moral Illnesses in the Bishop's Report

491

(2)

Introduction

493

(26)

David M. Weiss

Software Aspects of Strategic Defense Systems

497

(1)

David Lorge Parnas

Abstract

497

(1)

Introduction

497

(2)

Why Software Is Unreliable

499

(2)

Why the SDI Software System Will Be Untrustworthy

501

(3)

Why Conventional Software Development Does Not Produce Reliable Programs

504

(2)

The Limits of Software Engineering Methods

506

(4)

Artificial Intelligence and the Strategic Defense Initative

510

(2)

Can Automatic Programming Solve the SDI Software Problem?

512

(2)

Can Program Verification Make the SDI Software Reliable?

514

(2)

Is SDIO an Efficient Way to Fund Worthwhile Research?

516

(3)

SDI: A Violation of Professional Responsibility

519

(14)

David Lorge Parnas

Introduction

519

(1)

SDI Background

520

(2)

The Role of Computers

522

(1)

My Decision to Act

523

(1)

Critical Issues

524

(4)

Broader Questions

528

(5)

Introduction

533

(16)

Leonard L. Tripp

The Professional Responsibilities of Software Engineers

537

(1)

David Lorge Parnas

Abstract

537

(1)

Personal Responsibility, Social Responsibility, and Professional Responsibility

537

(1)

The Social Responsibility of Scientists and Engineers

538

(2)

The Professional Responsibilities of Engineers

540

(2)

What Are the Obligations of the Engineer?

542

(1)

Professional Practice in Software Development

543

(1)

A Simple Example, Pacemakers

543

(2)

Other Concerns

545

(1)

The ``Know How'' Isn't There

546

(1)

How to Improve the Level of Professionalism in Software Development

546

(3)

Introduction

549

(20)

Victor R. Basili

Software Aging

551

(1)

David Lorge Parnas

Abstract

551

(1)

What Nonsense!

551

(1)

The Causes of Software Aging

552

(1)

Kidney Failure

553

(1)

The Costs of Software Aging

553

(1)

Reducing the Costs of Software Aging

554

(1)

Preventive Medicine

555

(4)

Software Geriatrics

559

(3)

Planning Ahead

562

(1)

Barriers to Progress

563

(2)

Conclusions for Our Profession

565

(4)

Introduction

569

(8)

Richard Kemmerer

On ICSE's ``Most Influential'' Papers

571

(1)

David Lorge Parnas

Background

571

(1)

What Are the Best Papers of Our Most Important Software Engineering Conference?

571

(1)

We Must Be Doing Something(s) Wrong!

572

(3)

We Need to Change Something

575

(1)

Conclusions

576

(1)

Introduction

577

(16)

Daniel Hoffman

Teaching Programming as Engineering

579

(1)

David Lorge Parnas

Introduction

579

(1)

Programming Courses and Engineering

579

(1)

The Important Characteristics of Programming Courses

580

(1)

The Role of Mathematics in Engineering

581

(1)

The Role of Programming in Engineering, Business, and Science

581

(1)

The Content of Most ``Standard'' Programming Courses

582

(1)

Programming Courses Are Not Science Courses

582

(2)

A New Approach to Teaching Programming

584

(1)

The Mathematics Needed for Professional Programming

584

(3)

Teaching Programming with This Mathematical Background

587

(3)

Experience

590

(1)

Conclusions

591

(2)

Introduction

593

(4)

Victor R. Basili

Software Engineering: An Unconsummated Marriage

595

(1)

David Lorge Parnas

Software Engineering Education

595

(2)

Introduction

597

(10)

John Shore

Who Taught Me About Software Engineering Research?

599

(1)

David Lorge Parnas

Whom to Thank?

599

(1)

Everard M. Williams

599

(2)

Alan J. Perlis

601

(1)

Leo Aldo Finzi

602

(1)

Harlan D. Mills

603

(2)

Conclusions

605

(2)

PART V BIBLIOGRAPHY

607

(2)

Bibliography

609

(16)

Biographics

625

(6)

Credits

631

(4)

Index

635

Supplemental Materials

What is included with this book?

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.

Excerpts

Daniel M. Hoffman and David M. Weiss Why Create a Book Around Dave Parnas''s Work? It is sometimes said that progress in a scientific discipline can be measured by how quickly its founders are forgotten. Software development, sometimes called software engineering, is not a scientific discipline and is still young: Many of those who formulated fundamental principles in the field are still active in it. Unfortunately, we have the worst of both worlds: Our founders seem dimly remembered, and we are making little progress towards becoming a discipline. Fundamental ideas, such as information hiding and abstraction, are only vaguely understood by those who need them most and are constantly reinvented. Those who practice software development and those who teach software engineering seem uneducated in, and unaware of, the history of their profession. This book is our attempt to provide a view of the work of one of the grandmasters of our field, highlighting the fundamental ideas that he and his colleagues invented and expounded. We hope to provide a reference for those who teach and those who do, giving them both an historical record, a clear explanation of fundamental ideas that will help them in their work, and a set of examples to use and emulate. David L. Parnas is both a clear and creative thinker and an extraordinary expositor of seminal ideas. The issues that he addresses are at the heart of software engineering today; his explanations are still relevant and his solutions, trialed on real systems, transfer to today''s software development organizations and environments. Do you need to understand how to organize your software into modules so it can be easily maintained and so that your modules are reusable, whether they are expressed as classes, packages, or other forms? Dave Parnas identified the information hiding principle and showed how to to use it to construct workable, reusable modular structures that are stable over time. (See Chapters 2 and 16.) Are you struggling to create APIs to make your software useful to application programmers? Dave Parnas devised the idea (and coined the term) for abstract interfaces, and showed how to design interfaces that provide services without revealing their implementations. (See Chapter 15.) Languages like C++ and Java directly support this idea with abstract classes. Are you wondering how to create your software as a set of layers that define a hierarchical structure that meets your requirements, lets you build your system a few layers at a time, and lets others add to the structure that you have created? Dave Parnas clearly explained what a hierarchical structure is, what some of the important hierarchical structures that we use are, why people often confuse them, and how to create a layered structure that meets your needs. (See Chapter 8.) Do you know that your software is going to exist in many different versions, but are having difficulty designing your software not just to accommodate the different versions, but to take advantage of your situation to make your development process more efficient? Dave Parnas defined program families to help with just this situation and showed how to create them in a cost-effective way. (See Chapters 10 and 14.) Dave has been busy in more than just technical areas. His work includes commentary on the social responsibility of software engineers, both by exposition and by example. His stance on our inability to create trustworthy software for the Strategic Defense Initiative is represented (Chapters 26 and 27), as well as his thoughts on how to teach software engineering (Chapter 31 and 32), and how to make software engineering a profession (Chapters 28 and 33). Why Did We Pick These Papers? The preceding are just a few examples of the ideas described in the papers that constitute this book. Out of the more than two hundred papers that Dave has published, we selected thirty-two, plus one special one that he did not write, but strongly influenced. We picked technical papers that expressed fundamental ideas that were groundbreaking when they were published, that have an enduring message, and that are models of exposition, and nontechnical papers that had an influence on the opinions of the time. Some were controversial when published and remain so. An outstanding aspect of Dave''s career is his insistence that his ideas be tested on real problems, where one cannot define away the complexity of the world in the interest of devising an elegant solution. Perhaps the best known examples are the operational flight program (OFP) for the U.S. Navy''s A-7E aircraft and the shut-down software for the Darlington nuclear power plant. The A-7E project, also known as the Software Cost Reduction (SCR) project, was conducted by Dave and colleagues at the U.S. Naval Research Laboratory (NRL). It was a demonstration of how to apply ideas such as information hiding, abstraction, cooperating sequential processes, deterministic scheduling, program families, formal specification, hierarchical structuring, and undesired event handling to the design of a hard-real-time system. Many of the same approaches now appear in modern designs and modern languages under different names; a few diverse examples are exception handling (Chapter 12) and the observer pattern (Chapter 22). Several years of Dave''s time and effort were directed at making the SCR software and its documentation an engineering model of how to develop and document software. The papers derived from the project that appeared in the research literature; such as Chapters 6, 12, 15, 16, 17, 18, and 22, only tell part of the story. The complete set of requirements and design documentation (including what we now term architecture), was published as technical reports by NRL and serve as detailed guides and templates for those wishing to use the ideas. How Is the Book Organized? This book contains thirty-three papers divided into four sections. Dave has written a short introduction to each section and we have invited a guest author to write an introduction to each paper. Specification and Description contains six papers, focusing on the most important kinds of software engineering documentation and the roles that they play. Relational and tabular documentation are presented in depth, including both the underlying mathematical basis and practical notations suitable for use by working programmers. Design contains thirteen papers, covering the principles and techniques that have been central to Dave''s work for the past three decades. Information hiding is emphasized, including the role of information hiding in abstract interfaces, its application in complex systems, and its implications in the design of program families. Concurrency and Scheduling contains two early papers on the use of semaphores and two more recent papers on new approaches to synchronization and scheduling. The latter focus on achieving both good performance and a module structure that supports maintainability and comprehensibility. Finally, Commentary contains ten papers on a wide variety of topics including education, social issues, the role of the engineer, and the status of software engineering as an engineering profession. In the interests of preserving the historical record and of leaving Dave''s writing style unperturbed, we have tampered as little as possible with the papers that appear here, only correcting a few typographical errors in most papers.