From software design and specification to the social impact of technology, few software engineers have had the insight -- or the impact -- of David L. Parnas. Now, two leaders of the software engineering community have selected, annotated, and brought together 30 of Parnas' best papers: a lifetime of best practices that will be invaluable to every software practitioner -- and anyone who cares about the deeper meaning of information technology. Every article in this collection addresses a key problem in software development -- and presents insights that are as valuable now as when Parnas first shared them.

Table of Contents:
Foreword. Preface. 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). Introduction. 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). Abstract. Introduction. The State of a Computing Machine. Programs. Program Specifications. Primitive Programs. Control Constructs and Constructed Programs. Defining the Semantics of Constructed Programs. The Value of a Program. The Syntax of the Constructs. Notation. Guard Semantics. 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). Abstract. Introduction. The Structure of This Paper. Comparison with Other Work. Basic Definitions. 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). Abstract. 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). Abstract. 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. Describing Programs. Specifying Programs. Objects Versus Programs. Descriptions and Specifications of Objects. Conclusions. 6. Specifying Software Requirements for Complex Systems: New Techniques and Their Application (Kathryn L. Heninger). Abstract. Introduction. 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. Discussion. Conclusions. II. SOFTWARE DESIGN. 7. On the Criteria to be Used in Decomposing Systems into Modules (D. L. Parnas). Abstract. Introduction. A Brief Status Report. Expected Benefits of Modular Programming. What Is Modularization? Example System 1: A KWIC Index Production System. Hierarchical Structure. Conclusions. 8. On a “Buzzword”: Hierarchical Structure (David Parnas). Abstract. Introduction. General Properties of All Uses of the Phrase “Hierarchical Structure”. Summary. 9. Use of the Concept of Transparency in the Design of Hierarchically Structured Systems (D.L. Parnas and D.P. Diewiorek). Abstract. Introduction. The “Top Down” or “Outside In” Approach. “Transparency” of an Abstraction. Preliminary Example. “Register” for Markov Algorithm Machine. A Hardware Example. An Unsolved Transparency Problem from the Operating System Area. “Suggestive Transparency”. “Misleading Transparency”. Outside In and Bottom Up Procedures in Combination. 10. On the Design and Development of Program Families (David L. Parnas). Abstract. Introduction. Motivation for Interest in Families. Classical Method of Producing Program Families. New Techniques. 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. Stage 3. How the Module Specifications Define a Family. Which Method to Use. Relation of the Question of Program Families to Program Generators. Conclusions. Historical Note. 11. Abstract Types Defined as Classes of Variables (D.L. Parnas, J.E. Shore, D.M. Weiss). Introduction. Previous Approaches. 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). Abstract. Introduction. Difficulties Introduced by a “Leveled Structure”. The Effect of Undesired Events on Code Complexity. Impossible Abstractions. Error Types and Direction of Propogation. Continuation After UE “Handling”. Specifying the Error Indications. Redundancy and Efficiency. Degrees of Undesired Events. Examples. Conclusions. Appendix 12.A: Annotated Example of Module Design in Light of Errors. 13. Some Software Engineering Principles (David L. Parnas). Abstract. Introduction. What Is a Well-Structured Program? What Is a Module? Two Techniques for Controlling the Structure of Systems Programs. Results. Error Handling. Hierarchical Structure and Subsetable Systems. Designing Abstract Interfaces. Conclusions. 14. Designing Software for Ease of Extension and Contraction (David L. Parnas). Abstract. Introduction. 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). Abstract. Introduction. Objectives. Definitions. Design Approach. Design Problems. Summary. 16. The Modular Structure of Complex Systems (D.L. Parnas, P.C. Clements, D.M. Weiss). Abstract. Introduction. Background and Guiding Principles. A-7E Module Structure. Conclusions. 17. Active Design Reviews: Principles and Practices (David L. Parnas, David M. Weiss). Abstract. Introduction. 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). Abstract. 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). Abstract. Introduction. Safety-Critical Software in the Darlington Nuclear Power Generating Station. Why Is Software Inspection Difficult? Functional Documentation. Program-Function Tables. The Inspection Process. Hazard Analysis Using Functional Documentation. Conclusions. III. CONCURRENCY AND SCHEDULING. 20. Concurrent Control with “Readers” and “Writers” (P.J. Courtois, F. Heymans, D.L. Parnas). Abstract. Introduction. Problem 1. Problem 2. Final Remarks. 21. On a Solution to the Cigarette Smokers' Problem (Without Conditional Statements) (D.L. Parnas). Abstract. Introduction. Comments. On Patil's Proof. Patil's Result. 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). Abstract. Introduction. 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. Summary. 23. Scheduling Processes with Release Times, Deadlines, Precedence, and Exclusion Relations (Jia Xu and David Lorge Parnas). Abstract. Introduction. 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. Conclusions. 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. IV. COMMENTARY. 24. Building Reliable Software in Blowhard (David L. Parnas). Introduction. 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). Introduction. 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). Abstract. Introduction. 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). Introduction. SDI Background. The Role of Computers. My Decision to Act. Critical Issues. Broader Questions. 28. The Professional Responsibilities of Software Engineers (David Lorge Parnas). Abstract. 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. Other Concerns. The “Know How” Isn't There. How to Improve the Level of Professionalism in Software Development. 29. Software Aging (David Lorge Parnas). Abstract. What Nonsense! The Causes of Software Aging. Kidney Failure. The Costs of Software Aging. Reducing the Costs of Software Aging. Preventive Medicine. Software Geriatrics. Planning Ahead. Barriers to Progress. Conclusions for Our Profession. 30. On ICSE's “Most Influential Papers” (David Lorge Parnas). Background. What Are the Best Papers of Our Most Important Software Engineering Conference? We Must Be Doing Something(s) Wrong! We Need to Change Something. Conclusions. 31. Teaching Programming as Engineering (David Lorge Parnas). Introduction. 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. Experience. Conclusions. 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. Conclusions. V. BIBLIOGRPAHY. Bibliography. Bibliographies. Credits. Index.