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

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

Table of Contents

Foreword	ix
Preface	xi
PART I DESCRIPTION AND SPECIFICATION	1	(136)
David Lorge Parnas
Introduction	7	(22)
John McLean
Using Assertions About Traces to Write Abstract Specifications for Software Modules	9	(1)
Wolfram Bartussek
David L. Parnas
Introduction	9	(3)
A Formal Notation for Specification Based on Traces	12	(3)
Some Simple Examples	15	(2)
Discussion of the Simple Examples	17	(2)
A Compressed History of the Development of an Abstract Specification	19	(7)
Conclusions	26	(3)
Introduction	29	(20)
William Wadge
Less Restrictive Constructs for Structured Programs	31	(1)
David L. Parnas
William Wedge
Abstract	31	(1)
Introduction	31	(1)
The State of a Computing Machine	32	(1)
Programs	32	(1)
Program Specifications	32	(1)
Primitive Programs	33	(1)
Control Constructs and Constructed Programs	34	(1)
Defining the Semantics of Constructed Programs	34	(1)
The Value of a Program	34	(1)
The Syntax of the Constructs	34	(1)
Notation	35	(1)
Guard Semantics	35	(1)
The Semantics of a Limited Component	36	(1)
The Semantics of Limited Component Lists	36	(1)
The Semantics of ``;''	36	(1)
The Semantics of ``stop'', ``go'' and ``init''	36	(1)
Semantics of the Iterative Construct (it ti)	37	(1)
The Semantics of Parentheses	38	(1)
The Value of ``#''	38	(1)
The Value Stack	39	(1)
Exists and Entrances	39	(1)
A Very Simple Example Done Three Ways	40	(1)
The DEED Problem	41	(1)
Conclusions	42	(7)
Introduction	49	(18)
Martin van Emden
Predicate Logic for Software Engineering	51	(1)
David Lorge Parnas
Abstract	51	(1)
Introduction	51	(1)
The Structure of This Paper	52	(1)
Comparison with Other Work	53	(2)
Basic Definitions	55	(2)
The Syntax of Logical Expressions	57	(1)
The Meaning of Logical Expressions	58	(2)
Examples of the Use of This Logic in Software Documentation	60	(3)
Conclusions	63	(4)
Introduction	67	(22)
Joanne Atlee
Tabular Representations in Relational Documents	71	(1)
Ryszard Janicki
David Lorge Parnas
Jeffery Zucker
Abstract	71	(1)
A Relational Model of Documentation	71	(2)
Industrial Experience with Relational Documentation	73	(2)
Why Use Tabular Representations of Relations?	75	(2)
Formalisation of a Wide Class of Tables	77	(5)
Transformations of Tables of One Kind to Another	82	(3)
Conclusions	85	(4)
Introduction	89	(18)
Ali Mili
Precise Description and Specification of Software	93	(1)
D.L. Parnas
Abstract	93	(1)
On Foundational Research	93	(1)
Language Is Not the Issue	94	(1)
A Polemic About Four Words	95	(2)
Four Types of Software Products	97	(1)
Programs and Executions	98	(1)
A Mathematical Interlude: LD-Relations	99	(1)
Program Construction Tools	99	(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

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.

Rewards Program

Currently unavailable