Failure-Divergence Semantics as a Formal Basis for an

Object-Oriented Integrated Formal Method

Clemens Fischer and Heike Wehrheim
Universität Oldenburg
Fachbereich Informatik
Postfach 2503, D–26111 Oldenburg, Germany
ffischer,wehrheimg@informatik.uni-oldenburg.de

Abstract
The integration of several different modelling techniques into a single formal method
has turned out to be advantageous in the formal design of software systems. Giving a
semantics to an integrated formal method is currently a very active area of research.
In this paper we discuss the advantages of a failure-divergence semantics for data
and process integrating formal methods, in particular for those with a concept of
inheritance. The discussion proceeds along the lines of the formal method CSP-OZ,
a combination of CSP and Object-Z, developed in Oldenburg.

1 Introduction
Recently, there is an emerging interest in integrated specification methods combin-
ing different formalisms into one. The advantage of integrating several techniques
into one is that it allows for more convenient specifications, choosing the most suit-
able technique for every aspect of the system. The most prominent representative for
an integrated (although not completely formal) method is certainly the Unified Mod-
elling Language UML [Obj99, BRJ99] which combines standard object-oriented
class diagrams with a number of diagrams for describing the dynamic behaviour of
a system. On the side of formal methods, combinations of process algebras with
Z [TA97, Smi97, GS97], B [But99], abstract data types [BB87] or functional lan-
guages [GH96] or combinations of Z with statecharts [GHD98] can be found as
examples for the integration of different formalisms.
This paper continues a series of previous articles on integration modelling in
the Formal Specification Column. Differing from previous articles of the Column
we will not propose an abstract integration paradigm or a metamodel here but dis-
cuss the semantic basis for one particular object-oriented integrated formal method,
namely CSP-OZ [Fis97, Fis00]. CSP-OZ is a formal method which combines the
state-oriented method Object-Z [DRS95, Smi00], an object-oriented extension of Z,

1
 with the process algebra CSP [Ros97]. The semantic basis for this combination is
the failure-divergence model of CSP. In this paper, we explain the design choices
made when giving a failure-divergence semantics to CSP-OZ, and discuss the main
advantages of this particular semantics.
CSP-OZ is only one of a number of combinations of Z with a process algebra.
For a comparison of the different approaches see [Fis98].

2 CSP-OZ
CSP-OZ1 is an object-oriented formal method which integrates Object-Z and the
process algebra CSP. Object-Z or in general Z is a state-oriented method and thus
good at describing data types and operations. Z is currently being standardised by
the ISO [Z99] and has been successfully applied in a number of industrial case
studies. A large range of tools (for instance editors, parsers and theorem provers)
support the writing of Z specifications. The process algebra CSP on the other hand
is mainly concerned with the description of the dynamic behaviour of distributed
communicating systems. For CSP a commercial model checker (FDR) can be used
to perform correctness checks.
The basic idea behind the integration of these two formalisms is to identify every
Object-Z class with a CSP process. For this, every class specification of Object-Z is
equipped with a communication interface and a behaviour description in the style
of CSP2 . Then while the Object-Z part defines the attributes and methods of a class
(possibly with a guard and an effect predicate for every method), the CSP part fixes
the possible orderings of method execution. A method invocation is thus identified
with a CSP communication event.
A CSP-OZ specification typically consists of a number of Z type definitions and
CSP-OZ classes (possibly using inheritance as a structuring concept) together with a
description of the architecture of the system, consisting of an instantiation of classes
into objects and their composition via CSP operators.
CSP-OZ fits perfectly into the integration paradigm proposed in [EPO99], which
consists of four hierarchically organised layers: in CSP-OZ layer 1 (describing data
types) contains all Z axiomatic descriptions, data type definitions etc.; layer 2 (data
states and transformations) contains pure Object-Z class descriptions, defining the
state schema (attributes) of classes and the method schemas; layer 3 (processes)
is captured by the CSP behaviour definitions within a class and layer 4 (architec-
ture) is the final instantiation of classes into objects and their composition via CSP
operators, most often parallel composition and hiding. The semantics of layer 1
is the standard Z semantics, the semantics of layer 2 lifts this basis to the failure-
divergence model, and the upper level semantics are obtained by applying standard
CSP theory.
1 http://semantik.Informatik.Uni-Oldenburg.DE/ csp-oz
2 To be precise, a CSP-OZ specification may also still contain pure Object-Z classes.

