Behavioral Interface Speci cation Languages

speci cations are not a ected by changes of implementation details. In particular, clients that rely only on abstract speci cations need not be re-veri ed when the implementation of a module changes. Abstract speci cations tend to be simpler to write, read, and understand than implementation-dependent speci cations because they hide certain complications such as pointers, caches, etc. In the hash map example above, it is much simpler to specify a look-up in terms of a partial function than to describe it in terms of arrays of lists.speci cations tend to be simpler to write, read, and understand than implementation-dependent speci cations because they hide certain complications such as pointers, caches, etc. In the hash map example above, it is much simpler to specify a look-up in terms of a partial function than to describe it in terms of arrays of lists. Abstract speci cations are often expressed in terms of mathematical notions such as sets, sequences, relations, etc. Many theorem provers are equipped with various lemmas and tactics for these notions, which increases automation during the veri cation step.speci cations are often expressed in terms of mathematical notions such as sets, sequences, relations, etc. Many theorem provers are equipped with various lemmas and tactics for these notions, which increases automation during the veri cation step. Expressing behavior in terms of mathematical notions such as sets and functions allows one to formally connect the speci cation of a module to a high-level design speci cation written in languages such as VDM, Z, or B. This approach has been pioneered by the Larch project, which developed interface speci cation languages that make use of mathematical vocabulary expressed in the Larch Shared Language LSL [Guttag et al. 1993]. In all approaches to data abstraction, the idea is to present a higher-level, more abstract, view of what the module implements. For instance, one higher-level view of the stack module is as a mathematical sequence. The speci cations of the module's procedures can thus be given in terms of that abstract view, and the abstract view must be connected with the actual implementation. In speci cation languages that are built on a speci c mathematical vocabulary, such as VDM and the Larch family of interface speci cation languages, the abstract view is typically a value of a mathematical space such as a sequence. In a speci cation language without a de ned mathematical vocabulary, such as JML, the abstract view is de ned within the semantics of the programming language. JML provides a library of modeling classes that provide a JML representation of familiar mathematical concepts. For instance, the modeling class JMLObjectSequence represents sequences of objects. ACM Journal Name, Vol. V, No. N, October 2010. Speci cation Languages · 27 We explain four approaches to data abstraction: ghost variables, model variables, logic functions, and pure methods. 3.1. 1 Ghost Variables. One simple approach to data abstraction is to introduce ghost variables for the abstract view in the module interface. Fig. 7 shows a simple Counter class with JML speci cations. The ghost variable value is used to specify the behavior of increment and decrement without exposing implementation details. Changing the internal representation of the counter, for instance, to store the value explicitly, does not a ect the public speci cations. public class Counter { private int increments; private int decrements; //@ public ghost int value; //@ private invariant value == increments decrements; //@ public ensures value == \old(value) + 1; public void increment() { increments++; //@ set value = value + 1;