CSC/ECE 517 Fall 2007/wiki3 2 at

Programming by contract

Programming by Contract is a way of specifying the behavior of a function, and the name arises from its formal similarity to a legal contract. The preconditions define the conditions whose truth the caller guarantees to ensure before calling the function, and the postconditions define the conditions whose truth the function guarantees to establish by virtue of its execution. One of the purposes in this is to avoid redundant validity checks at each level in a stack of called functions.

Example 1

Consider the following example for counting the number of vowles [1]:

int is_vowelpair (const char *p)  
{
    return is_vowel(*p) && is_vowel (*(p+1));
}

int count_vowelpairs (char *s)
{ 
    int sum = 0;
    
    for (; *s != '\0'; s++)
        if (is_vowelpair(s))
            sum++;
    return sum;
} 

The functions count_vowelpairs receive as input argument a pointer to a C string. Neither function applies any validity check to the pointer, so there is an implicit precondition that the caller supply a valid pointer. To follow the rules of programming by contract we should make this an explicit precondition, albeit one that is so common and obvious that it hardly seems to need stating.

There are four possibilities for the pointer passed in as argument:

It contains a valid address that is indeed the address of a valid C string (including the null string). It contains a valid address but the memory at that address does not comprise a valid C string. It contains a bit pattern that is not a valid address (e.g., it is outside the addressing range, or the memory is not readable). It contains the null pointer. Our contract imposes the precondition that the pointer must be valid as specified in the first case above. There is no reasonable way to detect the second case, and for the third case it is usual to delegate detection (and handling) to the exception mechanism of the operating system11.

The fourth case is the interesting one. Null is a valid value for a pointer, but it is (by definition) an invalid address that will generally cause an addressing exception if dereferenced. It is, however, trivial for the function to detect that a null pointer argument has been passed. Therefore, we can propose a general rule that makes life easier for callers of a function: If a pointer to a null object is a valid argument, a null pointer should also be a valid argument with the same meaning. In the specific examples we are studying here, we should change the contract by weakening the precondition to allow the first and fourth cases, and implement the function to immediately return the value 0 if a null pointer is passed as the argument. The purpose of this rule is to relieve callers of the need to make the test for a null pointer; for a language like C the gain is not obvious, but for functional style languages like Lisp the gain is significant.

Example 2

Consider the following sort function in python [3]:

def sort(a):
    """Sort a list *IN PLACE*.

    pre:
        # must be a list
        isinstance(a, list)

        # all elements must be comparable with all other items
        forall(range(len(a)),
               lambda i: forall(range(len(a)),
                                lambda j: (a[i] < a[j]) ^ (a[i] >= a[j])))

    post[a]:
        # length of array is unchanged
        len(a) == len(__old__.a)

        # all elements given are still in the array
        forall(__old__.a, lambda e: __old__.a.count(e) == a.count(e))

        # the array is sorted
        forall([a[i] >= a[i-1] for i in range(1, len(a))])

This tells us everything we need to know about sort. During debugging, these statements are actually executed. If any of the pre-conditions are false, an exception is raised so the caller can be debugged. If any of the post-conditions are false, a similar exception is raised so the sort function can be debugged.

A programming language called Eiffel was created to facilitate Design by Contract. Eiffel provides built-in features to support the implementation of Design by Contract. The example below illustrates those features:

Example 3

The following example shows a partial implementation of a bounded queue, with methods put and remove. The pre- and post-conditions for those methods are coded explicitly with the "require" and "ensure" features of Eiffel.

                class BoundedQueue[G] feature
                    put(x:G) is
                       -- add x as newest element
                       require
                           not full
                       do
                           -- implementation of put
                           . . .
                       ensure
                           not empty
                       end;
                    remove is
                       -- remove oldest element
                       require
                           not empty
                       do
                           -- implementation of remove
                           . . .
                       ensure
                           not full
                       end;
                           empty: BOOLEAN is
                               -- is the queue empty?
                               do Result:=. . . end;
                           full: BOOLEAN is
                               -- is the queue full?
                               do Result:=. . . end;
                       end

The assertions are checked at run-time. This checking can be turned on or off as a result of a compilation switch.

Programming by contract places responsibility squarely on the shoulders of the caller for ensuring that specified preconditions for a function are met, and relieves the function of any responsibility for verifying that preconditions are met. As intended, this has the desirable effect of eliminating redundant validity checking. In real life, however, it also has an undesirable side effect: If the caller makes a mistake and does not in fact meet the preconditions, the function is likely to fail, and the cause of the failure may be difficult to track down. A pointer that is null or contains an invalid address is usually easy to diagnose; since an exception will be caused immediately an attempt is made to deference it, but other errors may cause failures far removed from the root cause.

See Also

http://en.wikibooks.org/wiki/Computer_programming/Design_by_Contract http://www.eventhelix.com/RealtimeMantra/Object_Oriented/design_by_contract.htm http://www.cs.uno.edu/~c1581/Labs2006/lab7/lab7.htm http://www.phpunit.de/pocket_guide/3.2/en/test-first-programming.html http://www.python.org/dev/peps/pep-0316/ http://www.artima.com/cppsource/deepspace2.html http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html

References

[1] http://www.ibm.com/developerworks/rational/library/455.html#N10324
[2] http://archive.eiffel.com/doc/manuals/technology/contract/page.html
[3] http://www.wayforward.net/pycontract/ [4] http://www.patentstorm.us/patents/6442750-description.html