Unifying Concurrent and Relational Refinement - University of Kent

Electronic Notes in Theoretical Computer Science 70 No. 3 (2002) URL: http://www.elsevier.nl/locate/entcs/volume70.html 38 pages

Unifying Concurrent and Relational Refinement Eerke Boiten and John Derrick Computing Laboratory University of Kent Canterbury, Kent, UK

Abstract Refinement in a concurrent context, as typified by a process algebra, takes a number of different forms depending on what is considered observable, where observations record, for example, which events a system is prepared to accept or refuse. Examples of concurrent refinement relations include trace refinement, failures-divergences refinement and bisimulation. Refinement in a state-based language such as Z, on the other hand, is defined using a relational model in terms of input/output behaviour of abstract programs. These refinements are verified by using two simulation rules which help make the verification tractable. The purpose of this paper is to unify these two standpoints, and we do so by generalising the standard relational model to include additional observable aspects. The central result of the paper is then to develop simulation rules to verify relations such as failures-divergences refinement in a relational setting, and show how these might be applied in a specification language such as Z.

Keywords Refinement, Z, failures-divergences, finalisation, process algebras.

1

Introduction

Why is a process algebra blessed with a multitude of refinement relations, whereas a language like Z only has one notion of refinement? How can one use Z to specify concurrent systems? What is the difference between failuresdivergences refinement and an input/output model? In this paper we seek 1

[email protected], http://www.cs.ukc.ac.uk/people/staff/eab2/, [email protected], http://www.cs.ukc.ac.uk/people/staff/jd1/

c

2002 Published by Elsevier Science B. V.

Boiten and Derrick

to answer these questions. To do so we attempt to reconcile the differences between a relational context and a process algebraic context in terms of their respective refinement relations. The relational context arises out of a specification language like Z [36] by considering each specification to define an abstract data type (ADT). Such an ADT consists of an initialisation, some operations and a finalisation, and a program over an ADT will be a sequential composition of these elements. Refinement in this context is taken to be subsetting of program behaviour, where what is deemed visible (i.e., the domain of the initialisation and the range of the finalisation) is the input/output relation. Thus an ADT C refines A if for every sequence of inputs, the outputs that C produces are a possible set of outputs that A could have produced. This definition of refinement quantifies over program behaviour and simulations have become the accepted approach to make verification of refinements tractable [8]. Two different forms of simulations are needed to provide a complete method: downward and upward simulations, and examples of their use in Z are given in [41,9]. Z, then, has one refinement relation and this contrasts with concurrent models where depending on the strength of observation one wishes to make a number of different relations are available. For example, in CSP one could use trace refinement, failures refinement or failures-divergences refinement [7]. In CCS, bisimulation is typically used [27], whereas in LOTOS reduction, extension and conformance are defined [1]. In general, therefore there are a multitude of possibilities, and a survey of some of the most important ones is given in [39]. These relations are often motivated by the description of an idealised machine by which one manipulates the system and observes its behaviour. Observations might include, for example, which events the system is able to perform (i.e., its ready sets) or not able to perform (i.e., its refusal sets) and the different concurrent refinement relations arise by varying the functionality of this machine. In this paper we explore the differences between these two models, and in particular, unify the two models. We do so by generalising the relational model by expanding the observations that a finalisation can make. We begin the discussion by focusing on the third question highlighted above and by generalising finalisations we show how to verify a number of different refinement relations in a language such as Z. This opens the way to use Z to develop concurrent systems. In some senses our areas of concern have been touched upon before. Work on state-based approaches to concurrent specification goes back to Josephs [22] (similar work due to He [18] and Woodcock and Morgan [42] also appeared around the same time). However, this work was not conducted in a relational setting, but rather was concerned with developing simulation techniques for failures-divergences refinement in a manner that mimicked the simulation techniques as found in Z. In particular, a relational model was not 2

Boiten and Derrick

used. Investigations into this area have recently been given new impetus by work on integrating different formal methods. This work includes proposals which combine Z and Object-Z [32] with process algebras such as CSP and CCS. For example, combinations of Object-Z and CSP have been investigated by a number of researchers including Smith [31], Fischer [13] and Mahony and Dong [25]. Other combinations include those investigated by Galloway [17], Treharne [38] and S¨ uhl [37]. A survey of some of these approaches is given in [14]. In this context, refinement relations that are compatible between statebased languages and process algebras are desired so that a uniform method of refinement can be presented for integrated specifications. The simulation rules embodied in the work of, for example, Josephs are subtly different from those as they are normally presented in Z and Object-Z: the Josephs rules contain a slightly more powerful quantification in the upward simulation rules than those derived from a relational setting, and Bolton and Davies have recently articulated the precise difference in [2]. There is interest therefore in presenting a uniform framework in which both process algebraic and simulation based methods can be embedded. This work can be seen to continue this theme, but instead of starting with a formulation such as provided by [22] we go back to the basic relational semantics and explore these issues from that fundamental perspective. In Section 2 we provide the basic definitions and background. Section 3 begins our program of unification by considering how to add refusals to our relational observations. This results in simulation rules for failures-divergences refinement expressed in the Z schema calculus, and a proof of the relationship between failures-divergences and relational refinement. Section 3 considers these questions in a simplified model where input and output are not considered, and we relax this restriction in Section 4 to provide corresponding results for arbitrary specifications. Other concurrent models are discussed in Section 5. The related work mentioned above is considered in more depth in Section 6 and we conclude in Section 7.

2

Background

In this section we present the standard refinement theory [9] for Abstract Data Types (ADTs) in a relational setting. The notion of observation will be fixed by introducing an explicit concrete (global) state which is used to initialise (and finalise) ADTs. In order to apply this theory to a particular specification language, for example, Z, the operations in a specification are interpreted as partial relations forming an ADT. The application of the simulation rules to specifications with partial operations leads to the simulation rules as they are normally presented. 3

Boiten and Derrick

2.1

A relational model

Given a (global) state G, a program is interpreted as a relation on that global state. An implementation of that program might be described by an Abstract Data Type (ADT), and programs written using that ADT will be relations on G. However, since the implementation details are unobservable, it might use a local state L on which its operations act. To translate to and from states G and L we prepend an initialisation operation to each such sequence, which will take every global state into some local (starting) state, and append a finalisation, which will translate back from local to global state, and call the result a complete program. This will lead to a complete program being interpreted as a relation on the global state as required. The initialisation and finalisation form part of the abstract data type. In order to distinguish between relational formulations (which use Z as a meta-language) and expressions in terms of Z schemas etc., we introduce the convention that expressions and identifiers in the world of relational data types are typeset in a sans serif font. Definition 2.1 (Data type) A data type is a quadruple (State, Init, {Opi }i∈I , Fin). The operations {Opi }, indexed by i ∈ I , are total relations on the set State; Init is a relation from G to State; Fin is a relation from State to G. 2 Definition 2.2 (Complete program) A complete program over a data type D = (State, Init, {Opi }i∈I , Fin) is an expression of the form Init o9 P o9 Fin, where P, a relation over State, is a program over {Opi }i∈I . In particular, for a sequence p over I , and data type D, pD denotes the complete program over D characterised by p (i.e., for D as above, if p = hp1 , ..., pn i then pD = Init o9 Opp1 o9 ... o9 Oppn o9 Fin). 2 Choices can be made as to which constructors can be used for programs, but here we will stick to programs as finite sequences of operations only, as this will be sufficient for the required notions of refinement in Z. We can then make the standard definition of refinement between data types, by quantification over all programs using them (see Figure 1). Data refinement is defined here in terms of inclusion of total relations, and is thus only concerned with reduction of non-determinism of the observable components. Definition 2.3 (Data refinement) For data types A and C, C refines A iff for each finite sequence p over I , pC ⊆ pA . 2 It is necessary to make the verification of refinement tractable, and the standard solution is to use simulations [8], where a step-by-step comparison is made of each operation in the data types (we assume throughout this pa4

Boiten and Derrick -

-

AOp1



-

AOp2

-

AOpn @ @ AFin @

AInit

@ R @ 

@ @

CFin

@CInit @ R COp1@

COp2-

COpn-

-

Fig. 1. Data refinement. -

-

AOp1



-

AOp2

-

AOpn @ @

AInit

AFin @

R @ @ CInit @ @@ R

R

R

R

R

@ R @ 

CFin COp1-

COp2-

-

COpn-

Fig. 2. Data refinement with simulations.

per that our data types are conformal, i.e., they use the same index set for the operations). To do so it is necessary to link the concrete and abstract states (and the link is known variously as a simulation, a retrieve relation, an abstraction relation, or a coupling invariant). This leads to the situation described in Figure 2, with the requirement that the triangles and squares semi-commute. There are two (interesting) ways to make this diagram semi-commute, known as downward and upward simulations, defined as follows. The importance of these definitions lies in the fact that simulations are sound and jointly complete [19,8]. Definition 2.4 (Downward simulation) Assume data types A = (AState, AInit, {AOpi }i∈I , AFin) and C = (CState, CInit, {COpi }i∈I , CFin). A downward simulation is a relation R from AState to CState satisfying (1)

CInit ⊆ AInit o9 R

(2)

R o9 CFin ⊆ AFin

(3)

∀ i : I • R o9 COpi ⊆ AOpi o9 R

If such a simulation exists, we also say that C is a downward simulation of A and similarly for corresponding operations of A and C. 2 Definition 2.5 (Upward simulation) For data types A and C as above, an upward simulation is a relation T from CState to AState such that (4)

CInit o9 T ⊆ AInit 5

Boiten and Derrick

0 qH

- q0 HH

HH H

1 qH

HH j q1