2
2.1 Example.
We explain this concept with the example of a vending machine.

Layer 1. The data types of the vending machine are given as Z types.

[MONEY ]
DRINK ::= TEA j COFFEE
A drink can either be tea or coffee; MONEY is an uninterpreted basic type. We
assume the existence of two functions and the relation  on MONEY .

price : DRINK ! MONEY

di : MONEY  MONEY ! MONEY
: MONEY $ MONEY
The function price gives the prices of a drink; di computes the difference between
two amounts of money.

Layer 2. For the second layer, we use the Object-Z class VM-Data as specified
in Figure 1. It comprises five state variables (attributes): store, a store for drinks;
s-money, a store for money; inserted, an intermediate store for the inserted money;
drink , for the choosen drink; and the boolean flag ok , to check whether enough
money has been inserted.
Four operation schemas define the transformations on this state space (the meth-
ods of the class): choose stores a chosen drink in the variable drink . The so called
delta-list ∆(drink ) specifies that choose can only change the variable drink . The
schema choose has two parts: The declaration part above the line specifies the delta
list and the parameter d ? of the operation. The predicate part below the line is a
predicate describing the state transformation. The final value of drink is there writ-
ten as drink . The operation pay stores the inserted money; change calculates the
0

change according to the chosen drink. If not enough money was inserted, ok is set
to false . Finally, the operation serve offers the chosen drink and decreases the value
of the corresponding store.

Layer 3. For the third layer, we use a so called CSP-OZ class. It is an Object-Z
class enriched with an interface and a CSP process. The interface is a list of typed
channels. The CSP process restricts the behaviour of the class: First a drink must be
chosen, then money has to be inserted, the change is given back and finally the drink
is served. Because we have specified the possibility of inserting not enough money,
serving the drink can be skipped (2 denotes the choice operator). However, this is
not controlled by the CSP part, rather we use Z schemas for this purpose, since this
part depends on certain attribute values.
The class VM-Contrl (see Fig. 2) is a specialisation of the VM-Data, inheriting
all its attributes and methods. That makes all items declared in VM-Data available
for VM-Contrl.

3
 VM-Data
serve
store : DRINK ! N ∆(ok ; store)
s-money; inserted : MONEY d ! : DRINK
drink : DRINK d ! = drink ^ ok = true
ok : B store (d !) = store(d !) 1
0

fd !gC store = fd !gC store

0

ok = false
0

choose pay
∆(drink ) ∆(s-money)
d ? : DRINK m ? : MONEY
drink 0
= d? s-money 0
= m?
change
∆(ok )
m ! : MONEY
price (drink )  s-money )
(m ! = di (s-money; price (drink )) ^ ok 0
= true )
price (drink ) > s-money )
(m ! = s-money ^ ok = false )
0

Figure 1: Layer 2: The Object-Z Class VM-Data

To link Z operation schemas to behaviour, special keywords are used: enable

specifies the guard of an operation, effect specifies the corresponding state tran-
sition. Thus a drink can only be chosen when it is stored and a drink is only served if
the customer has paid enough money. The effect of all operations is mapped directly
to the corresponding Object-Z operations. The schema Init specifies the allowed
initial states.
In this example we have a very strict separation of data and behaviour aspects:
the Object-Z class specifies the effect of operations on the data and the CSP-OZ class
specifies all aspects relevant to the ordering of operation execution. This separation
may also be weakened: the specification of data can be put directly into the CSP-
OZ class, completely omitting an Object-Z class specification. For larger systems, it
may however be useful to adhere to a strict separation in order to enhance modularity

4
 VM-Contrl
