David L. Parnas is one of the grandmasters of software engineering. His academic research and industrial collaborations have exerted far-reaching influence on software design and development. His groundbreaking writings capture the essence of the innovations, controversies, challenges, and solutions of the software industry. Together, they constitute the foundation for modern software theory and practice.
This book contains thirty-three of his most influential papers in various areas of software engineering. Leading thinkers in software engineering have contributed short introductions to each paper to provide the historical context surrounding each paper's conception and writing.
Software Fundamentals: Collected Papers by David L. Parnas is a practical guide to key software engineering concepts that belongs in the library of every software professional. It introduces and explains such seminal topics as:
- Relational and tabular documentation
- Information hiding as the basis for modular program construction
- Abstract interfaces that provide services without revealing implementation
- Program families for the efficient development of multiple software versions
- The status of software engineering as a profession
- Why complex software, such as for the Strategic Defense Initiative, is unlikely to work the first time that it is used in the field
As a celebration of one of the fathers of modern software engineering, and as a practical guide to the key concepts underlying software development, Software Fundamentals is valuable for professionals, especially those who are interested in teaching the fundamentals of software.
David Parnas is highly regarded for his many valuable contributions to software engineering. He developed and applied cutting-edge software technology to the U.S. Navy's A-7E aircraft, and he advised the Atomic Energy Control Board of Canada on the use of safety-critical, real-time software. During his career, he has contributed more than 200 papers to ACM, IEEE, and ICSE publications. He won an ACM 'Best Paper' award, two 'Most Influential Paper' awards from ICSE, and the 1998 'Outstanding Researcher' award from ACM SIGSOFT. In May 2001, Dr. Parnas was recognized at the International Conference on Software Engineering for his lifetime of outstanding achievements.About the editors:
Daniel Hoffman is an Associate Professor of Computer Science at the University of Victoria in British Columbia. David Weiss is the Director of the Software Technology Research Department at Avaya Laboratories.
|Edition description:||New Edition|
|Product dimensions:||7.40(w) x 9.10(h) x 1.70(d)|
About the Author
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.
Table of Contents
I. DESCRIPTION AND SPECIFICATION.
David Lorge Parnas, P.Eng.
1. Using Assertions About Traces to Write Abstract Specifications for Software Modules (Wolfram Bartussek and David L. Parnas).
A FormalNotation for Specification Based on Traces.
Some Simple Examples.
Discussion of the Simple Examples.
A Compressed History of the Development of an Abstract Specification.
Conclusions.2. Less Restrictive Constructs for Structured Programs (David L. Parnas and William Wadge).
The State of a Computing Machine.
Control Constructs and Constructed Programs.
Defining the Semantics of Constructed Programs.
The Value of a Program.
The Syntax of the Constructs.
The Semantics of a Limited Component.
The Semantics of Limited Component Lists.
The Semantics of “;”.
The Semantics of “stop”, “go” and “init”.
Semantics of the Iterative Construct (it ti).
The Semantics of Parentheses.
The Value of “#”.
The Value Stack.
Exits and Entrances.
A Very Simple Example Done Three Ways.
The DEED Problem.
Conclusions.3. Predicate Logic for Software Engineering (David Lorge Parnas).
The Structure of This Paper.
Comparison with Other Work.
The Syntax of Logical Expressions.
The Meaning of Logical Expressions.
Examples of the Use of This Logic in Software Documentation.
Conclusions.4. Tabular Representations in Relational Documents (Ryszard Janicki, David Lorge Parnas, Jeffery Zucker).
A Relational Model of Documentation.
Industrial Experience with Relational Documentation.
Why Use Tabular Representations of Relations?
Formalisation of a Wide Class of Tables.
Transformations of Tables of One Kind to Another.
Conclusions.5. Precise Description and Specification of Software (D. L. Parnas).
On Foundational Research.
Language Is Not the Issue.
A Polemic About Four Words.
Four Types of Software Products.
Programs and Executions.
A Mathematical Interlude: LD-Relations.
Program Construction Tools.
Objects Versus Programs.
Descriptions and Specifications of Objects.
Conclusions.6. Specifying Software Requirements for Complex Systems: New Techniques and Their Application (Kathryn L. Heninger).
A-7 Program Characteristics.
Requirements Document Objectives.
Requirements Document Design Principles.
Techniques for Describing Hardware Interfaces.
Techniques For Describing Software Functions.
Techniques for Specifying Undesired Events.
Techniques for Characterizing Types of Changes.
II. SOFTWARE DESIGN.
7. On the Criteria to be Used in Decomposing Systems into Modules (D. L. Parnas).
A Brief Status Report.
Expected Benefits of Modular Programming.
What Is Modularization?
Example System 1: A KWIC Index Production System.
8. On a “Buzzword”: Hierarchical Structure (David Parnas).
General Properties of All Uses of the Phrase “Hierarchical Structure”.
9. Use of the Concept of Transparency in the Design of Hierarchically Structured Systems (D.L. Parnas and D.P. Diewiorek).
The “Top Down” or “Outside In” Approach.
“Transparency” of an Abstraction.
“Register” for Markov Algorithm Machine.
A Hardware Example.
An Unsolved Transparency Problem from the Operating System Area.
Outside In and Bottom Up Procedures in Combination.
10. On the Design and Development of Program Families (David L. Parnas).
Motivation for Interest in Families.
Classical Method of Producing Program Families.
Representing the Intermediate Stages.
Programming by Stepwise Refinement.
Technique of Module Specification.
Comparison Based on the KWIC Example.
Comparative Remarks Based on Dijkstra's Prime Program.
Comparative Remarks Based on an Operating System Problem.
Design Decisions in Stage 1.
How the Module Specifications Define a Family.
Which Method to Use.
Relation of the Question of Program Families to Program Generators.
11. Abstract Types Defined as Classes of Variables (D.L. Parnas, J.E. Shore, D.M. Weiss).
Motivations for Type Extensions.
A New Approach.
Applying These Concepts to Designing a Language.
12. Response to Undesired Events in Software Systems (D.L. Parnas, H.W. Wuerges).
Difficulties Introduced by a “Leveled Structure”.
The Effect of Undesired Events on Code Complexity.
Error Types and Direction of Propogation.
Continuation After UE “Handling”.
Specifying the Error Indications.
Redundancy and Efficiency.
Degrees of Undesired Events.
Appendix 12.A: Annotated Example of Module Design in Light of Errors.
13. Some Software Engineering Principles (David L. Parnas).
What Is a Well-Structured Program?
What Is a Module?
Two Techniques for Controlling the Structure of Systems Programs.
Hierarchical Structure and Subsetable Systems.
Designing Abstract Interfaces.
Conclusions.14. Designing Software for Ease of Extension and Contraction (David L. Parnas).
Software as a Family of Programs.
How Does the Lack of Subsets and Extensions Manifest Itself?
Steps Toward a Better Structure.
Example: An Address-Processing Subsystem.
Some Remarks on Operating Systems: Why Generals Are Superior to Colonels.
Summation.15. A Procedure for Designing Abstract Interfaces for Device Interface Modules (Kathryn Heninger Britton, R. Alan Parker, David L. Parnas).
Summary.16. The Modular Structure of Complex Systems (D.L. Parnas, P.C. Clements, D.M. Weiss).
Background and Guiding Principles.
A-7E Module Structure.
Conclusions.17. Active Design Reviews: Principles and Practices (David L. Parnas, David M. Weiss).
Objectives of Design Reviews.
Conventional Design Reviews.
A More Effective Review Process.
Conclusions.18. A Rational Design Process: How and Why to Fake It (David Lorge Parnas, Paul C. Clements).
The Search for the Philosopher's Stone: Why Do We Want a Rational Design Process?
Why Will a Software Design “Process” Always Be an Idealization?
Why Is a Description of a Rational Idealized Process Useful Nonetheless?
What Should the Description of the Development Process Tell Us?
What Is the Rational Design Process?
What Is the Role of Documentation in This Process?
Faking the Ideal Process.
Conclusion.19. Inspection of Safety Critical Software using Function Tables (David Lorge Parnas).
Safety-Critical Software in the Darlington Nuclear Power Generating Station.
Why Is Software Inspection Difficult?
The Inspection Process.
Hazard Analysis Using Functional Documentation.
III. CONCURRENCY AND SCHEDULING.
20. Concurrent Control with “Readers” and “Writers” (P.J. Courtois, F. Heymans, D.L. Parnas).
21. On a Solution to the Cigarette Smokers' Problem (Without Conditional Statements) (D.L. Parnas).
On Patil's Proof.
On a Complication Arising from the Introduction of Semaphore Arrays.
On the Yet Unsolved Problem.
On More Powerful Primitives.
22. On Synchronization in Hard-Real-Time Systems (Stuart R. Faulk and David L. Parnas).
The Need for a Separation of Concerns.
A Two-Level Approach to Synchronization.
Considerations at the Lower Level.
The Lower-Level Synchronization Primitives.
Considerations at the Upper Level.
The STE Synchronization Mechanisms.
Implementation in Terms of the Lower-Level Mechanism.
The Pre-Run-Time Scheduler.
Why Another Synchronization Mechanism?
Experience and Results.
23. Scheduling Processes with Release Times, Deadlines, Precedence, and Exclusion Relations (Jia Xu and David Lorge Parnas).
Overview of the Algorithm.
Notation and Definitions.
How to Improve on a Valid Initial Solution.
Searching for an Optimal or Feasible Solution.
Empirical Behavior of the Algorithm.
Appendix 23.A: An Implementation of the Procedure for Computing a Valid Initial Solution.
Appendix 23.B: An Implementation of the Main Algorithm.
Appendix 23.C: Examples 1$#150;5.
24. Building Reliable Software in Blowhard (David L. Parnas).
On “Building In”.
Four Views of a Programming Language.
Resolving Conflicts of Viewpoint in the Design of BLOWHARD.
What Is BLOWHARD?
Why This Farce?
25. The Impact of Money-Free Computer Assisted Barter Systems (David L. Parnas).
Money Versus Barter as a Mechanism for Exchanging Our Current Goods and Services.
Money Versus Barter for Future Sales?
What Would Barter Mean for Foreign Trade?
Are CABS a Dream or Are They Current Technology?
Turning Theory into Practice.
What Would Be the Net Effect of the Use of CABS?
Can a Materialistic, “Rational”, System Be Humane?
CABS and the Moral Illnesses in the Bishop's Report.
26. Software Aspects of Strategic Defense Systems (David Lorge Parnas).
Why Software Is Unreliable.
Why the SDI Software System Will Be Untrustworthy.
Why Conventional Software Development Does Not Produce Reliable Programs.
The Limits of Software Engineering Methods.
Artificial Intelligence and the Strategic Defense Initiative.
Can Automatic Programming Solve the SDI Software Problem?
Can Program Verification Make the SDI Software Reliable?
Is SDIO an Efficient Way to Fund Worthwhile Research?
27. SDI: A Violation of Professional Responsibility (David Lorge Parnas).
The Role of Computers.
My Decision to Act.
28. The Professional Responsibilities of Software Engineers (David Lorge Parnas).
Personal Responsibility, Social Responsibility, and Professional Responsibility.
The Social Responsibility of Scientists and Engineers.
The Professional Responsibilities of Engineers.
What Are the Obligations of the Engineer?
Professional Practice in Software Development.
A Simple Example, Pacemakers.
The “Know How” Isn't There.
How to Improve the Level of Professionalism in Software Development.
29. Software Aging (David Lorge Parnas).
The Causes of Software Aging.
The Costs of Software Aging.
Reducing the Costs of Software Aging.
Barriers to Progress.
Conclusions for Our Profession.
30. On ICSE's “Most Influential Papers” (David Lorge Parnas).
What Are the Best Papers of Our Most Important Software Engineering Conference?
We Must Be Doing Something(s) Wrong!
We Need to Change Something.
31. Teaching Programming as Engineering (David Lorge Parnas).
Programming Courses and Engineering.
The Important Characteristics of Programming Courses.
The Role of Mathematics in Engineering.
The Role of Programming in Engineering, Business, and Science.
The Content of Most “Standard” Programming Courses.
Programming Courses Are Not Science Courses.
A New Approach to Teaching Programming.
The Mathematics Needed for Professional Programming.
Teaching Programming with This Mathematical Background.
32. Software Engineering: An Unconsummated Marriage (David Lorge Parnas).
Software Engineering Education.
33. Who Taught Me About Software Engineering Research? (David Lorge Parnas, P.Eng.)
Whom to Thank?
Everard M. Williams.
Alan J. Perlis.
Leo Aldo Finzi.
Harlan D. Mills.
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.
Why Have Guest Introductions?
The papers span the period from the 1970s through the 1990s. Some use old examples and notations that may not seem relevant to today's Internet world. We asked leading members of our field to write short introductions to the papers to explain the papers' historical and modern relevance. Right from the start, we knew that the introductions must be fun to read and worth reading. They must tell the reader something worth knowing that is not in the paper or is not obvious from reading the paper.
We were most fortunate in gathering an impressive collection of authors. Some have been involved with Dave since his work at NRL and earlier. Others participated in the SCR Workshops that continued the NRL work. Some have never directly collaborated with Dave. All are excellent writers with special insights about the significance of the papers both at the time of writing and today. All wrote with enthusiasm and skill. The thirty-three paper introductions are an important contribution in their own right. The fact that these people were all willing, indeed eager, to contribute speaks highly of Dave's work.
Dave collaborated with us on the selection of the papers in this book. On several occasions he commented that we were likely to get people angry once again. That is the nature of the man and his ideas: insightful, creative, stimulating, provocative. We hope you find that the papers in this book have the same qualities. It is our present to Dave on his sixtieth birthday.
We would like to say that we had the idea for this book on our own, but it actually originated with Brad Appleton. Thanks, Brad, for giving us the chance to carry out the idea. Organizational and production details for a book of this sort can get quickly out of hand without an experienced professional editor to guide you. Debbie Lafferty at Addison-Wesley has been a cheerful, steadfast guide for us, appreciating the idea for the book from the first, and working with us to make it happen. During the course of production, all of the papers contained herein were retyped. Dorene Brummel happily took on the job of proofreading them, for which we are very grateful.
Joanne Glazer Weiss showed outstanding forebearance and support when her husband plunged into this project immediately after finishing his first book. He thanks and loves her.
Duck Bay, British Columbia