HH HH

HH j q2 H

2q ⊥q

- q⊥ j

Fig. 3. Totalisation of {(0, 0), (0, 1), (1, 2)} over the state {0, 1, 2} in the behavioural approach.

(5)

CFin ⊆ T o9 AFin

(6)

∀ i : I • COpi o9 T ⊆ T o9 AOpi

If such a simulation exists, we also say that C is an upward simulation of A and similarly for corresponding operations of A and C. 2 2.2

Partial Relations

The rules given above provide a data refinement relation for ADTs whose operations are total relations. However, in languages like Z, operations are often specified by partial relations. There are at least two different interpretations of partial operations in the world of state based systems. In the contract or non-blocking approach to ADTs, the domain (precondition) of an operation describes the area within which the operation should be guaranteed to deliver a well-defined result, as specified by the relation. Outside that domain, the operation may be applied, but may return any value, even an undefined one (modelling, e.g., non-termination). In the behavioural or blocking approach to ADTs, operations may not be applied outside their precondition; doing so anyway leads to an undefined result. The precondition is often called the guard in this context. Traditionally, the first approach is the more common one in Z, although it really should depend on the area of application as to which of the two interpretations is the “correct” one. In fact, they are not necessarily exclusive [26]. In both approaches the simulation rules for partial operations are derived from those for total operations by modelling partial relations on a set S as total relations on a set S⊥ , which is S extended with a distinguished value ⊥ not in S. This construction is known as a totalisation, and the totalisation of an operation is illustrated in Figure 3 where values outside the domain are linked to ⊥ only. Definition 2.6 (Totalisation) 6

Boiten and Derrick

c on For a partial relation Op on State, its totalisation is a total relation Op State⊥ , defined in the “contract” approach to ADTs by c == Op ∪ {x, y : State⊥ | x 6∈ dom Op • (x, y)} Op or in the behavioural approach to ADTs by c == Op ∪ {x : State⊥ | x 6∈ dom Op • (x, ⊥)} Op Totalisations of initialisation and finalisation are defined analogously. A relae between AState⊥ tion R between AState and CState is extended to a relation R and CState⊥ , defined in the contract approach by e == R ∪ ({⊥AState } × CState⊥ ) R and in the behavioural approach by e == R ∪ {(⊥AState , ⊥CState )} R

2

The resulting refinement rules for totalised relations can then be simplified to remove any reference to ⊥. This calculation, and a similar one for the contract interpretation (see [41,9,4]), lead to the following definition. Definition 2.7 (Downward simulation for partial relations) Assume data types A = (AState, AInit, {AOpi }i∈I , AFin) and C = (CState, CInit, {COpi }i∈I , CFin) where the operations may be partial. A downward simulation is a relation R from AState to CState satisfying, in the contract interpretation CInit ⊆ AInit o9 R R o9 CFin ⊆ AFin ran(dom AFin C R) ⊆ dom CFin ∀ i : I • ran(dom AOpi C R) ⊆ dom COpi ∀ i : I • (dom AOpi C R) o9 COpi ⊆ AOpi o9 R The five conditions are commonly referred to as “initialisation”, “finalisation”, “finalisation applicability”, “applicability” and “correctness”. In the behavioural interpretation, correctness is strengthened to: ∀ i : I • R o9 COpi ⊆ AOpi o9 R 2 Definition 2.8 (Upward simulation for partial relations) Assume data types A = (AState, AInit, {AOpi }i∈I , AFin) and C = (CState, CInit, {COpi }i∈I , CFin) where the operations may be partial. An upward simulation 7

Boiten and Derrick

is a relation T from CState to AState satisfying, in the contract interpretation CInit o9 T ⊆ AInit CFin ⊆ T o9 AFin ∀ c : CState • c(| T |) ⊆ dom AFin ⇒ c ∈ dom CFin ∀ i : I • dom COpi ⊆ dom(T − B dom AOpi ) ∀ i : I • dom(T − B dom AOpi ) − C COpi o9 T ⊆ T o9 AOpi In the behavioural interpretation, correctness is strengthened to: ∀ i : I • COpi o9 T ⊆ T o9 AOpi 2 2.3

Refinement in Z

The simulation rules presented above can be used to define a refinement methodology in a language such as Z, and to do so one gives a relational interpretation to a Z specification. We describe that process here, firstly in the context where the Z operations have no input or output. The combination of having no outputs and the Z data type being abstract means that all we could really observe in this context is whether a sequence of operations would be “possible” in the sense of not having ⊥ as a possible outcome. A Z specification can be thought of as a data type, defined as a tuple (State, Init, {Opi }i∈I ). The operations Opi are defined in terms of (the variables of) State (its before-state) and State 0 (its after-state). The initialisation is also expressed in terms of an after-state State 0 . Finalisation normally does not appear explicitly in the simulation rules as presented in Z. In a context with no input or output, finalisation corresponds to an operation from the local state (which will correspond to State) to a global state which contains no information, i.e., a one point domain, which we define as follows: G == {∗}. The relational formalisation of initialisation requires a total relation from the global state to the local state, however. Since the global state G is a singleton domain {∗}, the relation taking ∗ to any value in the set of initial states is the required relation. Init == {Init • ∗ 7→ θState 0 } (In Z, θState 0 produces the binding which is represented by the components in State 0 , but removing the primes on the labels.) Z operations are also represented by schemas, and the correct relational embedding is as follows: (7) Op == {Op • θState 7→ θState 0 } Note that in this interpretation, pre corresponds to dom, in the sense that (which will no longer be the case once we consider inputs and outputs) pre Op == dom Op = {Op • θState} 8

Boiten and Derrick

A retrieve relation R between AState and CState is then embedded in the relational setting as follows: R == {R • θAState 7→ θCState}. Given this embedding above, we can translate the relational refinement conditions of downward simulations into refinement conditions for Z ADTs. This is straightforward, the only point of note is that the conditions on the finalisation are always satisfied in this Z interpretation. Definition 2.9 (Standard downward simulation in Z) Given Z data types A = (AState, AInit, {AOpi }i∈I ) and C = (CState, CInit, {COpi }i∈I ). The relation R on AState ∧ CState is a downward simulation from A to C if ∀ CState 0 • CInit ⇒ ∃ AState 0 • AInit ∧ R 0 and for all i ∈ I : ∀ AState; CState • pre AOpi ∧ R ⇒ pre COpi ∀ AState; CState; CState 0 • pre AOpi ∧ R ∧ COpi ⇒ ∃ AState 0 • R 0 ∧ AOpi The above rules assume the contractual interpretation of ADTs. In the behavioural interpretation, the rule for correctness becomes ∀ AState; CState; CState 0 • R ∧ COpi ⇒ ∃ AState 0 • R 0 ∧ AOpi When this behavioural correctness condition holds, the applicability condition above is equivalent to ∀ AState; CState • R ⇒ (pre AOpi ⇔ pre COpi ). 2 The translation of the upward simulation conditions are similar, however this time the finalisation produces a condition that the simulation is total on the concrete state. Definition 2.10 (Standard upward simulation in Z) Given Z data types A = (AState, AInit, {AOpi }i∈I ) and C = (CState, CInit, {COpi }i∈I ). Then the relation T on AState ∧ CState is an upward simulation from A to C if ∀ CState • ∃ AState • T ∀ AState 0 ; CState 0 • CInit ∧ T 0 ⇒ AInit and for all i ∈ I : ∀ CState • (∀ AState • T ⇒ pre AOpi ) ⇒ pre COpi ∀ AState 0 ; CState; CState 0 • (∀ AState • T ⇒ pre AOpi ) ⇒ (COpi ∧ T 0 ⇒ ∃ AState • T ∧ AOpi ) Under the assumption of totality of T , the applicability condition is equiva9

Boiten and Derrick

lently phrased as ∀ CState • ∃ AState • T ∧ (pre AOpi ⇒ pre COpi ) The above rules assume the contractual interpretation of ADTs. In the behavioural interpretation, the rule for correctness becomes ∀ AState 0 ; CState; CState 0 • (COpi ∧ T 0 ) ⇒ ∃ AState • T ∧ AOpi 2 2.4 Embedding Inputs and Outputs The previous subsection described an embedding of Z ADTs without inputs or outputs in the relational setting. In such a context, Z operations translate naturally to the homogeneous relations of the relational data type. To carry this over to the situation with input and output, they will be modelled by sequences whose elements are produced and consumed one by one by the operations of the ADT. As these inputs and outputs form part of the observable behaviour of the ADT, those sequences will need to be part of the global state. They also need to be available for the ADT to change, so they will also be part of the local state. Initialisation and finalisation will be concerned with copying these sequences between the global and local state. We will need the following notation [9]. Definition 2.11 (Input and output signature) Denoting S ∨ ¬S by ΣS , the input signature of an operation schema Op on state State is its projection on input components only, i.e., ?Op = Σ(∃ State • pre Op) The output signature of an operation schema Op on state State is its projection on output components only, i.e., !Op = Σ(∃ pre Op; State 0 • Op) 2 For simplicity, we assume that all operations Opi have input of type Input, and output of type Output. Note that these are schema types (whose elements are labelled bindings) whose signatures coincide with those of ?Opi and !Opi , respectively. First, the global state contains sequences of inputs and outputs (only). G == seq Input × seq Output The local state contains both of those plus a representation of the Z ADT state, the latter is the same as in the IO-free embedding above. State == seq Input × seq Output × State 10

Boiten and Derrick