chan choose [ d ? : DRINK ]
chan serve [ d ! : DRINK ]
chan pay [ m ? : MONEY ]
chan change [ m ! : MONEY ]
main
c
= choose ! pay ! change !
((serve ! main) 2 main)
inherit VM-Data
Init enable choose
ok = false d ? : DRINK
enable serve ok = false
ok = true store(d ?) > 0

effect choose =b choose effect change =b change

effect pay =b pay effect serve =b serve

Figure 2: Layer 3: The CSP-OZ Class VM-Contrl

of the specification.

Layer 4. In layer 4 we combine CSP-OZ classes by standard CSP operators. An

overview of the system is given in Fig. 3. There the class VM-Contrl communicates
with four other classes which we have not explicitly given here: Buttons controls
the two buttons to choose a drink, Dispenser controls the process of making coffee
or tea, Slot stores inserted coins and Change hands out the change.
The diagram in Figure 3 corresponds to the following CSP process:

VendingMachine =c (( Buttons kjDispenser kjChange kjSlot )

k VM-Contrl)
choose serve change pay
fj ; ; ; jg

nfjchoose ; serve ; change ; pay jg

where kj denotes interleaving, k parallel composition synchronising on the set of
A
events A, nA hides the events from A and fjchoose serve change pay jg is the set
; ; ;

of events corresponding to the channels choose serve change and pay .

; ;

5
 b-tea b-coffee

Buttons

choose
coins-out change pay coins-in
Change VM Contrl Slot

serve

Dispenser

tea coee
Figure 3: Layer 4: Architecture of the Vending Machine

2.2 Semantics
CSP-OZ possesses a uniform formal semantics on the basis of CSP’s failure-divergence
model. A failure-divergence model records the possible execution traces of a sys-
tem, the sets of events which may be refused after a particular trace and the points
of divergence, i.e. execution of an infinite number of internal events (livelock). The
semantics of a CSP-OZ class specification is derived in two steps:
 the Z part of the class is given a failure-divergence semantics (via a translation
into CSP) and
 the semantics of the Z part is combined with the (standard) semantics of the
CSP part via the CSP parallel composition operator.
The CSP-OZ semantics is built on the Z semantics as defined in the current commit-
tee draft of the ISO [Z99]. Types, expressions and schemas are interpreted according
to this semantics. Every Object-Z class is then viewed as a process where the class’
methods play the role of communication events. The following four points explain
the main considerations underlying the semantics of Object-Z classes:
 Every method whose guard evaluates to true in the current state can be exe-
cuted,

6
  the values for input parameters are fixed by the environment communicating
with the object (external choice over all possible values for input parameters),
 the values for output parameters and next state are internally chosen from the
set of possible values according to the effect schema of the method (internal
choice),
 an invocation of a method, whose guard evaluates to true but whose precondi-
tion of the effect predicate is not fulfilled leads to divergence.
This semantics supports a blocking as well as a non-blocking view of methods:
guards can be used to block the execution of methods in particular states of the
object, the execution of non-blocked methods whose effect predicates can however
not be fulfilled leads to divergence (every behaviour possible after invocation of
method). The non-blocking view has its origin in Z, where undefinedness is usually
interpreted as ‘all possible values’. The blocking view is typically encountered in
the design of distributed communicating systems, for which CSP can be used as a
modelling language.

