\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 itself is a compound schema
that results from the logical conjunction of the schema
state and its primed version ,
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 , which expresses that the
state before the applying the operation
is the same as the state (denoted by )
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 in
the declaration section of the schema specifying
update).
It requires as input a region and temperature .
(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
using the built-in
operator for function modification.
}
\nop{
The function lookup leaves the state of the weathermap
invariant (as expressed by the inclusion
of ).
It retrieves the temperature value for the region
by checking for the membership of .
For both the operations update and lookup,
the pre-condition 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
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.
}