The initialisation transfers the sequence of inputs from the global state to the local state, and picks an initial local ADT state that satisfies the ADT’s initialisation. Init == {Init; is : seq Input; os : seq Output • (is, os) 7→ (is, hi, θState 0 )} Fin == {State; is : seq Input; os : seq Output • (is, os, θState) 7→ (hi, os)} The effect of an operation Op on the modified local state is as follows. The first element is taken from the input sequence, and used as the input (= θ?Op) for the operation. The remainder of the input sequence is left for the following operations. The output produced by the operation (θ!Op) is appended to the output sequence. The state is transformed according to the operation. Opi == {Opi ; is : seq Input; os : seq Output • (hθ?Opi i a is, os, θState) 7→ (is, os a hθ!Opi i, θState 0 )} The embedding of retrieve relations in the relational setting is trivial, assuming R is a retrieve relation between AState and CState we have: R == {R; is : seq Input; os : seq Output • (is, os, θAState) 7→ (is, os, θCState)} With this embedding of input and output into the state one needs to derive the simulation rules again, and details of this can be found in, for example, [9]. In fact, the derivation produces the same conditions as before modulo the need to quantify over inputs and outputs. 2.5 Failures-divergences refinement A contrasting view of refinement is that offered by a process algebraic description of a system. There, instead of a relation over a global state being representative of a program, the traces of events (in essence, the programs themselves) are recorded. For example, the standard semantics of CSP is the failures-divergences semantics developed in [6,7,30]. A process is modelled by the triple (A, F , D) where A is its alphabet, F is its failures and D is its divergences. The failures of a process are pairs (t, X ) where t is a finite sequence of events that the process may undergo and X is a set of events the process may refuse to perform after undergoing t. That is, if the process after undergoing t is in an environment which only allows it to undergo events in X , it may deadlock. The divergences of a process are the sequences of events after which the process may undergo an infinite sequence of internal events, i.e. livelock. Divergences also result from unguarded recursion. 11

Boiten and Derrick

Failures and divergences are defined in terms of the events in the alphabet of the process. The failures of a process with alphabet A are a set F ⊆ A∗ × P A such that a number of properties hold. Properties F 1 and F 2 capture the requirement that the sequences of events a process can undergo form a nonempty, prefix-closed set. Property F 3 states that if a process can refuse all events in a set X then it can refuse all events in any subset of X . Property F 4 states that a process can refuse any event which cannot occur as the next event. (Earlier versions of the CSP semantics, e.g., [6], required that the set of refused events be finite. This requirement was later dropped [7] 2 .) (h i, ∅) ∈ F (t1 a t2 , ∅) ∈ F ⇒ (t1 , ∅) ∈ F (t, X ) ∈ F ∧ Y ⊆ X ⇒ (t, Y ) ∈ F (t, X ) ∈ F ∧ (∀ e ∈ Y • (t a hei, ∅) 6∈ F ) ⇒ (t, X ∪ Y ) ∈ F

(F 1) (F 2) (F 3) (F 4)

The divergences of a process with alphabet A and failures F are a set D ⊆ A∗ such that: D ⊆ dom F t1 ∈ D ∧ t2 ∈ A∗ ⇒ t1 a t2 ∈ D t ∈ D ∧ X ⊆ A ⇒ (t, X ) ∈ F

(D1) (D2) (D3)

The first property simply states that a divergence is a possible sequence of events of the process. Properties D2 and D3 capture the idea that it is impossible to determine anything about a divergent process in a finite time. Therefore, the possibility that it might undergo further events cannot be ruled out. In other words, a divergent process behaves chaotically. Refinement in CSP is defined in terms of failures and divergences [7]. A process Q is a refinement of a process P , denoted P vFD Q, if failures Q ⊆ failures P and divergences Q ⊆ divergences P Since our purpose is to reconcile failures-divergences refinement and refinement in a relational setting it is worth reflecting for a moment on the differences between the two models. First, as mentioned above, on one level the very basis is different. Relational refinement is only concerned with the relation between input and output, since that is all that is observed in the global state. This contrasts with a process algebraic view where the event names have an importance not attributed to them in the relational setting. There are various ways to bridge this gap, usually by describing a ’corresponding process’ for an ADT which in effect starts to make the events observable. More on this later. 2

The additional property stating that a set is refusable if all its finite subsets are refusable in [7] was shown to be unnecessary in [29].

12

Boiten and Derrick

Second, relational refinement looks at reduction of non-determinism visible in the global state as given by complete programs. Failures-divergences refinement, on the other hand, is very explicitly not just concerned with traces but also with refusals and divergences, and the relationship between this and complete programs is not immediately obvious. The purpose of the rest of this paper is to discuss these differences, and derive a relational refinement which in some senses corresponds to failuresdivergences refinement. Considering refusals and input and output will be at the heart of correctly achieving this correspondence.

3

Adding refusals to relational refinement

We will begin our generalisation of relational refinement by considering how to add refusals to our observations. We postpone any consideration of input and output until Section 4, and therefore begin with the relational set up as described in Sections 2.1 to 2.3. Programs are thus relations over an augmented global state G⊥ where G == {∗}. Observations of a program thus merely record whether the sequence of operations terminated correctly (output ∗) or whether they aborted with an output of ⊥G through either non-termination (non-blocking contract approach) or inapplicability (blocking behavioural approach). The basic ’observations’ the relational model makes are thus very weak, sufficient perhaps for a sequential setting, but certainly not discriminating enough for a concurrent setting. The solution is simple: make more observations, and the only way we can do this is to increase the expressitivity of the finalisation, since this represents what is observable. We first of all consider how this affects the simulation rules. Since we have derived a set of rules for use with partial relations, we work for the moment without the need to consider totalisations. Thus to include extra information, we generalise finalisation from being {State • θState 7→ ∗} to becoming {State • θState 7→ E } where E will be a set of operation names. What goes in E depends on what we want to observe, for example, we will first consider E representing what operations could be refused at the state in which we have just finalised. The result type of finalisation and the input of initialisation should both be the “global state”, and thus for consistency, initialisation should also take a set of operations as its input.

13

Boiten and Derrick

Example 3.1 The standard Z ADT (B , Init, {On, Off }) where B b:B

On ∆B

Init B0

¬b ∧ b 0

b

Off ∆B

0

b ∧ ¬b 0 is interpreted as the relational data type (B, Init, {On, Off}, Fin) where B == {h| b == true |i, h| b == f alse |i} Init == {g : P{On, Off } • g 7→ h| b == true |i} On == {h| b == f alse |i 7→ h| b == true |i} Off == {h| b == true |i 7→ h| b == f alse |i} Fin == { h| b == true |i 7→ {On}, h| b == true |i 7→ ∅, h| b == f alse |i 7→ {Off }, h| b == f alse |i 7→ ∅}

2

Finalisations are still total on the local state, on this local state we return a set of observations E . Since our operations are indexed over I we can use this as the set of operation names. To code refusals in the relational setting we take E to be any subset of the following (which are the maximal refusals): I \ {i : I | dom Opi }. As the finalisation, observing such a set E , is determined by the particular interpretation of ADTs (rather than being under control of the specifier), we should include it in a modified definition of the finalisation in the relational setting, as follows: Definition 3.2 (Refusals embedding) An abstract data type (State, Init, {Opi }i∈I ) in the refusals interpretation is embedded in the relational model as follows. The global state G is P I , finalisation is given by Fin == {State; E : P I | (∀ i ∈ E • ¬ pre Opi ) • θState 7→ E } and initialisation is given by Init == {Init; E : P I • E 7→ θState 0 } Local state and embedding of operations are as in (7). Note that the initialisation is unchanged except for the effect of a different global state. 14

Boiten and Derrick

The refinement obligations on finalisations now do not disappear, unlike they did in Section 2.3. Remember that for downwards simulations these were the conditions that: R o9 CFin ⊆ AFin ran(dom AFin C R) ⊆ dom CFin Even with this extended finalisation the second condition is always satisfied. However, expanding the first we find that R o9 CFin ⊆ AFin ≡ { definition of ⊆ } ∀ g, a • (a, g) ∈ R o9 CFin ⇒ (a, g) ∈ AFin ≡ { definition of AFin } ∀ AState; E • (∃ CState • R ∧ E ⊆ Ref (CState)) ⇒ E ⊆ Ref (AState) ≡ ∀ AState; E ; CState • R ⇒ (E ⊆ Ref (CState)) ⇒ E ⊆ Ref (AState) ≡ ∀ AState; CState • R ⇒ ∀ E • (E ⊆ Ref (CState) ⇒ E ⊆ Ref (AState)) ≡ ∀ AState; CState • R ⇒ (Ref (CState) ⊆ Ref (AState)) ≡ ∀ R • (Ref (CState) ⊆ Ref (AState)) Where Ref (State) = {i : I | ¬ pre Opi }. In a similar fashion we can extract the requirements due to upwards simulations. Again the requirement that ∀ c : CState • c(| T |) ⊆ dom AFin ⇒ c ∈ dom CFin is always satisfied. However, that of CFin ⊆ T o9 AFin leads to ∀ E ; CState • E ⊆ Ref (CState) ⇒ ∃ AState • (T ∧ E ⊆ Ref (AState)) which is equivalent to (see Appendix A) ∀ CState • ∃ AState • T ∧ Ref (CState) ⊆ Ref (AState) Some points about this construction are worth noting: •

Consideration of refusals means we are extending our observations beyond simply acceptance of traces, and a record of events (refusals in this instance) at a certain moment in time has been made. This is making the first step in the bridge from the relational world to a more concurrent reactive model. This record of events appears in the simulation rules via the quantification over i that occurs within the scope of the quantification over AState and CState. 15

Boiten and Derrick •

Although we began by embedding refusals in a finalisation, the conditions can be unwound to be expressed in terms of the schema calculus directly.

