Contracts as protocols of interaction

\c{ Contracts as supported by Eiffel and Annotated C++ are a very powerful means of characterizing the interaction between a server object and a client object. However, with software becoming increasingly complex, what we need is a mechanism to characterize the behavior of collections of objects. In  [HHG90], an extended notion of contracts is introduced to characterize behavioral compositions, that is the constraints involved in the communication between objects that cooperate to perform a common task. } \c{ A contract (in the extended sense) lists the objects that participate in the task and characterizes the dependencies and constraints imposed on their mutual interaction. For example, the contract model-view, shown below (in a slightly different notation than the original presentation in  [HHG90]), introduces the object model and a collection of view objects. Also, it characterizes the minimal assumptions with respect to the functionality these objects must support and it gives an abstract characterization of the effect of each of the supported operations. } \nop{ In the following, we will a first attempt at exploring how contracts may aid in establishing the dynamic properties of a system. Beware, our presentation is rather sketchy and informal. No attempt has been made to rigorously define the constructs introduced. Instead, the notation employed is only meant to convey the basic intuitions underlying the notion of contracts. } \slide{3-MV}{The Model-View contract}{\slilarge
  contract model-view { 
\fbox{MV(C)}
subject : model supports [ state : V; value( val : V ) |-> [state = val]; notify(); notify() |-> \forall v \e views \bl v.update(); attach( v : view ) |-> v \e views; detach( v : view ) |-> v \not\e views; ] views : set where view supports [ update() |-> [view reflects state]; subject( m : model ) |-> subject = m; ] invariant: \forall v \e views \bl [v reflects subject.state] instantiation: \forall v \e views \bl subject.attach(v) & v.subject(subject); subject.notify(); }
} \c{ To indicate the type of variables, the notation v : type is used expressing that variable v is typed as type. The object subject of type model has an instance variable state of type V that represents (in an abstract fashion) the value of the model object. Methods are defined using the notation Actions may consist either of other method calls or conditions that are considered to be satisfied after calling the method. Quantification as for example in is used to express that the method update() is to be called for all elements in views. } \c{ The model-view contract specifies in more formal terms the MV part of the MVC paradigm discussed in section MVC. Recall, that the idea of a model-view pair is to distinguish between the actual information (which is contained in the model object) and the presentation of that information, which is taken care of by possibly multiple view objects. The actual protocol of interaction between a model and its view objects is quite straightforward. Each view object may be considered as a handler that must minimally have a method to install a model and a method update which is invoked, as the result of the model object calling notify, whenever the information contained in the model changes, as indicated by %D info. The effect of calling notify() is abstractly characterized as a universal quantification over the collection of view object. \nop{ Any object that conforms to the abstract description of a view may take the role of view in the contract. } Calling notify() for subject results in calling update() for each view. The meaning of update() is abstractly represented as which tells us that the state of the subject is adequately reflected by the view object. The invariant clause of the model-view contract states that every change of the (state of the) model will be reflected by each view. The instantiation clause describes, in a rather operational way, how to initialize each object participating in the contract. } \c{ In order to instantiate such a contract, we need to define appropriate classes realizing the abstract entities participating in the contract, and further we need to define how these classes are related to their abstract counterparts in the contract by means of what we may call, following  [HHG90], conformance declarations. Conformance declarations specify, in other words, how concrete classes embody an abstract role, similar as in the realization of a partial type by means of inheritance. }