3 Failure-Divergence Semantics
The reference model of [GR99] for integrated formalisms proposes to use abstract
transition systems as the semantical basis for layer 2 specifications. Although this
is also possible for CSP-OZ [Fis00] (the transition system can then be the basis for
deriving failures and divergences), we will directly discuss the failure-divergence
semantics here. The choice for a failure-divergence semantics has several advan-
tages.
I The failure-divergence model is the basis for defining three different imple-
mentation relations for CSP: trace refinement, stable failures refinement and failure-
divergence refinement. These relations compare an implementation towards a given
specification according to the dynamic behaviour they exhibit (process refinement),
requiring that the implementation exhibits only a subset of the traces/failures/ diver-
gences of the specification. Having given a failure-divergence semantics to CSP-OZ,
all these implementation relations are applicable to CSP-OZ specifications.
I All process refinement relations are monotone wrt. the operators on the ar-
chitectural level (layer 4), which is clearly a prerequisite for a good implementation
relation. By monotonicity we mean that the process refinement relations are pre-
served under all CSP operators. This is a standard result for CSP.
I Not only CSP but also Z comes with a specific refinement concept. The
standard refinement concept for state-oriented formalisms is data refinement, used
for instance for Z or VDM specifications. Data refinement is concerned with the
change of data structures on different abstraction levels. An initial specification
often uses different data structures than the final implementation which in its choice
of data structures has to be oriented towards efficiency. Data refinement rules are
used to show the correctness of the implementation with respect to the specification.

7
 Since we have a clear separation of the Z- and CSP-part within a CSP-OZ class,
the concept of data refinement can also be applied to CSP-OZ classes, i.e. it can be
determined whether a class is a data refinement of another class. It is hence most im-
portant that this layer 2 (data) refinement concept neatly fits to the layer 3 (process)
refinement concept. The relationship between data refinement and failures refine-
ment has been intensively studied, and the duality of data and process refinement
has been shown in [Jif89, dRE98]: given a failure-divergence semantics for a state-
oriented formalism, data refinement induces process refinement. In [FH97] these
results have been extended to CSP-OZ with its specific combination of blocking and
non-blocking views of method invocation.
I CSP-OZ is an object-oriented formal method. Specifications define a number
of classes which may be instantiated into objects and afterwards combined. Classes
may inherit attributes, methods or behaviour of superclasses. Semantically inher-
itance is interpreted as the conjunction of the Z-part and the parallel composition
of the CSP-part of a class. As usual, inheritance in CSP-OZ is primarily a concept
for re-use of already written specification code. However, closely connected with
inheritance is the question of subtyping: when is a subclass a proper subtype of its
superclass? Subtypes always have to fulfil the principle of type substitutability: an
exchange of a superclass by a subclass should be transparent to clients. In the con-
text of process-oriented formalisms, subtyping is not so much concerned with types
in the usual sense but with the behaviour associated with a class. A replacement of a
superclass by one of its subclasses is only possible if the subclass closely resembles
the behaviour of the superclass. One candidate for such a behavioural subtyping
relation obviously seems to be failure-divergence refinement. Failure-divergence
refinement is however not able to capture the issue of extension of functionality
(i.e. addition of new methods to the subclass) which arises when using inheritance.
Nevertheless failure-divergence semantics can be the basis for defining a number of
behavioural subtyping relations, varying in the degree in which they fulfil the prin-
ciple of type substitutability [FW00]. The principle idea is to use various kinds of
restriction and hiding operators of process algebras (applied to the methods added
in the subclass) when comparing superclasses with subclasses. In [FW00] the ade-
quateness of such behavioural subtyping relations has been shown by giving testing
characterisations for the relations.

Summarising, failure-divergence semantics provides a clear basis for formal meth-

ods integrating state and process based languages. The refinement concepts of the
different layers fit well together and the composition operators of the architectural
level preserve the refinement relations. Moreover, a failure-divergence model can
also be used for defining behavioural subtyping relations; a failure-divergence se-
mantics for an object-oriented formal method thus additionally gives us the possi-
bility of determining subtype relationships among classes.