•

The differences between these conditions and those for the standard simulations are quite clear. · For downward simulations, this new finalisation condition is equivalent to the standard applicability condition. This is not the case for upward simulations. · The standard upward simulation applicability condition requires that we have to consider pairs of abstract and concrete states for each operation. The finalisation condition, on the other hand, requires that for every abstract state we can find a single concrete state such that all the preconditions of the abstract operations imply the preconditions of their concrete counterparts. This is a stronger condition and one that highlights the difference between sequential and concurrent refinement.

•

The conditions extracted from this finalisation requirement work with both the blocking and the non-blocking model of preconditions.

•

One might wonder how, by following the definition of refinement, which is a universal quantification over all traces, a semantic characterisation is obtained which is more powerful than trace semantics. The key to this lies in the observation that, for this finalisation, the observation at the end of a full trace does not determine the observations possible after each of its prefixes. For the finalisations in Section 2.3, the output generated at the end of a trace determined the intermediate output sequences, too, thus making it an essentially sequential semantics. By making independent observations at any prefix, we have essentially made the choice points visible.

To summarise, we have changed the observations made by amending the finalisation. This leads to non-trivial finalisation conditions given above. For downward simulations the finalisation condition is equivalent to the applicability condition, thus Definition 2.9 represents the complete definition required. For upwards simulations the finalisation condition subsumes the applicability condition, thus the following represents the necessary set of conditions. Definition 3.3 (Upward simulation with refusals) Given Z data types A = (AState, AInit, {AOpi }i∈I ) and C = (CState, CInit, {COpi }i∈I ). Then the relation T on AState ∧ CState is an upward simulation from A to C if ∀ AState 0 ; CState 0 • CInit ∧ T 0 ⇒ AInit ∀ CState • ∃ AState • T ∧ Ref (CState) ⊆ Ref (AState) and for all i ∈ I : ∀ AState 0 ; CState; CState 0 • (∀ AState • T ⇒ pre AOpi ) ⇒ (COpi ∧ T 0 ⇒ ∃ AState • T ∧ AOpi ) 16

Boiten and Derrick

Fig. 4. An upwards simulation which does not satisfy the finalisation condition.

The above rules assume the contractual interpretation of ADTs. In the behavioural interpretation, the rule for correctness becomes ∀ AState 0 ; CState; CState 0 • (COpi ∧ T 0 ) ⇒ ∃ AState • T ∧ AOpi 2 To see that the upwards finalisation condition subsumes the applicability condition note that the former can be written as: ∀ CState • ∃ AState • ∀ i : I • T ∧ (pre AOpi ⇒ pre COpi ) which is strictly stronger than the applicability condition: ∀ i : I • ∀ CState • ∃ AState • T ∧ (pre AOpi ⇒ pre COpi )

Example 3.4 The difference is illustrated in Figure 4, see also [3]. This pictures an abstract and concrete system, in which the concrete system has no operations enabled at its single point but still satisfies the upward simulation conditions when finalisation is not considered. 3.1 The correspondence with failures-divergences refinement So far we have extended our notion of observation in a relational setting, and, using the same relational model of refinement as before, extracted simulation rules. Since these simulation rules are known to be sound and jointly complete (i.e., Section 2.1 did not fix the finalisation used) they form a tractable method for verifying our relational refinements. Our task now is to show that this relational refinement corresponds in some sense to failures-divergences refinement. This will complete the bridge to a reactive model. Three points are worth noting. The first is that ’in some sense’ means it is modulo an encoding of the ADT as a set of events, however, this encoding is natural and uncontroversial. The second point to note is that the result is not obvious: although we have put refusals in the finalisation we still need to get a handle on the traces, and this has to be extracted from 17

Boiten and Derrick

the definition of relational refinement. Finally, note that Josephs [22] proves soundness and completeness with respect to failures-divergences refinement of exactly the collection of simulation rules given above. However, he only considers the blocking approach, and the proof presented in this section will be further generalised to the situation with inputs and outputs in Section 4. Instead of describing the corresponding process as a process specification in, say, CSP (as is done in [3]), one can think directly in terms of events and hence traces, refusals and divergences. Without any input or output the matter is trivial. Operations transform the augmented state space State⊥ , and therefore if (x , y) ∈ Op we can think of this as a transition between x and y due to an Op event Op, that is, x −→ y. As we are comparing refinement relations, we need to use the basic definition of refinement (Definition 2.3). This is defined for total relations only, and thus we need to consider totalised relations. The totalisation is defined differently for the blocking and non-blocking approaches, this will be taken into account below. 3.1.1 The blocking model In the blocking model there are no divergences: each operation is either blocked or gives a well-defined result. Traces arise from sequences of operations which are defined within their guards. Refusals indicate the impossibility of applying an operation outside its precondition. This interpretation defines the failures of an ADT. Theorem 3.5 In the blocking model, relational refinement with extended finalisations corresponds to failures-divergences refinement. Proof. 1. Assume the ADT A = (AState, AInit, {AOpi }i∈I , AFin) is refined by C = (CState, CInit, {COpi }i∈I , CFin). We have to prove that every failure (tr , X ) of C is also a failure of A. W.l.o.g., let tr =< i1 , i2 , . . . , in >. tr being a trace of C means that operations within are not refused, hence as a totalised relation CInit o9 COpi1 o9 . . . o9 COpin o9 CFin contains a pair (E , E 0 ) where E 0 6= ⊥G . By relational refinement, this pair is also in AInit o9 AOpi1 o9 . . . o9 AOpin o9 AFin. Thus tr is a trace of A as required. The refusals are simple, since at the end of a trace X will be in the finalisation, and relational refinement gives us subsetting of the finalisation. Therefore (tr , X ) is a failure of A. 2. For the reverse implication, suppose we have failures-divergences refinement. We have to show that relational refinement follows, e.g., that CInit o9 COpi1 o9 . . . o9 COpin o9 CFin ⊆ AInit o9 AOpi1 o9 . . . o9 AOpin o9 AFin. Now CInit o9 COpi1 o9 . . . o9 COpin o9 CFin as a totalised relation will map any global state g either to E for a set of indices E or to ⊥G . 18

Boiten and Derrick

In the former case it follows that (hi1 , i2 , . . . , in i, E ) is in the failures of C and hence in the failures of A. This implies that (g, E ) ∈ AInit o9 AOpi1 o9 . . . o o 9AOpin 9 AFin. In the latter case, an outcome of ⊥G means that one of the operations was refused in the program. W.l.o.g. assume that this first occurred after j steps. Thus schematically we have (if α is some element in CState): CInit o9 COpi1 o9 . . . o9 COpij o9 COpij+1 o9 . . . o9 COpin o9 CFin g 7→ α 7→ ⊥State 7→ ⊥State 7→ ⊥G Thus, (hi1 , i2 , . . . , ij i, {ij +1 }) is in the failures of C, by failures-divergences refinement it is then also in A. Thus, for some element β in the local state of A, AInit o9 AOpi1 o9 . . . o9 AOpij o9 AOpij+1 o9 . . . o9 AOpin o9 AFin g 7→ β 7→ ⊥State 7→ ⊥State 7→ ⊥G Thus (g, ⊥G ) ∈ AInit o9 AOpi1 o9 . . . o9 AOpin o9 AFin. Hence, for the blocking model, relational refinement is equivalent to failuresdivergences refinement. 2 3.1.2 The non-blocking model In the non-blocking model there are divergences, but no refusals beyond those after a divergence. Before the ADT diverges, no operation is blocked, it either gives a well-defined result or causes divergence. Traces are, once again, sequences of operations. Divergences arise from applying an operation outside its precondition. This interpretation defines the failures and divergences of an ADT. Thus, when a program has not diverged it will finalise to some set of inapplicable operations E ; if it has diverged, it may finalise to any set of refused operations, or to ⊥G . Theorem 3.6 In the non-blocking model, relational refinement with extended finalisations corresponds to failures-divergences refinement. Proof. 1. Assume the ADT A = (AState, AInit, {AOpi }i∈I , AFin) is refined by C = (CState, CInit, {COpi }i∈I , CFin). We have to prove that every failure (tr , X ) of C is also a failure of A, and that every divergent trace of C is a divergent trace of A. First, we prove the inclusion of divergences. Let hi1 , . . . , in i be a divergent trace of C. Then, due to the totalisation chosen, for any g (g, ⊥G ) ∈ CInit o9 COpi1 o9 . . . o9 COpin o9 CFin and thus by relational refinement (g, ⊥G ) ∈ AInit o9 AOpi1 o9 . . . o9 AOpin o9 AFin which can only be the case if hi1 , . . . , in i is a divergent trace of A. 19

Boiten and Derrick

Next, consider a failure (tr , X ) of C, where tr = hi1 , . . . , in i. If tr is divergent in C, then due to the above it is also divergent in A and thus (tr , X ) will be a failure of A as well. So, assume tr is non-divergent in C, and then necessarily X = ∅. This means that (g, ∅) ∈ CInit o9 COpi1 o9 . . . o9 COpin o9 CFin and thus by relational refinement (g, ∅) ∈ AInit o9 AOpi1 o9 . . . o9 AOpin o9 AFin The latter might still arise after applying an undefined operation, as a consequence of the choice of totalisation. In that case, (a prefix of) tr must be divergent in A, and thus (tr , ∅) is a possible failure of A as required. If tr is not divergent in A, then (tr , ∅) is also a failure of A as required. 2. For the reverse implication, suppose we have failures-divergences refinement. We have to show that relational refinement follows. So we prove for every (g, E ) and every trace tr = hi1 , . . . , in i that (g, E ) ∈ CInit o9 COpi1 o9 . . . COpin o9 CFin implies (g, E ) ∈ AInit o9 AOpi1 o9 . . . AOpin o9 AFin First, if tr is divergent in C, due to failures-divergences refinement, tr is divergent in A, and then the conclusion will hold for any g and E including ⊥G . So, assume tr is non-divergent in C. If tr is divergent in A, the conclusion will hold for any g and E including ⊥G . Thus, assume tr is non-divergent in A as well. This means that (g, E ) is included in the concrete program exactly when E = ∅, and similarly for the abstract program. Thus, relational refinement holds in every case. 2

