- Used Books
- Staff Picks
- Gifts & Gift Cards
- Sell Books
- Stores & Events
- Let's Talk Books
Special Offers see all
More at Powell's
Recently Viewed clear list
Used Trade Paper
Ships in 1 to 3 days
More copies of this ISBN
Software Fundamentals: Collected Papers by David L. Parnasby Daniel Hoffman
Synopses & Reviews
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:
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.
Book News Annotation:
Collects 33 of Parnas's most influential papers on software documentation, design, concurrency and scheduling, and non- technical issues. Leading thinkers in software engineering contribute short introductions to set each paper's conception and writing in historical context. Topics include relational and tabular documentation, information hiding as the basis for modular program construction, abstract interfaces that provide services without revealing implementation, and program families for the efficient development of multiple software versions.
Annotation c. Book News, Inc., Portland, OR (booknews.com)
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.
What Our Readers Are Saying
Other books you might like