\c{

Model-based specification

Contracts and the specification of behavioral types have a close relationship to a possible implementation in an object oriented language such as Eiffel or C++. However, we may wish to employ a richer specification language to specify the functionality of a system, without regard to an immediate implementation in some programming language. Traditionally, a distinction is made between model-based specification techniques (exemplified by VDM [Jones] and Z [DillerXX]) and property-based or algebraic specification formalisms (such as OBJ [XXX] for sequential systems or process algebra [BergXX] that may be used to characterize concurrent systems). \nop{ To conclude our exploration of formal methods that may support object oriented development, we will briefly look at the (model-based) specification language Z and provide some references to research concerning formalisms to model the interaction between objects. } In section algebraicXX we have looked at algebraic specifications of abstract data types. As an example of a model-based specification formalism we will briefly look at Z. } \c{ The specification language Z is based on classical (two-valued) logic and set theory. It has been used in a number of industrial projects (see [Hayes]) and to specify the architecture of complex intelligent systems (see [AAXX]). The central compositional unit of specification in Z is the schema. A schema may be used to specify both states and operations in a logical way. The logic employed in Z is a typed logic. The specification of a schema consists of a number of declarations followed by constraints specifying conditions on the variables introduced in the declarations. Declarations may include other schemas, as for example in the example specification of the operation op. The schema %D state itself is a compound schema that results from the logical conjunction of the schema state and its primed version state', which denotes state after applying op. } \slide{10-model}{Model-based specification}{

State and operations

}{

Specifying state and operations

}

Z

Change and invariance

Verification

} \c{ Both schema inclusion and schema conjunction are examples of the powerful schema calculus supported by Z, which enables the user to specify complex systems in Z. Moreover, schemas may be decorated in order to specify the effects of an operation. Invariance may be specified as in %X state, which expresses that the state before the applying the operation is the same as the state (denoted by state') after applying the operation. Because schemas are specified in a logical manner, both pre-conditions and post-conditions are implicitly specified by the constraints included in the schema. Hence, to verify that an operation op is legal for a state it is merely required to verify that the conditions specified for state hold and that, together with the pre-conditions (that are implicitly specified by the schema for op) they imply the logical formula characterizing op. See slide 10-model. } \nop{

Example

To illustrate the use of Z, we will briefly discuss a simple example specifying the functionality of a weathermap. } \nop{

State

wheathermap

Examples

Operations

} \nop{ A weathermap consists of a variable known that contains the set of known regions. Further we have a function t which assigns to each region a temperature. For example, t may specify that in the west the temperature is 17 and the north (only) 12. We specify two operations (update and lookup) for our weathermap. The function update modifies the state of the weathermap (as indicated by the occurrence of %D WM in the declaration section of the schema specifying update). It requires as input a region r? and temperature tmp?. (The annotations ? and ! are used to indicate respectively input and output variables.) The operation update results in modifying the function t by adding the assignment r? |-> tmp? using the built-in operator \oplus for function modification. } \nop{ The function lookup leaves the state of the weathermap invariant (as expressed by the inclusion of %X WM). It retrieves the temperature value for the region r? by checking for the membership of r? |-> tmp!. For both the operations update and lookup, the pre-condition r? \e known is specified, expressing that the region for which an update or lookup is performed must be defined for the function t (since we have required dom t = known as an invariant of the weathermap). Only the operation update involves an actual modification of the data, as expressed by the post-condition for update. } \nop{

Conditions

} \nop{ For those not familiar with set theory and the characterization of functions as sets, the operations update and lookup will look miraculous. However, first order logic and elementary set theory are in fact rather simple yet powerful tools to specify the functional behavior of a system. The major advantage of using such a formalism is that it allows to specify both states and operations in unambiguously in a concise way. } \nop{ (An additional advantage of Z, or rather the environment coming with Z is that the specification may be written using a powerful type setting language). } \c{ Clearly, despite the absence of objets or classes, Z has a strongly object-based flavor. In  [Stepney], a number of studies is collected proposing to extend Z with a formal notion of classes and inheritance. The reader interested in these extensions is in particular invited to study Object-Z, OOZE and Z++. As an historical aside, we may note that Z has been of significant influence in the development of Eiffel. See  [Meyer92]. Although the two approaches are rather divergent, they obviously still share a common interest in correctness. }