4

Dealing with input and output

Thus far we have considered the relationship between relational refinement of ADTs and failures-divergences refinement of an event based interpretation of simple ADTs where no input or output was present. We now generalise these results to specifications containing input and output. Crucial to this will, of course, be how we treat input and output in our event based interpretation, that is, how we define traces and, in particular, refusals for a system containing input and output. Section 2.4 described the standard approach to deriving the simulation rules in the relational context when dealing with input and output. In this approach the global and local states are augmented with input and output 20

Boiten and Derrick

sequences, which the operations affect in particular ways to mimic the effect of input consumption and output production. One obvious approach then is to apply the results of Section 3 directly to this model, determining the failures-divergences refinement that then arises from the correspondences described in Section 3.1. However, when one works through the details of the construction it becomes clear that this approach is deficient. The problem is that the input and output have an observable nature which is not captured when deriving the corresponding process (and its failures and divergences). In particular, the manipulation of the input and output sequences by an individual operation Op in a program is a key observable property, yet the corresponding process just considers this as a transition Op where only the operation name is visible and not the input and output. Thus in dealing with input and output we need to resolve the following: •

describe the correct corresponding process and its failures and divergences,

•

define the finalisation,

•

prove that relational refinement is the same as failures-divergences refinement, and

•

extract simulation rules from the relational refinement, expressing them in the schema calculus.

These issues are, of course, related to one another and we proceed in sequence, for example, defining the finalisation in terms of refusals defined by the corresponding process.

4.1 The corresponding process The standard, and obvious, approach here is to describe a state change between State and State 0 due to an operation Op with input i and output o Op.i.o as an event State −→ State 0 . The traces arising from an ADT are then the traces arising from the evolutions of these events from the initial state. The refusals and divergences are slightly more complicated. A consequence of including outputs in the events is that the traditional Z precondition, which excludes outputs, does not refer to single events anymore. As a consequence, we cannot refer to “its” precondition for an event, and thus it is not obvious what a “non-blocking” approach would be in this situation. So, for the rest of this section we will consider the blocking model only. What would the refusals need to be under the given interpretation? For a given input i and state State, if these lie outside the precondition of an operation Op, then Op.i .o will be refused for all possible outputs o. What if an operation is applied in a state and input inside its precondition, can it ever be refused? The answer depends on how the environment reacts with it with respect to synchronisation on outputs. We have two choices: 21

Boiten and Derrick •

the environment cannot influence the output, and there are refusals due to a particular output being chosen, or

•

the environment can influence the output, and there are no such refusals.

The first option deals with a situation when the outputs of an operation cannot be constrained by the environment: one can refuse all but one of the possible assignment of values to the outputs corresponding to a particular operation and assignment of values to the inputs. The alternative view is one where the coupling between a system and its environment is tighter and the environment can affect non-determinism in the outputs of operations by choosing a value to synchronise on if one can be found. We call the former a demonic choice of outputs, and the latter an angelic choice [35] (despite their names the former is most often used). The refusals one gets differ slightly in each of the models. In the first the process is allowed to refuse all but one of the possible outputs. Thus Op.i .o will be in a refusal set E if there is another possible output o2 (6= o) which is not in E . Hence the refusals E in the demonic model at a particular State are characterised by: Op.i .o ∈ E

⇒

Op.i.o

¬ ∃ State 0 • State −→ State 0 ∨ Op.i.o

(∃ State 00 • State −→ State 00 ∧ Op.i.o2

(∃ o2 6= o; State 0 • State −→ State 0 ∧ Op.i .o2 6∈ E )) In the second, angelic, model, the refusals arise simply out of the failure to be able to perform that operation. Hence here the refusals are defined by Op.i.o

Op.i .o ∈ E ⇒ ¬ ∃ State 0 • State −→ State 0 Note that there are, again, no divergences. 4.2

The finalisation

The finalisation now has to take into account input and output information. Specifically, in Section 3 we generalised finalisation to become: {State • θState 7→ E } In the presence of input and output sequences this will become: {State; is : seq Input; os : seq Output • (is, os, θState) 7→ (hi, os, E )} Now the refusals E will also possibly need to include input and output information since whether an operation is refused depends, as we have just seen, on the inputs and outputs. E will thus consist of events (in the process 22

Boiten and Derrick

algebraic sense) that have been refused, and will thus be of the form Op.i .o where Op is an operation index, i an input value, and o an output value. Once again, this different finalisation is represented by a modified embedding of the Z ADT into the relational model. Definition 4.1 (Angelic and Demonic Embeddings) An abstract data type (State, Init, {Opi }i∈I ) with inputs of type Input and outputs of type Output is embedded in the relational model as follows. The global state is defined by Event = I × Input × Output G = P Event The embedding of operations is as in Section 2.4; like in Definition 3.2, initialisation is extended with an input set of events that is ignored. Finalisation is given by Fin == {State; is : seq Input, os : seq Output; E : G | Fcond • (is, os, θState) 7→ (h i, os, E )} where Fcond is in the angelic model: E ⊆ {(i , in, out) | ¬ ∃ State 0 ; Input; Output • Opi ∧ θ?Opi = in ∧ θ!Opi = out} and in the demonic model: E ⊆ {(i , in, out) | (¬ ∃ State 0 ; Input; Output • Opi ∧ θ?Opi = in)∨ (∃ State 0 ; Input; Output • Opi ∧ θ?Opi = in∧ θ!Opi 6= out ∧ (i , in, θ!Opi ) 6∈ E )} Note that i and in are treated analogously in both models. This is unsurprising: inputs in process algebra are often considered as syntactic sugar for a richer alphabet of operations. Indeed, we could have reflected this by embedding a Z datatype with {Opi }i∈I into a relational datatype with {Opi }i∈I ×Input instead. 4.3

The correspondence with failures-divergences refinement

Having defined the corresponding process and the finalisation we are in a position to show the correspondence with failures-divergences refinement. This result is independent of the model of outputs used, that is, whether demonic or angelic, since these are just coded up in the refusals, and refusal information is preserved across the failures-divergences model and the finalisation. Theorem 4.2 In the blocking model, relational refinement with extended finalisations corresponds to failures-divergences refinement. 23

Boiten and Derrick

Proof. 1. Assume the ADT A = (AState, AInit, {AOpi }i∈I , AFin) is refined by C = (CState, CInit, {COpi }i∈I , CFin). We have to prove that every failure (tr , X ) of C is also a failure of A. W.l.o.g., let tr = hi1 , . . . , in i. tr being a trace of C means that operations within are not refused, hence as a relation CInit o9 COpi1 o9 . . . o9 COpin o9 CFin contains a defined pair (is, h i, e) 7→ (hi, os, E ). Moreover, it will contain such a pair for E = X . By relational refinement this pair is also in AInit o9 AOpi1 o9 . . . o o 9AOpin 9 AFin. Thus (tr , X ) is a refusal of A as required. 2. For the reverse implication, suppose we have failures-divergences refinement. We have to show that relational refinement follows, e.g., that CInit o9 COpi1 o9 . . . o9 COpin o9 CFin ⊆ AInit o9 AOpi1 o9 . . . o9 AOpin o9 AFin. Now CInit o9 COpi1 o9 . . . o9 COpin o9 CFin as a totalised relation will map (is, h i, e) to either (hi, os, E ) for some set of events E or to ⊥G . In the former case we can construct a valid trace tr of C. This is given by the operations in the program tagged with their corresponding input and output: tr = hi1 .is(1).os(1), . . . , in .is(n).os(n)i. Thus (tr , E ) is in the failures of C and hence in the failures of A. This implies that ((is, h i, e), (hi, os, E )) ∈ AInit o9 AOpi1 o9 . . . o9 AOpin o9 AFin as required. In the latter case, an outcome of ⊥G means that one of the operations was refused in the program. Assume that this first happened after the j -th step. Thus schematically we have (note that LC is the full local state seq Input × seq Output × CState): CInit o9COpi1 o9 . . . o9 COpij o9 COpij+1 o9 (is, h i, e) 7→ (is 0 , os 0 , cs) 7→ ⊥LC

. . . o9 COpin o9 7→ ⊥LC

CFin 7 → ⊥G

By failures-divergences refinement we know that (hi1 .is(1).os(1), . . . , ij .is(j ).os(j )i, {ij +1 .is(j + 1).os(j + 1)}) is in the failures of C. Thus, for some local state as of A, AInit o9AOpi1 o9 . . . o9 AOpij o9 AOpij+1 o9 (is, h i, e) 7→ (is 0 , os 0 , as) 7→ ⊥LA

. . . o9 AOpin o9 AFin 7→ ⊥LA 7→ ⊥G

Thus ((is, h i, e), ⊥G ) ∈ AInit o9 AOpi1 o9 . . . o9 AOpin o9 AFin. Hence, for the blocking model, relational refinement is equivalent to failuresdivergences refinement. 2

4.4 The simulation rules We now know that under the (natural) correspondence, relational refinement corresponds to failures-divergences refinement. It remains now to extract simulation rules that can be applied to the schema calculus, since we do not wish to work with sets of events as currently embedded in the finalisation. Fortunately we can do this. 24

