“Response to Undesired Events in Software Systems” by David Lorge Parnas
Response to Undesired Events in
Software Systems
by Dr. David Lorge Parnas
[1]
City University of New York /GC – Spring 2004
CSc 79000 - Software Engineering
Class summary - Submission
Professor Dr. D. Kopec
Prepared by Ellen Pesochin
03/05/04
Presentation Summary by Ellen Pesochin
page 1
“Response to Undesired Events in Software Systems” by David Lorge Parnas
A Little Bit of History:
Dr. David L. Parnas wrote several papers in the 1970’s and 1980’s that are now
considered classics. The concepts he advocated such as information hiding and use of
abstract interfaces are generally accepted as the appropriate way to design nontrivial
software systems. However, not all of what he proposed has been full appreciated and
assimilated into our practices. Many of his simple, elegant ideas have been lost amongst
the hype surrounding the technologies and methods that have arisen in the past two
decades.
State of practice at the time of this papers writing is such that programs should be
designed and implemented correctly, therefore there should be little need to handle
unexpected events. Dr. Parnas argues that it is foolhardy to assume program correctness
We observe that the ideas in this paper sound a lot like the structured exception handling
mechanisms used in modern day languages. Even with programs proven to be correct we
should expect errors at run-time because incorrect data or inconsistent data may be
supplied to the system, hardware may fail and cause system inconsistency, programs are
changed from time to time and new errors may appear
Undesired Events (UE) in Software System:
Undesired doesn’t mean Unexpected
An Undesired Event is any event that results in a deviation from normal behavior. It’s not
an “error”, which should be corrected. This paper recognizes an essentially undependable
nature of a real world execution environment. Its main contribution was in recognition of
constantly existing aspect of program’s execution environment that do not behave as well
as we all wish. A simple fact of life: Things go wrong, things fail, things change and/or
we make incorrect assumptions. Problems that are arise not from programming, but are
unavoidable consequences of execution in the real time and real world environment.
Authors of the paper focus on detecting, responding and handling UEs. They propose an
approach to handling UEs based on the concept of hardware “traps” for error detection
and recovery. Dr. Parnas extends this notion to software detected events by viewing UEs
as the trap mechanism for an abstract machine. The approach inherits key feature of
hardware traps: the ability to separate the code handling undesired events and treat it as a
distinct concept and the ability to invoke different event handling routines depending on
the error context. Main idea is to detect UEs at lower levels of the program and handle
them at higher program levels.
Propagation of UE:
Idea is to handle the UE at the highest level that makes sense, i.e. detect UE at the lower
levels of program execution, but propagate the UE to higher program levels for servicing.
Any level from the level detecting the UE on up can handle the UE –if the UE cannot be
03/05/04
Presentation Summary by Ellen Pesochin
page 2
“Response to Undesired Events in Software Systems” by David Lorge Parnas
handled at the current level it should be propagated upward. As a last resort the UE
should be reported to the user –typically results in the process being aborted.
Specification of Indicators:
A program built with UE in mind will be better insulated from errors. The constraints
which “trigger” UE will be checked multiple times (each transition from a higher to a
lower level). Redundancy promotes reliability. But when a module is designed and
specified, there are many things especially limitations need to be considered and here are
the main ones:










Limitations on the Values of Parameters
Capacity Limitations
Requests for Undefined Information
Restrictions on the Order of Operations
Detection of Actions Which are Likely to be Unintentional
Sufficiency
UE should be Prioritized
The number of UE
Program State Management
Reporting UE
Degrees of UE and Their Handling:
UE mechanisms must provide some context for the UE. Not all UE can be handled
abstractly –specific information about the UE may be required to facilitate proper
recovery from it. This implication is somewhat less abstract than desired (information
hiding), but it is an appropriate compromise.
When it comes to the degrees of UEs there is a basic model of the system that recognizes
two different types of incidents:
 Incidents which result in crashes (no recovery)
 Incidents which can be fully recovered
The UE model can be designed with greater granularity. When it is not a binary outcome
(fail, continue as if no error has occurred) the programmer must specify what they mean
by “correct UE handling” and priority of handling:
 Orders of degree
 Orders of aims
 Orders of action
03/05/04
Presentation Summary by Ellen Pesochin
page 3
“Response to Undesired Events in Software Systems” by David Lorge Parnas
Conclusion:
Main ideas that are conveyed by the authors are:
1. UE are developed in response to events generated by the abstract machine
2. UE detection, UE correction, and the normal program code should be separated
and be able to be modified independently
3. A system can evolve from a version with very little recovery to one that has
advanced recovery mechanisms without changing the structure of the system
4. Locating modules that trigger UE should be fast and efficient
5. The cost of implementing a program with UE should be low but the cost of
handling individual UE may vary
This paper almost predicts verbatim how UE (exceptions) are handled in modern day
programming languages and programming techniques
 Exceptions can be compartmentalized and/or flexibly propagated upward
 Exceptions are based on “stock” objects, “custom” objects, or objects customized
from “stock” objects
 Exceptions are managed as objects, enabling simple extension
 Some languages (Visual Basic) still retain a “trap like” interface for UE –The "on
error" go to statement.
In today's infrastructure centric software development model, handling UE properly is a
paramount requirement
Reference:
1. D. L. Parnas H. Würges. “Response to Undesired Events in Software Systems ",
IEEE Computer Society Press, Proceedings of the 2nd International conference on
Software Engineering San Francisco, California, (1976) Pages:437-446
03/05/04
Presentation Summary by Ellen Pesochin
page 4