8
References
[BB87] Tommaso Bolognesi and Ed Brinksma. Introduction to the ISO specifi-
cation language LOTOS. Computer Networks and ISDN Systems, 14:25–
59, 1987.
[BRJ99] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Lan-
guage user guide. Addison Wesley, 1999.
[But99] M. Butler. csp2B: A practical approach to combining CSP and B. In
J. Wing, J. Woodcock, and J. Davies, editors, FM’99: Formal Methods,
number 1708 in Lecture Notes in Computer Science, pages 490–508.
Springer, 1999.
[dRE98] W.-P. de Roever and K. Engelhardt. Data-Refinement: Model Oriented
Proof Methods and their Comparison. Cambridge University Press,
1998.
[DRS95] R. Duke, G. Rose, and G. Smith. Object-Z: A specification language
advocated for the description of standards. Computer Standards and In-
terfaces, 17:511–533, 1995.
[EPO99] H. Ehrig, J. Padberg, and F. Orejas. From basic views and aspects to
integration of specification formalisms. Bulletin of the EATCS, (69):98–
108, 1999.
[FH97] C. Fischer and S. Hallerstede. Data-Refinement in CSP-OZ. Technical
Report TRCF-97-3, University of Oldenburg, June 1997.
[Fis97] C. Fischer. CSP-OZ: A combination of Object-Z and CSP. In H. Bow-
man and J. Derrick, editors, Formal Methods for Open Object-Based Dis-
tributed Systems (FMOODS ’97), volume 2, pages 423–438. Chapman &
Hall, 1997.
[Fis98] C. Fischer. How to combine Z with a process algebra. In J. Bowen,
A. Fett, and M. Hinchey, editors, ZUM’98 The Z Formal Specification
Notation, volume 1493 of LNCS, pages 5–23. Springer, 1998.
[Fis00] C. Fischer. Combination and Implementation of Processes and Data:
from CSP-OZ to Java. PhD thesis, University of Oldenburg, 2000. to
appear.
[FW00] C. Fischer and H. Wehrheim. Behavioural subtyping relations for object-
oriented formalisms. In T. Rus, editor, AMAST 2000: International Con-
ference on Algebraic Methodology And Software Technology. Springer,
2000. to appear.
[GH96] T. Gehrke and M. Huhn. ProFun – a Language for Executable Specifi-
cations. In H. Kuchen and S.D. Swierstra, editors, Proceedings of the
8th International Symposium on Programming Languages: Implementa-
tions, Logics and Programs (PLILP ’96), volume 1140 of Lecture Notes
in Computer Science, pages 304–318. Springer, 1996.

9
[GHD98] W. Grieskamp, M. Heisel, and H. Dörr. Specifying Embedded Systems
with Statecharts and Z: An Agenda for Cyclic Software Components.
In Egidio Astesiano, editor, Proc. of the 1st Intl. Conf. on Fundemantal
Approaches to Software Engineering – FASE’98, volume 1382 of lncs,
pages 88–106. Springer-Verlang, 1998.
[GR99] M. Große-Rhode. On a reference model for the formalization and in-
tegration of software specification languages. Bulletin of the EATCS,
(68):81–89, 1999.
[GS97] A. J. Galloway and W. Stoddart. An operational semantics for ZCCS. In
M. Hinchey and Shaoying Liu, editors, Int. Conf. of Formal Engineering
Methods (ICFEM). IEEE, 1997.
[Jif89] He Jifeng. Process refinement. In J. McDermid, editor, The Theory and
Practice of Refinement. Butterworths, 1989.
[Obj99] Object Management Group. OMG Unified Modeling Language Specifi-
cation, June 1999. version 1.3.
[Ros97] A. W. Roscoe. The Theory and Practice of Concurrency. Prentice-Hall,
1997.
[Smi97] G. Smith. A semantic integration of Object-Z and CSP for the specifica-
tion of concurrent systems. In J. Fitzgerald, C. B. Jones, and P. Lucas,
editors, Proceedings of FME 1997, volume 1313 of LNCS, pages 62–81.
Springer, 1997.
[Smi00] G. Smith. The Object-Z Specification Language. Kluwer Academic Pub-
lisher, 2000.
[TA97] K. Taguchi and K. Araki. Specifying concurrent systems by Z + CCS. In
International Symposium on Future Software Technology (ISFST), pages
101–108, 1997.
[Z99] Z notation. Final Committee Draft, CD 13568.2, ISO Panel
JTC1/SC22/WG19 (Rapporteur Group for Z), 8 1999. see
www.comlab.ox.ac.uk/oucl/groups/zstandards/ for the
current status of the Z standardisation.

10