Boiten and Derrick

Maximal refusal sets in the demonic model Prior to discussion of the simulation conditions, we consider the nature of maximal refusal sets for a particular state in the demonic model. Any maximal refusal set can be partitioned into independent maximal subsets for each particular operation and input, as the only restriction on membership refers to different outputs for the same operation and input. A maximal collection of refused events for any particular operation i and input in is either •

{(i , in, out)} for all values of out, representing the fact that operation i is blocked for input in in this state, or

•

{(i , in, out)} for all values of out except out = out 0 , representing the fact that operation i is enabled for input in in this state, and that it may result in output out 0 .

As a consequence, there is no guarantee that there is a single maximal refusal set for any given state, and thus an analogon of Ref (State) cannot be defined in this model. (This could also be concluded from the “negative occurrence” of E , “(i , in, θ!Opi ) 6∈ E ”, in its characterisation in Definition 4.1.) The relevance of maximal refusal sets is in proofs: when we need to prove inclusion of concrete refusal sets in abstract refusal sets, it is sufficient to consider maximal concrete refusal sets only, as downward closedness of abstract refusal sets then guarantees inclusion of all. Note that this does not imply a maximal refusal semantics: the maximal refusal sets that are observed in finalisation are the unions of all maximal refusal sets in all concrete (linked) states, e.g., returning the full set for a particular i and in if it is blocked in some final state. Downwards simulations in the demonic model Remember that the condition we have to work with is R o9 CFin ⊆ AFin. Theorem 4.3 The condition R o9 CFin ⊆ AFin in the demonic model is subsumed by the normal applicability and correctness rules. Proof. Consider a maximal set of refusals E for a given concrete state cs and a specific operation i and input in. For any event (i , in, out), we need to prove that it belongs to the set for the abstract case in condition Fcond in Definition 4.1. First, if it belongs to E because of the first disjunct (“(i , in, out) is impossible from cs”) then there are two possibilities. Either pre COpi does not hold for cs and in, in which case, by the applicability condition, pre AOpi does not hold for any linked abstract state and in, and thus (i , in, out) satisfies the conditions on the abstract side. The other possibility is that pre COpi does hold for cs and in, but out is not one of the possible outputs in that case, let us call these couts. If out is not possible in the linked abstract state, 25

Boiten and Derrick

the correctness condition also covers it being impossible in this concrete state. If out is possible in the linked abstract state, then in that state also any of the outputs from couts is possible, due to the correctness condition, and this concrete refusal set E corresponds in the abstract case to one that represents choosing a different output from couts. If (i , in, out) belongs to E because of the second disjunct (“(i , in, out 0 ) is also possible for out 6= out 0 ”), then the correctness condition guarantees that both out and out 0 are possible in any linked abstract state, and thus (i , in, out) can be refused there for the same reason. 2 An essential observation is that downwards simulation allows reduction of non-determinism of outputs. An output that is possible in the abstract system but not in the concrete system could be refused in either system: in the concrete one because it is impossible, in the abstract one because an alternative output exists. The other downward simulation conditions are unchanged compared to those in Section 2.4, the minor change to the initialisation embedding has no consequences.

Upwards simulations in the demonic model In a similar fashion we can extract the requirements due to upwards simulations, with only the finalisation condition leading to an extra condition. The requirement that CFin ⊆ T o9 AFin, as before, can be simplified to remove all reference to the input and output streams. What remains is a condition on refusals (where FcondC and FcondA are concrete and abstract versions of the demonic Fcond condition in Definition 4.1): ∀ CState; E • FcondC ⇒ ∃ AState • T ∧ FcondA As Fcond is satisfied for E = ∅, this implies the usual condition of totality of T on the concrete state. Now consider a maximal refusal set E in the concrete case, in a particular state. As argued above, this set represents, for each operation i and input in, whether it is blocked (in which case E contains all (i, in, out) tuples), or whether a particular output out 0 is chosen (in which case E contains all (i , in, out) events for which out 6= out 0 ). The quantification is such that for each such maximal refusal set, a different linked abstract state may be chosen. That this is necessary is clear from the following example. Example 4.4 Consider the datatypes C = (CState, CInit, {COp1 }) and A = (AState, AInit, {AOp1 }), where CState == [ c : {1, 2} ] 26

Boiten and Derrick

CInit CState 0 c0 = 1

COp1 ∆CState x ! : {3, 4} c = 1 ∧ c0 = 2 x! = 3 ∨ x! = 4 AState == [ a : {0, 1, 2} ] AInit AState 0 a0 = 1 ∨ a0 = 0

AOp1 ∆AState x ! : {3, 4} (a = 0 ∨ a = 1) ∧ a 0 = 2 (a = 0 ⇒ x ! = 3) ∧ (a = 1 ⇒ x ! = 4) The following is an upward simulation in the demonic model: T AState; CState a=2⇔c=2 (a = 0 ∨ a = 1) ⇔ c = 1 Observe that this is the traditional example of an upward (but not downward) simulation, involving postponement of non-determinism, here transferred to non-determinism of outputs. The finalisation condition is only of interest for the empty program, i.e., for the initial states. State a = 0 contributes refusals {∅, {(1, ∗, 4)}}, state a = 1 contributes refusals {∅, {(1, ∗, 3)}}; the refusals in c = 1 are the union of these sets. This concrete state has no single maximal refusal set. In checking the finalisation condition, it needs to consider different linked abstract states for different maximal concrete refusal sets. 2 Thus, even in the context of a data type with just a single operation, we need to look at different linked states for different output values. This seems 27

Boiten and Derrick

somewhat at odds with the upward simulation condition for finalisations which we had before, which insisted on choosing the same linked abstract state for every set of enabled operations. In fact, the consideration of maximal refusal sets represents exactly the combination of these two conditions, as we will see below. Another illustrative example, which highlights the difference between sequential and concurrent refinement in the context of outputs, is the following. Example 4.5 Consider data types P = (PState, PInit, {POpi }i∈I ) and Q = (QState, QInit, {QOpi }i∈I ), for I = {1, 2}, where PState p : {p0, p1, p2}

QState q : {q0, q1, q2}

PInit PState 0

QInit QState 0

p 0 = p0 ∨ p 0 = p1

q 0 = q0 ∨ q 0 = q1

POp1 ∆PState out! : {o1, o2}

QOp1 ∆QState out! : {o1, o2}

(p = p0 ∨ p = p1) ∧ p 0 = p2 p = p0 ⇒ out! = o1 p = p1 ⇒ out! = o2

(q = q0 ∨ q = q1) ∧ q 0 = q2 q = q0 ⇒ out! = o1 q = q1 ⇒ out! = o2 QOp2 ∆QState out! : {o1, o2}

POp2 == POp1

(q = q0 ∨ q = q1) ∧ q 0 = q2 q = q0 ⇒ out! = o2 q = q1 ⇒ out! = o1 The relation linking all initial states, and linking all final states, is an upward simulation according to Definition 3.3 (in either direction – the ADTs are symmetric), see also [3]. However, failures-divergences refinement does not hold between these two systems. The upwards simulation finalisation condition fails for the initial states, as they have incomparable refusal sets. For example, p1 has as its refusals P{(1, ∗, o1), (2, ∗, o1)}, whereas the maximal refusals of q0 and q1 contain one of those events each (plus another one from p2’s refusals). Note also that this example has the same relevance for the angelic and demonic models: due to absence of output non-determinism the models lead to identical refusals. 2 The example above shows clearly that we cannot reason from individual 28

Boiten and Derrick

refused events, and choose appropriate linked abstract states for each such event. The simplest way to express the condition is now via the complements of maximal refusal sets, as these are relatively small sets, consisting of at most one event for each operation plus input. This is characterised by the following definition Sim == (I , Input) → 7 Output Sim (for simultaneously offered events) is the type of sets of tuples ((i , in), out) such that for every pair (i , in) at most one out occurs in the set. We formalise an event being “possible” in a certain state of an ADT: State

((i,in),out)

−→ == ∃ State 0 ; Input; Output • COpi ∧ θInput = in ∧ θOutput = out

Similarly, an (operation, index) combination may be disabled in a particular state: (i,in)

State 6−→ == ¬ ∃ State 0 ; Output • COpi ∧ θInput = in The interpretation of an element of Sim as the complement of a maximal refusal set in a particular state is that all the events in it are enabled, and every (operation, index) combination outside its domain is disabled. iin

e

Maxref (E , State) == (∀ e : E • State −→) ∧ (∀ iin : dom E • State 6−→) Taking into account that a linked abstract state may refuse some of the chosen events, and must refuse all the disabled ones, the finalisation condition is: ∀ CState; E : Sim • Maxref (E , CState) ⇒ ∃ AState; E 0 : Sim • T ∧ E 0 ⊆ E ∧ MaxRef (E 0 , AState) This condition is stronger than normal applicability, but it also contains an element of correctness, as can be seen from the similarity to the following consequence of standard upward simulation correctness: ∀ CState; in : Input; out : Output; i : I • CState

((i,in),out)

−→ ⇒ ∃ AState • T ∧ AState

((i,in),out)

−→

The angelic model of outputs We can now also vary the conditions to use the angelic model of outputs. The differences between the models in terms of refinement are simple: in the demonic model we can reduce non-determinism in the outputs, but in the 29

Boiten and Derrick

