Invited talk upon receiving the 2002 ICSE Most Influential Paper Award for ICSE 1992, at the 24th International Conference on Software Engineering (ICSE 2002), 22 May 2002.
2. Why Assertions?
The logical choice
The logical choice
for automated runtime fault detection
for automated runtime fault detection
in debugging, testing, maintenance, production
in debugging, testing, maintenance, production
Low development cost
Low overhead in execution time and object
code space
Highly effective fault detection
Informative diagnostics for fault isolation
High overall return on effort
3. 1967–1992:
Important Antecedents
Floyd (1967) and Hoare (1969)
Executable assertions
Algol W, Alphard, CLU, Euclid (mid 1970s)
Papers at 1975 Int’l Conf on Reliable Software
assert macro for C/Unix (1975)
Anna —ANNotated Ada (early 1980s)
Eiffel (1985)
Leveson, Chu, Knight and Shimeall study
(1990)
4. Problems with Assertions in 1992
Cumbersome and Inflexible
Separate tools for processing assertions
Difficult to selectively enable/disable assertions
Simplistic and Uninformative
C’s assert macro dumps core upon failure
Unproven
Some examples persuaded, others dissuaded
“It’s like writing the program twice.”
A notable exception: AT&T 5ESS Asserts
5. Why I Wrote This Paper
To find ways of increasing the
expressive power and flexibility of
assertions in development
To identify the kinds of assertions
that are effective at detecting faults
To provide practitioners with a useful
aid to writing assertions
6. Summary of the Paper (I)
An assertion language for C
Point assertions, preconditions, postconditions
Constrained quantifiers
Violation actions
Severity levels
An Assertion PreProcessor (APP) for C
A replacement for the C preprocessor in the
standard C compilation cycle
Minimal changes to compilation, makefiles
7. Summary of the Paper (II)
A case study: YEAST
Publish/subscribe middleware for Unix in LANs
Two-person effort
12,000 lines of C (including Yacc and Lex)
116 assertions in my part of the code
19 faults (10 in my part)
8 faults detected by assertion violations
6 others could have been detected
A classification of effective assertions
Assertions for function interfaces
Assertions for function bodies
8. 1992–2002:
Proliferation and Maturation
Assertions for OO
Meyer “Design by Contract” (Computer Oct 1992)
Java tools: iContract, Jcontract, Jass, …
Findler and Felleisen (ESEC/FSE 2001)
Sun’s Java JDK 1.4
Microsoft’s C#
Assertions for GNU
Phil Maker’s GNU Nana (1997)
Assertions for TCL
Jon Cook (1997)
Assertions for Testing:
Sankar and Hayes “Assertion Definition Language” (1994)
Assertions for UML
9. “Assertions” at PreCache
10 Engineers
Mostly prior Bell Labs research PhDs
150,000+ lines of distributed software
C, C++, Java, JNI
Fault Management Module
Components log significant execution errors,
warnings, exceptions, alerts, state changes, traces
Log file or separate fault management server
Assertion language is the programming language
Significant aid to fault detection and isolation
Recognizable patterns of log messages
10. Conclusion
Current state of technology offers hope for
use of assertions in 2012
Ubiquitous tool in development
First class consideration in development
processes
Standard feature of languages, compilers,
environments, infrastructures
Including improvements for COTS-based systems
Standard component of introductory programming
courses
11. References
The APP tool
http://www.research.att.com/sw/tools/reuse
Please don ’t send change requests to me
The paper
“Towards a Method of Programming with
Assertions”, Proceedings of ICSE ’92
The journal-length version
IEEE Transactions on Software Engineering,
January 1995
A minor correction
IEEE Transactions on Software Engineering,
March 1995