A Tool for Writing and Debugging Algebraic Specifications Johannes Henkel * and Amer Diwan * {henkel,diwan}@cs.colorado.edu Abstract Despite their benefits, programmers rarely use formal specifications, because they are difficult to write and they require an up front investment in time. To addressthese is- sues, we present a tool that helps programmers write and debug algebraic specifications. Given an algebraic specifi- cation, our tool instantiates a prototype that can be used just like any regular Java class. The tool can also mod- ify an existing application to use the prototype generated by the interpreter instead of a hand-coded implementation. The tool improves the usability of algebraic specifications in the following ways: (i) A programmer can “run” an al- gebraic specification to study its behavior. The tool reports in which way a specification is incomplete for a client appli- cation. (ii) The tool can check whether a specification and a hand-coded implementation behave the same for a par- ticular run of a client application. (iii) A prototype can be used when a hand-coded implementation is not yet avail- able. Two case studies demonstrate how to use the tool. 1. Introduction Formal specifications have many software engineering benefits. Perhaps the most important advantage of formal specifications is that they can provide an unambiguous and possibly machine checkable documentation of an interface. Clients of the specified interfaces know exactly what the in- terface provides and can therefore use it correctly. Program- mers implementing the interface know exactly how an im- plementation of the interface should behave and therefore have a gold standard with which to test their implementa- tion. Unfortunately, most programmers do not write formal specifications because they are difficult to write and require significant mathematical maturity on the part of program- mers. This paper describes and evaluates a tool for develop- ing algebraic specifications. * This work is supported by NSF grants CCR-0085792, CCR-0133457, and CCR-0086255. Any opinions, fi ndings and conclusions or recom- mendations expressed in this material are the authors’ and do not nec- essarily reflect those of the sponsors. There are many kinds of formal specifications, each with their own strengths and weaknesses. For example, ax- iomatic specifications (e.g., [12]) are well suited for describ- ing how methods manipulate the state of an object. They are thus valuable for programmers who try to understand and extend an existing implementation [9]. On the other hand, for programmers who are interested in using a partic- ular class without worrying about the implementation de- tails, understanding axiomatic specifications can be cum- bersome. In contrast, for certain classes, in particular many container classes, algebraic specifications (e.g., [13]) can be short and elegant; they often provide the advantage of capturing the observable behavior without exposing the im- plementation details of objects. Since container classes are among the most frequently reused classes, and thus partic- ularly benefit from machine checkable documentation, we focus only on algebraic specifications in this paper. Given an algebraic specification for a class and a client for the class, our tool runs the client using interpreta- tion to simulate the behavior of the specified class. In this way, when a programmer writes an algebraic specification, the system automatically provides an implementation. Our tool interprets algebraic specifications using term rewriting, which is a well studied area [6, 20]. However, to our knowl- edge our system is the first to seamlessly integrate fully au- tomatic algebraic rewriting techniques with Java classes. Our system provides three main benefits. First, it gives programmers more for their effort: they not only get the benefit of a formal specification but they also get a prototype of their class, which they can immediately use. This feature may be particularly useful in multi-programmer projects since it allows the developers of some components to test against specifications of other components before those are even implemented. Second, by providing a feature for ex- perimentally validating a specification against an imple- mentation, our tool helps prevent divergence of implemen- tation and its specification as the software system evolves. Third, our system is invaluable for debugging algebraic specifications since it allows programmers to “run” a spec- ification and observe its behavior. When running a specifi- cation, there are three possible outcomes: (i) the run pro- duces correct answers, which suggests that the specification may be sound and complete; (ii) the run produces incor-