angelic version we cannot. This difference can be expressed in the simulation rules by using a different precondition operator. As described in [33], the change needed is to alter the definition of pre Op to include existential quantification of the after state only (and not the output), since we wish to exclude reduction of non-determinism of the output. Hence for an operation Op defined over state space State we define Pre Op == ∃ State 0 • Op, and use Pre in place of pre in some of the simulation conditions. Refinements in this model behave exactly as before, except non-determinism in outputs cannot be resolved. Downwards simulations in the angelic model Interestingly now the finalisation condition for a downwards simulation is not subsumed by the other conditions. Rather, it now adds the constraint that non-deterministic outputs cannot be reduced in a refinement. In addition, the condition Fcond is expressed in such a way that we can define a unique maximal refusal set Ref (State). Ref (State) == {(i , in, out) | ¬ ∃ State 0 ; Input; Output • Opi ∧ in = θInput ∧ out = θOutput} With a proof analogous to that in Section 3, we get ∀ R • (Ref (CState) ⊆ Ref (AState)) which becomes ∀ R; i : I ; Input; Output • Pre AOpi ⇒ Pre COpi which is stronger than the standard applicability condition. In the context of standard applicability, an equivalent formulation is ∀ R; i : I ; Input; Output • Pre AOpi ∧ pre COpi ⇒ Pre COpi Upwards simulations in the angelic model The simplified condition for upwards simulation finalisation, ∀ CState; E • FcondC ⇒ ∃ AState • T ∧ FcondA similarly can be expressed in terms of maximal refusal sets, and (re-)using the proof from Appendix A becomes ∀ CState • ∃ AState • T ∧ ∀ Input; Output; i : I • Pre AOpi ⇒ Pre COpi We thus have a number of different possible simulation rules for both downward and upward simulation covering the cases of blocking vs non-blocking and 30

Boiten and Derrick

demonic vs angelic. In each case, due to the extended finalisation, the simulation rules are sound and jointly complete with respect to failures-divergences refinement. We can now provide a complete characterisation of all the possibilities. For downward simulation, the various conditions are: DS.Init ∀ CState 0 • CInit ⇒ ∃ AState 0 • AInit ∧ R 0 DS.App ∀ R; i : I ; Input • pre AOpi ⇒ pre COpi DS.CorrBlock ∀ i : I ; Input; Output; R; CState 0 • COpi ⇒ ∃ AState 0 • R 0 ∧ AOpi DS.FinAng ∀ R; i : I ; Input; Output • Pre AOpi ⇒ Pre COpi The following rules are required in the various situations; conditions dominated by stronger conditions have been omitted. Outputs: none

Demonic

Init

Angelic

DS.Init

App

DS.App

-

Corr

DS.CorrBlock

Fin

-

DS.FinAng

For upward simulation, the various conditions are: US.Init ∀ T 0 • CInit ⇒ AInit US.CorrBlock ∀ i : I ; Input; Output; T 0 ; CState • COpi ⇒ ∃ AState • T ∧ AOpi US.FinRef ∀ CState • ∃ AState • T ∧ ∀ i : I ; Input • pre AOpi ⇒ pre COpi US.FinDem ∀ CState; E : Sim • Maxref (E , CState) ⇒ ∃ AState; E 0 : Sim • T ∧ E 0 ⊆ E ∧ MaxRef (E 0 , AState) US.FinAng ∀ CState • ∃ AState • T ∧ ∀ Input; Output; i : I • Pre AOpi ⇒ Pre COpi They are required in the following situations: Outputs: none

Demonic

Angelic

Init

US.Init

App

-

Corr

US.CorrBlock

Fin

US.FinRef US.FinDem US.FinAng

31

Boiten and Derrick

5

Other Refinement Relations

As indicated in the introduction, failures-divergences is but one of a number of refinement relations that have been proposed in a concurrent setting. These include trace refinement [21], a very coarse notion of refinement, up to bisimulation [27] which (as an equivalence) identifies fewer processes. In between these lie numerous semantic models which give rise to refinement preorders. A survey of these, and the relationship between them is given in [39]. Using our extended relation model, with its generalisation of finalisation, we can model these concurrent semantics in a relational setting. This answers the question posed in the introduction: why are there more concurrent refinement relations than relational ones. The answer is that there are not, it was just that the relational model was taking one particular choice about observations, and it is the extent of observations available that differentiates between the concurrent refinement relations. In the full paper, we consider the readiness model, as proposed by Olderog and Hoare [28], in full detail. Some concurrent refinement relations make observations not only at the end of a trace, but also while the process is evolving. For example, failuretrace refinement [23] considers refusals sets not only at the end of a trace, but also between each action in a trace. Failure-trace refinement is inclusion of failure-traces, where a failure-trace of a process P is of the form tr = X1 a1 X2 a2 . . . Xn an Xn+1 where a1 a2 . . . an is a trace of P and each (a1 . . . ai , Xi+1 ) is a failure of P . To model this type of refinement relation in a relational context we would not just use a finalisation that observes failures, but we would have to observe failures at every step. As a consequence, a sequence of failures at intermediate points would be added to the local state and treated analogously to the output sequence. The crucial observation would be made before every operation, as follows: Op == {Opi ; is : seq Input; os : seq Output; fs : seq P Event; E : P Event | Fcond • (hθ?Opi i a is, os, fs, θState) 7→ (is, os a hθ!Opi i, fs a hE i, θState 0 )} using the appropriate condition Fcond from Definition 4.1.

6

Related Work

Work relating concurrent and state-based refinement includes work on semantic aspects due to Josephs [22], He [18] and Woodcock and Morgan [42], as well as work dealing with the specific correspondence discussed here by Bolton and Davies [3,2]. Relevant also is the work on integrated formal notations, see for example [31,34,12,13,25,17,38,14], as well as that on related questions such as subtyping [16,40,24]. 32

Boiten and Derrick

The aim of the work of Josephs, He, and Woodcock and Morgan [22,18,42] was the same as ours, namely to derive simulation techniques suitable for verifying concurrent refinement relations. There are two main differences to the work presented here: a relational model is not used, and the simulation conditions are presented in a different format. The former is a semantic issue, whilst the latter has consequences for the translation of the conditions for use within particular specification notations (e.g., Z or Object-Z). For example, Josephs [22] uses a labelled transition system framework and derives downward and upward simulation conditions for CSP failures refinement (he considers only divergence free processes). The conditions he derives are essentially the same as those we have derived above in Definitions 2.9 and 3.3. What we have added here (in addition to the use of the relational framework) is to articulate these correctly within the schema calculus setting, and this needed a careful consideration of inputs and outputs, something that was not considered in [22]. The work of Woodcock and Morgan [42] is essentially the same as [22] but uses a wp-semantics instead of a labelled transition system framework. Integrations of state-based languages and process algebras led to more recent work on simulation rules for failures-divergences refinement. In particular, combinations of Object-Z and CSP required the use of simulation rules in Object-Z which were compatible with CSP failures-divergences refinement. Unfortunately, the simulation rules as presented in, for example, Josephs [22] were incorrectly translated into a schema calculus setting [33,4,15]. The mistake made was in the quantification over all possible operations in the upwards simulation conditions (and arose because only one operation was considered, and the difference in the quantification only arises when there is more than one operation). Thus Definition 2.10 was presented instead of Definition 3.3. This error was recently pointed out by Bolton and Davies [2]. They showed that data refinement (as in Definition 2.3 and verified by simulations according to Definitions 2.9 and 2.10) did not correspond to failures-divergences refinement, but to a slightly different semantic model which they termed singleton failures. (The name relates to the fact that refusal sets are at most singletons.) The work in [2] also did not consider failures-divergences refinement, but in [3] they extended [2] by presenting a translation of the Josephs rules from [22] to the Object-Z schema calculus. The rules presented correspond to failure-divergence refinement for specifications without output. In fact, this does correct the mistakes from [33,4,15] in terms of a system with more than one operation, however, as we have seen above, there are further problems due to the treatment of outputs. So the upward simulation conditions given in [3] do not fully cover specifications with outputs, as we have discussed in Section 4.4. Simulation rules for other concurrent refinement relations such as readiness refinement [28] and failure-traces [23] have, to our knowledge, not been derived before. These will appear in the full version of this paper. 33

Boiten and Derrick

Apart from the work of Bolton, none of this work uses a relational model and, in particular, the use of finalisations has not been explored before. The relational model we used in Section 2.1 is the standard model [18]. The embedding of partial relations (and hence the Z schema calculus) was first articulated in [41] and a comprehensive treatment appeared in [9]. The use of different models of outputs, demonic and angelic, goes back to work on combining Object-Z and CSP, and different appraoches to integrated languages have chosen differing models of outputs. For example, [31] adopts an angelic output model, however, the majority of work on integrating ObjectZ and CSP have used the demonic model of outputs. The latter includes [13,25,34]. A discussion of the merits of both approaches is contained in [35]. The other related work mentioned above either deals with standard Z simulation rules (or, in fact, variants for Object-Z) [33,34,12] or widens the discussion to subtyping [16,40] which considers additional operations to those present in the initial specification.

7

Conclusions

The aim of this paper was to present a comprehensive treatment of relational and concurrent refinement relations. We saw that the simulation rules for failure-divergences refinement are stronger than the simulation rules derived from the simpler relational model, and presented for Z in [41,9]. For systems without output our results agree with those given in [22] and [3]. In our opinion, the main contribution of our work is the uniform treatment of both sequential and concurrent refinement as afforded by our relational model. To do this we used finalisations in a manner which was novel. This allowed the correct simulation rules for failure-divergences refinement to be derived. The results go beyond failure-divergences refinement though, since we aimed to provide a mechanism by which further concurrent refinement relations could be considered. This we did, and illustrated the approach by deriving simulation rules for failure-trace refinement. Other relations will be considered in the full version of this paper and in further work. These are preliminary results, and much remains to be done. For example, work on simulation techniques for systems containing internal operations includes [11,10], and this could be incorporated into the framework we presented above. Work on testing in a state-based system could also be invigorated by applying results from the testability of process algebras [5] via the simulation results presented above. 34

