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.

1. Assertions a Decade Later
David S. Rosenblum
PreCache, Inc.
&
UC Irvine

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