2004 hawaii inter conf comp sci1 specifying and proving object- oriented programs arthur c. fleck...

2004 Hawaii Inter Conf Comp Sci 1

Specifying and Proving Object-Oriented Programs

Arthur C. Fleck

Computer Science Department

University of Iowa


A specification should allow for many implementations.

An implementation may be based on a variety of data

structures and algorithms. Nonetheless, a specification

precisely describes the “essential behavior” of each

implementation.


An object is a collection of functions that share a state. — Peter Wegner


An object is a collection of functions that share a state. — Peter Wegner

BUT the function concept is a “stateless” idea —

every time a function is called with the same

arguments, it returns the same value.


The Abstract Data Type (ADT) methodology is a well-

established means of describing a collection of

functions and the domains on which they operate.

The ADT methodology avoids all representation details of

the functions and their domains, and expresses only the

“essential properties”.


Example — Stack ADT

Signatures

new: Stack

push: Stack, Integer Stack

pop: Stack Stack

top: Stack Integer

Equations (for all sStack, i Integer):

pop(push(s, i)) = s

top(push(s, i)) = i


Notice that in the Stack ADT example, the domain

of Stack values remains completely abstract — no

implementation details are presumed. Also, no

algorithms are provided for the operations, but

their essential properties (LIFO) are effectively

indicated.


This conventional ADT methodology is our starting

point and we seek to formalize the incorporation of a

shared state in this context.

A primary goal is to retain the abstractness inherent

in the ADT methodology so that the state component

also avoids presuming any representation details.


To avoid all state representation details, we adopt a

history perspective. That is, since an object has local

memory, it may respond differently each time an

identical message is sent. These behavioral differences

are ascribed to the history of prior messages received

by the object.


The methods of a class are characterized according to

their dependence on local storage. The options are:

state-independent — its results depend only on its

arguments;

state-dependent — a result may depend on the state

of the receiving object.


Methods are also characterized according to their

effect on local state. The options are:

side-effect free — execution never changes the state,

only a functional result is produced;

side-effect inducing — execution may change the state as well as yielding a result.


The two characteristics we have just identified divide

the methods of a class into up to four categories.

An Abstract Object Class (AOC) incorporates a finite

collection of abstract data domains including a state set,

a finite collection of message identifiers together with

their signatures and state related categories, and a

finite collection of semantic equations.


From this perspective, an ADT is just an AOC each

of whose operations is state-independent and side-

effect free.

As already required for ADTs, we find it necessary to

admit “hidden methods” in AOCs. We also allow

methods to incorporate “hidden arguments” — this is

the role played by an object’s states.


Each state-dependent method with argument types

A1, … , An has functional (i.e., visible) signature

: A1, … , An Result

This reflects the syntax with which is used in client

code. But state-dependent methods are regarded as

having a hidden argument which is the state of the

receiving object, and its behavioral signature is

: State, A1, … , An Result

where 'State' is the abstract state set of the class,


Each side-effect inducing method with argument

types A1, … , An has functional (i.e., visible) signature

: A1, … , An Result

This reflects the syntax with which is used in client

code.

A side-effect inducing method may also be state-

dependent, in which case it also has a corresponding

behavioral signature as indicated previously.


Since they are hidden functions, the state transition

functions cannot be invoked explicitly by client code.

However, each invocation of a side-effect inducing

function is understood to also implicitly invoke the

associated state transition function.

Each side-effect inducing method has an associated

hidden state transition function with signature

: State, A1, … , An State

where 'State' is the abstract state set of the class.


With these conventions, we have identified a collection

of functions, all with abstract domains, and including

a shared abstract state set. We can now proceed to

specify these functions using methodology similar to

that for ADTs!


The history perspective is applied by specifying the behavior of sequences of messages rather than individual messages.

The abstract state of an object is expressed as the sequence of all messages received by the object.


Example — Histogram AOC, informal description

The histogram is a commonly used aggregation of

values that may be inspected, graphed, etc. For

illustration we include the following methods.

empty — the initial, empty histogram

tally(v) — add value v to receiving histogram

high — return the greatest value in the histogram

low — return the least value in the histogram

sampleSize — return the number of values in the histogram


Histogram Example — formal description

The only method with side effects is 'tally'. All of

the methods are state-dependent (and so have a

hidden State argument), except for 'empty'. For

signatures:

tally: Value Histogram

tally: State, Value State (hidden)

high: Value

low: Value

sampleSize: Integer


Histogram Example continued

tally(s,v) = s^'tally'(v) (^ is concatenation)

high(s^'tally'(v)) = if s='empty' then v

else max(v, high(s))

sampleSize('empty') = 0

sampleSize(s^'tally'(v)) = if s='empty'

then 1

else 1+sampleSize(s)


With this specification, the instance variable

structure of an implementation is not dictated.

Whether instance variables are used to hold e.g.

high and low values or not remains the option of

the implementor while the essential behavior is

still clearly indicated.


Notice that the transition function definition for the

tally method is especially simple — on the right-

hand side, the new invocation is just concatenated

on the end. While they can be defined equationally,

transition function definitions are so trivial that we

would normally leave them implicit in the

understanding of an abstract state as the sequence

of all messages received by an object.


Since what remains is a collection of functions,

conventional ADT-like methodology suffices to

formalize their description. The extensions we

require are hidden arguments, plus the coupling

of each transition function invocation with the

invocation of its side-effect inducing method.

This accomplishes the formalization of Peter

Wegner’s intuition of an object as a collection of

functions that share a state.

2004 hawaii inter conf comp sci1 specifying and proving object- oriented programs arthur c. fleck...

Documents

stack stack

conf comp scinotice

conf comp scito

conf comp scifrom

conf comp scimethods

local state

conf comp scian object

state set