Boiten and Derrick

References [1] Bolognesi, T. and E. Brinksma, Introduction to the ISO Specification Language LOTOS, Computer Networks and ISDN Systems 14 (1988), pp. 25–59. [2] Bolton, C. and J. Davies, A Singleton Failures Semantics for Communicating Sequential Processes (2002), under consideration. [3] Bolton, C. and J. Davies, Refinement in Object-Z and CSP, in: M. Butler, L. Petre and K. Sere, editors, Integrated Formal Methods (IFM 2002), Lecture Notes in Computer Science 2335 (2002), pp. 225–244. [4] Bolton, C., J. Davies and J. C. P. Woodcock, On the refinement and simulation of data types and processes, in: K. Araki, A. Galloway and K. Taguchi, editors, International conference on Integrated Formal Methods 1999 (IFM’99) (1999), pp. 273–292. [5] Brinksma, E., G. Scollo and C. Steenbergen, Process specification, their implementation and their tests, in: B. Sarikaya and G. v. Bochmann, editors, Protocol Specification, Testing and Verification, VI (1986), pp. 349–360. [6] Brookes, S. D., C. A. R. Hoare and A. W. Roscoe, A theory of communicating sequential processes, Journal of the ACM 31 (1984), pp. 560–599. [7] Brookes, S. D. and A. W. Roscoe, An improved failures model for communicating processes, in: Pittsburgh Symposium on Concurrency, Lecture Notes in Computer Science 197 (1985), pp. 281–305. [8] de Roever, W.-P. and K. Engelhardt, “Data Refinement: Model-Oriented Proof Methods and their Comparison,” CUP, 1998. [9] Derrick, J. and E. A. Boiten, “Refinement in Z and Object-Z,” Springer-Verlag, 2001. [10] Derrick, J., E. A. Boiten, H. Bowman and M. W. A. Steen, Weak refinement in Z, in: J. P. Bowen, M. G. Hinchey and D. Till, editors, ZUM’97: The Z Formal Specification Notation, Lecture Notes in Computer Science 1212 (1997), pp. 369–388. [11] Derrick, J., E. A. Boiten, H. Bowman and M. W. A. Steen, Specifying and Refining Internal Operations in Z, Formal Aspects of Computing 10 (1998), pp. 125–159. [12] Derrick, J. and G. Smith, Structural refinement in Object-Z/CSP, in: W. Grieskamp, T. Santen and B. Stoddart, editors, International conference on Integrated Formal Methods 2000 (IFM’00), Lecture Notes in Computer Science 1945 (2000), pp. 194–213. [13] Fischer, C., CSP-OZ - a combination of CSP and Object-Z, in: H. Bowman and J. Derrick, editors, Second IFIP International conference on Formal Methods for Open Object-based Distributed Systems (1997), pp. 423–438.

35

Boiten and Derrick

[14] Fischer, C., How to combine Z with a process algebra, in: J. P. Bowen, A. Fett and M. G. Hinchey, editors, ZUM’98: The Z Formal Specification Notation, Lecture Notes in Computer Science 1493 (1998), pp. 5–23. [15] Fischer, C., “Combination and implementation of processes and data: from CSP-OZ to Java,” Ph.D. thesis, University of Oldenburg (2000). [16] Fischer, C. and H. Wehrheim, Behavioural subtyping relations for objectoriented formalisms, in: T. Rus, editor, Algebraic Methodology and Software Technology, Lecture Notes in Computer Science 1816 (2000), pp. 469–483. [17] Galloway, A. and W. Stoddart, An operational semantics for ZCCS, in: Hinchey and Liu [20], pp. 272–282. [18] He Jifeng, Process refinement, in: J. McDermid, editor, The Theory and Practice of Refinement (1989). [19] He Jifeng, C. A. R. Hoare and J. W. Sanders, Data refinement refined, in: B. Robinet and R. Wilhelm, editors, Proc. ESOP’86, Lecture Notes in Computer Science 213 (1986), pp. 187–196. [20] Hinchey, M. G. and S. Liu, editors, “First International Conference on Formal Engineering Methods (ICFEM’97),” IEEE Computer Society Press, Hiroshima, Japan, 1997. [21] Hoare, C. A. R., “Communicating Sequential Processes,” Prentice Hall, 1985. [22] Josephs, M. B., A state-based approach to communicating processes, Distributed Computing 3 (1988), pp. 9–18. [23] Langerak, R., “Transformations and Semantics for LOTOS,” Ph.D. thesis, University of Twente, The Netherlands (1992). [24] Liskov, B. and J. M. Wing, A behavioural notion of subtyping, ACM Transactions on Programming Languages and Systems 16 (1994), pp. 1811– 1841. [25] Mahony, B. and J. Dong, Blending Object-Z and timed CSP: An introduction to TCOZ, in: K. Futatsugi, R. Kemmerer and K. Torii, editors, 20th International Conference on Software Engineering (ICSE’98) (1998). [26] Miarka, R., E. A. Boiten and J. Derrick, Guards, preconditions and refinement in Z, in: J. P. Bowen, S. Dunne, A. Galloway and S. King, editors, ZB2000: Formal Specification and Development in Z and B, Lecture Notes in Computer Science 1878 (2000), pp. 286–303. [27] Milner, R., “Communication and Concurrency,” Prentice-Hall, 1989. [28] Olderog, E.-R. and C. A. R. Hoare, Specification-oriented semantics for communicating processes, Acta Informatica 23 (1986), pp. 9–66. [29] Roscoe, A. W., An alternative order for the failures model, Journal of Logic and Computation 3 (1993).

36

Boiten and Derrick

[30] Roscoe, A. W., “The Theory and Practice of Concurrency,” International Series in Computer Science, Prentice-Hall, 1998. [31] Smith, G., A semantic integration of Object-Z and CSP for the specification of concurrent systems, in: J. Fitzgerald, C. B. Jones and P. Lucas, editors, FME’97: Industrial Application and Strengthened Foundations of Formal Methods, Lecture Notes in Computer Science 1313 (1997), pp. 62–81. [32] Smith, G., “The Object-Z specification language,” Kluwer Academic Publishers, 2000. [33] Smith, G. and J. Derrick, Refinement and verification of concurrent systems specified in Object-Z and CSP, in: Hinchey and Liu [20], pp. 293–302. [34] Smith, G. and J. Derrick, Specification, refinement and verification of concurrent systems - an integration of Object-Z and CSP, Formal Methods in Systems Design 18 (2001), pp. 249–284. [35] Smith, G. and J. Derrick, Abstract specification in Object-Z and CSP, 2002, submitted for publication. [36] Spivey, J. M., “The Z notation: A reference manual,” International Series in Computer Science, Prentice Hall, 1992, 2nd edition. [37] S¨ uhl, C., RT-Z: An integration of Z and timed CSP, in: K. Araki, A. Galloway and K. Taguchi, editors, International Conference on Integrated Formal Methods (IFM’99) (1999), pp. 29–48. [38] Treharne, H. and S. Schneider, Using a process algebra to control B operations, in: K. Araki, A. Galloway and K. Taguchi, editors, International Conference on Integrated Formal Methods 1999 (IFM’99) (1999), pp. 437–456. [39] van Glabbeek, R. J., The linear time - branching time spectrum, in: J. C. M. Baeten and J. W. Klop, editors, CONCUR 90, Lecture Notes in Computer Science 458 (1990), pp. 278–297. [40] Wehrheim, H., Behavioural subtyping and property preservation, in: S. F. Smith and C. L. Talcott, editors, Formal Methods for Open Object-Based Distributed Systems (FMOODS 2000) (2000), pp. 213–231. [41] Woodcock, J. C. P. and J. Davies, “Using Z: Specification, Refinement, and Proof,” Prentice Hall, 1996. [42] Woodcock, J. C. P. and C. C. Morgan, Refinement of state-based concurrent systems, in: D. Bjorner, C. A. R. Hoare and H. Langmaack, editors, VDM’90: VDM and Z!- Formal Methods in Software Development, Lecture Notes in Computer Science 428 (1990).

Appendix A Given is ∀ E ; CState • E ⊆ Ref (CState) ⇒ ∃ AState • (T ∧ E ⊆ Ref (AState)) 37

Boiten and Derrick

Because E and Ref (CState) are independent from AState, this is equivalent to ∀ E ; CState • ∃ AState • E ⊆ Ref (CState) ⇒ (T ∧ E ⊆ Ref (AState)) We would like to prove this equivalent to: ∀ CState • ∃ AState • T ∧ Ref (CState) ⊆ Ref (AState) Proof. We will prove this by mutual implication: ∀ CState • ∃ AState • T ∧ Ref (CState) ⊆ Ref (AState) ≡ {property of ⊆} ∀ CState • ∃ AState • T ∧ ∀ E • E ⊆ Ref (CState) ⇒ E ⊆ Ref (AState) ≡ {∃ E • E ⊆ Ref (CState)} ∀ CState • ∃ AState • ∀ E • E ⊆ Ref (CState) ⇒ T ∧ E ⊆ Ref (AState) ⇒ {predicate calculus} ∀ CState; E • ∃ AState • E ⊆ Ref (CState) ⇒ T ∧ E ⊆ Ref (AState) ⇒ {specialise for E = Ref (CState)} ∀ CState • ∃ AState • T ∧ Ref (CState) ⊆ Ref (AState) 2

38