A Provably Correct Functional Programming Approach to the Prototyping of Formal Z Specifications Ali E. Abdallah1

Alexandra Barros∗

Jonathan P. Bowen1

Jos´e B. Barros2

1

South Bank University, Centre for Applied Formal Methods School of Computing, Information Systems & Mathematics (SCISM) Borough Road, London SE1 0AA, UK Email: {abdallae, bowenjp}@sbu.ac.uk URL: http://www.cafm.sbu.ac.uk/ 2

Universidade do Minho, Campus De Gualtar, 4710 Braga, Portugal Email: [email protected]

Abstract

ated with modern functional languages; for example, strong typing, polymorphic types, lazy evaluation and higher-order constructs. The aim of the work presented here is twofold: firstly, to find a systematic way of building prototypes for Z specifications; secondly, to be able to prove that a prototype correctly implements its original specification. Correctness of prototypes can only be proved if the ‘translation’ process has a formal basis. Hence we have to establish a formal relationship between Z specifications and functional prototypes. This relationship is based on model refinement in the sense of specification refinement in the model-oriented specification style as described for example in [30]. It builds on two other formal relationships: one between Z and Miranda data types, and another between Z predicates and Miranda Boolean expressions. To reduce the number of proofs required in model refinement, we have defined a set of rules based upon the established relationships that allow us to build prototypes that are implicitly correct. Conversion of formal specifications in Z and VDM [23] to logic and functional languages has been reported in the literature for a number of years so that the notion as such is not original. Being a logic-based language, Prolog [26] appears to be a good candidate to use for the prototyping of specifications written in first order predicate logic like Z (and VDM). In fact, an approach pursued by a number of researchers is the translation of model-based specifications [10] to Prolog (e.g., see [21, 34]). An advantage of this approach is that operations defined through relations can be directly implemented. However there is no algorithmic way of transforming first order predicate logic into Horn clauses and, since there are no types in Prolog, the notion of objects belonging to different types is lost and must be coded explicitly if required. On the other hand, the structure of a model-based specification often takes on the form of a functional program. There will be some abstract types

This paper describes a systematic way of constructing correct prototypes in a functional language such as Miranda or Haskell from Z specifications. A formal relationship between Z specifications and functional prototypes is established. This relationship is based on model refinement in the sense of specification refinement in the model-oriented specification style. To reduce the number of proofs required in model refinement, we have defined a set of rules that allow us to derive a prototype from a specification. The use of such a set of rules implicitly guarantees the correctness of the derivation. Keywords: Formal specification, Functional programming, Prototyping, Refinement, Z notation.

1

Introduction

The advantages of starting the development of a software system by writing its specification in a high-level formal notation are well-known for systems of the highest integrity [12, 22]. It is recommended practice for software engineers working on systems where safety or security is paramount [7]. Using the specification to prove or derive properties of the system is one way of exploring the behavior of the system without implementing it. Devising executable prototypes (preferably automatically) from formal specifications is another important aspect of validation. The existence of a rapid prototype can be useful in the acceptance of a specification [6] and also for testing purposes [32]. This paper describes work that is focused on the development of prototypes written in a functional language such as Miranda [14] or Haskell [31] for Z specifications [8]. These funtional programming languages have characteristics that are associ∗ Supported

by JNICT under contract no. BD/1103/90-IA.

1

2

and operations manipulating objects of these types. Hence other researchers prefer the alternative approach of translating the specification to a functional language (e.g., see [15, 17, 25, 28]). More recently, a combination of the functional and logic language approach has been found to be useful for both execution and testing [18, 19]. Although the approach presented can be included in the group that uses a functional language as the prototyping language, there is a major difference between the way we tackle the problem and the manner in which it has been treated previously. The main concern of papers proposing prototyping techniques has been to find a systematic method for building prototypes. However such methods have been devised in an informal ad hoc manner. Hence there is no possibility of checking if a prototype built using one of those procedures correctly implements the original specification. By contrast, we have established a formal relationship between Z specifications and functional prototypes. Consequently it is possible to check if a prototype is a correct implementation of a specification. Furthermore, based on such relationship, we have defined a systematic way of deriving correct prototypes from specifications in order to reduce the number of proofs required in model refinement. The refinement relationship we have established between Z specifications and prototypes is based on data refinement for Z specifications as described in [30], and builds on a relationship between Z data types and Miranda data types that is founded on abstract data types refinement as explained, for example, in [5]:

From Z Specifications to Prototypes

Formal specifications are not directly executable in general [20] although some believe they should be if possible [16]. This is a differentiating feature from a program, which must be executable. A specification should concentrate on the what rather than the how. It can be possible to present a specification in a natural way that is also executable (e.g., see [9]) but normally some compromise is required. Here we assume that the original Z specification has been produced solely with specification (for understandability and perhaps proof of correctness) rather than executability in mind and thus is unlikely to be executable as it stands. For a discussion on the executability of Z, see [13]. For an example of an intermediate specification language based on Z, see [29]. To model a system in Z, as in any specification language with the level of abstraction adequate to define large systems, we can use non-executable definitions and data types that are not oriented towards computer representation [10]. As a consequence, in general, to build an executable version of the specification we have to go through the following two steps: firstly, refinement of the abstract specification A into a concrete model C; secondly, translation of C into the prototyping language. Refinement in this context is model-refinement, i.e. specification refinement in the model-oriented specification style as described for example in [30]. The motivation for refining a specification may be to obtain a design nearer the implementation language or to obtain an efficient design [1]. In the prototyping context, refinement aims at replacing the original specification by a design that may be “directly” translated into some programming language, in our case into a functional language. If the specification is expressed in terms of objects that are not directly implementable, it has to go through data refinement in order to be substituted for a model whose objects have Miranda counterparts. Functions defined in an implicit1 way, and nondeterministic operations have to go through operation refinement. In the case of an implicit specification, an “algorithm” to calculate the after-state values and outputs explicitly has to be found. A non-deterministic operation has to be substituted for a deterministic function that chooses one of the possible values belonging to the range of the relation that defines the operation. This high-level refinement process needs to be undertaken for the final implementation anyway. For a prototype system, this refinement process can be undertaken within the context of Z. For the final system, much further more detailed refinement (e.g., in the style of development encouraged by the B-Method [3]) will be required. Z Cartesian product types, sequences, integers, and natural numbers have “direct” counterparts in Miranda. Sets, binary relations, mappings and bags are not directly available.

Concrete objects of type C are related to the abstract objects of type A they represent by an abstraction (or “retrieve”) function retr with type retr :: C → A.i If retr c = a, then c is said to represent the value a. The abstract data type T specified by the operations aop1 . . . aopn is refined by the concrete type t if, for each aopi : t1 . . . tm → tn , there is a concrete function opi such that retr (opi x1 . . . xm ) = aopi (retr x1 ) . . . (retr xm ). See also [24] for related concepts of refinement. The following notation will be used in this paper: ˜ D stands for the concrete data representation of D, and ˆ T stands for the representing type of T. Alternatively we use A vT a to denote the fact that a is the representing type of A. In Section 2 we describe the class of Z specifications for which a prototype can be “automatically” derived and given an example of how a Z schema can be systematically implemented in a functional language. In Section 3 we establish a formal relationship (founded on model refinement) between Z specifications and functional prototypes. In Section 4 we present a set of refinement rules based upon the definitions given in the previous section that allow the construction of prototypes that are implicitly correct. For a fuller version of this paper, see [2].

1 An implicit specification establishes what is intended to be computed. On the other hand, an explicit specification shows how a result can be computed.

2

Hence data refinement needs have to be done in specifications that involve these kinds of objects before they could be translated. To enlarge the class of specifications that can be automatically prototyped, we have implemented them so that they have become pre-defined Miranda types. In the prototyping context, it seems a good idea for the programmer to provide a selection of different representations for a given data type. For each particular application, a representation is chosen from the available ones, accordingly to the features required for that specific problem (efficiency, generality, etc.). For example, two different representations of finite sets could be available: ordered lists and lists with no duplicates. The first is more efficient, but the second is more general since it can be used to represent non-ordered sets. There should also be a representation of infinite sets available. A possible implementation of infinite sets is proposed in [5]; a set is represented by a function that tests for membership. Two implementations of sets (using ordered lists and lists with no duplicates), and representations for relations, mappings and bags can be found in [4]. In [2] we demonstrated how a (partially refined) Z specification can be implemented in a functional language.

3

the correspondence between the Miranda implementation of sets using ordered lists (set ˜ A) and the Z finite set type (F A): ˜ → FA retrSet1 [[ ]] : set A retrSet1 [[ [] ]] = ∅ retrSet1 [[ (x:xs) ]] = {(retrieveA x)} ∪ (retrSet1 [[ xs ]]), if ordered (x : xs) where ordered [] = true ordered [x] = true ordered (x : y : xs) = (x < y) ∧ ordered (y : xs)

where retrieveA relates elements of A with elements of ˜ A. Each data type available in Z has a set of pre-defined operations associated with it. As well as formalizing the correspondence between values of A and C, the abstraction function retr :: C → A is also used to specify corresponding operations. For example, consider the operation ∪ (set union) defined in the Z tool-kit. The ($union) :: set a -> set a -> set a function, which implements ∪, is specified by the equation ∀ r, s: set a • retrSet1 (r $union s) = (retrSet1 r) ∪ (retrSet1 s).

Only implementations that satisfy the above equation are considered valid. Besides the pre-defined operations that belong to the Z tool-kit, the designer can define his own functions. Again, an implementation g :: i_1 > \ldots{} -> i_n -> o of a function of type G : AI1 → . . . → AIn → AO must satisfy the equation

Correctness of the Prototype

A major feature of Z specifications is the schema. A schema consists of two parts: a declaration of variables, and a predicate constraining their values. In an “executable” specification, the predicate part of a schema describes the properties that the objects manipulated must satisfy and/or the values to be assigned to the state/operation-outputs. A predicate describing properties of objects is translated into a Boolean function that tests for those properties. A Z expression designating some typed value v is translated into an expression that designates the representing value of v in Miranda. We have said that Z sequences may be represented by Miranda lists, Z finite sets may be represented by sets as we have implemented them in Miranda, etc. But what does it mean for a Z type to be represented by a Miranda type? And what is the relationship between a Z predicate and a Miranda Boolean expression? It seemed desirable that, in the first place, the way how predicates and typed expressions in Z are related to typed expressions in Miranda should be investigated. Thus, before describing the relationship between a prototype and a specification, we will see how both Z typed expressions and Z predicates are formally related with Miranda typed expressions.

retrieve (g a_1 \ldots{} a_n) = G (retrieve a_1) . . . (retrieve a_n)

to be correct. Thus, to relate a Z type T with a Miranda type t we have to: firstly, define a retrieve function mapping objects of t to the objects of T that they represent; secondly, show that the functions that implement the operations on T satisfy their specifications (or alternatively derive these functions from their specifications – for example the derivation of $union from the above specification can be found in [4]). retrTuple, retrRel, retrMap, retrSeq, retrBag, retrFreeT, retrZ, and retrN – the abstraction functions for tuples, binary relations, functions, sequences, bags, free types, integers and naturals, respectively – can be found in [4]. An object a is translated to c, if a vdata c, where a vdata c denotes the fact that c is a data refinement of a. Besides the vdata relation symbol, in the following sections we will also use the symbols vT and vf . We will write A vT a to denote the fact that a is the representing type of A, and G vf g to denote the fact that the abstract function G is implemented by the function g.

Typed expressions: The formalism behind the representation of a Z data type A by a Miranda type C is data refinement in the sense used for example in [5] to formalize the implementation of abstract types. In order to explain which concrete objects correspond to which abstract objects we define an abstraction (or retrieve) function retr with type retr :: C → A that maps the concrete type into the abstract one. If retr c = a, then c is said to represent the value a. An example of an abstraction function is one that describes

Predicates: Any predicates that describe properties of manipulated objects are translated into Boolean expressions that test for those properties. Data refinement is the concept behind the formalization of the prototyping of Z data types. But, since predicates are not typed in the context of Z, this concept is not adequate to justify in a theoretic way the refinement of Z predicates. This leads us into a new theoretic 3

In Z, the process of substituting an abstract state space and corresponding operations for a state space and operations that are described in terms of more computer-oriented data types is called data refinement [30]. Concrete states are related to abstract states by a retrieve schema, and there are three conditions that must be satisfied for a data refinement to be correct:

problem. What is the relationship between non-typed predicates and expressions with type bool? We say that a predicate P is refined by a Boolean expression p if whenever P holds for given objects x1 . . . xn , p instantiated with the concrete representations of x1 . . . xn , reduces to True. Formally, ∀ x1 : Tˆ1 ; . . . ; xn : Tˆn ; X1 : T1 ; . . . ; Xn : Tn • P vpred (p x1 . . . xn ) ⇔ P [ (retrieve x1 )/X1 , . . . , (retrieve xn )/Xn ] ⇒ p x1 . . . xn = True.

• each possible initial state of the concrete type must represent a possible initial state of the abstract type; • a concrete operation must allow termination whenever the abstract operation does so;

Refinement rules: Given the definitions of vdata and vpred , we can derive laws that relate both Z typed expressions and Z predicates with Miranda typed expressions. Sample laws that are based on the definitions of vdata and vpred can be found in [2]. These rules can be proved correct once for all. Whenever they apply, refinement proof obligations can be immediately discharged, as seen in the previous section. A specification defines: some types that model the data in the specification; the form of abstract states; the initial abstract state; operations that manipulate abstract states. A prototype defines: some types that model the data in the prototype; the type of concrete states together with a Boolean function that tests for the validity of concrete states; an initial concrete state; functions that manipulate the concrete state. Let S be a Z specification,

• the state after a concrete operation must represent one of those abstract states in which the abstract operation could terminate. To distinguish this type of refinement from the data type refinement discussed earlier we will refer to it as model refinement. The prototyping of a Z specification by a functional program is also seen as a step of model refinement in the sense that the specification is seen as an abstract model and the prototype as a concrete model. P is a refinement of S if there is a retrieve function retrAstate that relates each concrete state c with an abstract state A in such a way that • if the state invariant holds for A then c is a valid concrete state; • the abstract and concrete initial states are related by retrAstate;

S = k[ hT1 , . . . , Tm i, Astate, IAstate, h (Op1 , preOp1 ), . . . , (Opk , preOpk ) i ]k and P be the corresponding Miranda prototype, P = k[ h t_1,\ldots{},t_m i, (cstate, validstate), icstate, h (op_1, preop_1),\ldots{}, (op_k, preop_k) i ]k

Defn 1: Refinement of specifications into prototypes

where: T1 . . . Tm Astate IAstate Opi . . . Opk preOpi . . . preOpk t_1\ldots{}t_m cstate validstate

icstate op_i\ldots{}op_k preop_i\ldots{}preop_k

• whenever an abstract operation allows termination its corresponding implementation is guaranteed to terminate, and the state after the concrete operation represents one of those abstract states in which the abstract operation could allow termination. Formally,

P is a refinement of S, i.e., S v P if

are user-defined Z types; is the abstract state; is the initial abstract state; are operations on the abstract state; are the preconditions of the above operations;

∃ retrAstate : cstate → astate, retrT1 : t_1 → T1 , . . . , retrTn : t_1 → Tn • Astate vstate (cstate, validstate) IAstate vistate icstate ∧ ∀ i : 1..k • preOpi vpre preop_i ∧ ∀ i : 1..k • Opi vop op_i

are user-defined Miranda types; is the type of concrete states; is a function that tests for the validity of concrete states; is the concrete initial state; are operations on the concrete state; are the preconditions of the above operations.

∧

where astate is the schema type of bindings of Astate, and the relations vstate , vistate , vpre , vop are as defined in the following subsections. Let the abstract state be described by Astate C1 : T1 ; . . . ; Cn : Tn Ainvariant

4

and the state space of the concrete data type be described by

k[

> cstate ::= State (t_1, \ldots{}, t_n) > validstate :: cstate -> bool > validstate (State (a_1,\ldots{},a_n)) = > cinvariant a_1 \ldots{} a_n.

where

2 This rule give a flavor of those needed for transformational refinement to a functional programming prototype. Many more such rules are needed for a practical transformation system; for a selection of further rules, see [2].

“Transformational” Refinement

5

This section presents a “transformational” approach to the derivation of prototypes from specifications. The main motivation for the work related with this section has been the need to reduce the number of formal proofs required in model refinement. The “standard” way of refining a model A would lead us to:

Conclusion

The main contribution of this work to the prototyping problem consists of a framework for the derivation of correct prototypes from Z specifications. Our approach has had as a first concern the establishment of a formal relationship between specifications and prototypes. The rules to derive prototypes from specifications have then been defined based on such a relationship. These rules have been proved correct with respect to the relationship once for all. Any refinement based on them is then implicitly guaranteed to be correct. The formal relationship between specifications and prototypes builds on a formal relationship between Z data types and Miranda data types. Abstract data types refinement revealed to be appropriate to formalize the translation of Z typed expressions into Miranda typed expressions, but it was not adequate to justify in a formal way the translation of predicates into Boolean expressions because the first are not typed. Hence a new refinement concept had to be introduced to deal with predicates. Besides correctness, another aspect of prototyping of potential importance is the maintenance of the structure of the specification. To aid this, the structure of the specification should be reflected in the structure of the prototype. Otherwise it would be difficult to update the prototype each time a new specification error is detected by the user. During the validation process, the specification might have to be changed several times. If the modifications made on the prototype reflect the modifications made in the specification, then it is easier to perform them. By maintaining the structure of the specification, the validation cycle is easier. Finally, tesing is very important in industrial practice [11, 33]. The presence of a specification and a prototype may be beneficial in the testing process. For example, the specification could act as a guide for automated generation of tests for black box testing and the prototype could act as a test oracle. This paper has only been able to give a flavor of the approach suggested using a very simple example by way of illustration. For an early much fuller discussion of the approach, with more complex examples and a much more complete set of rules, see [4]. A more recent expanded version of this paper including a selection of further rules is also available as a technical report [2].

• Define an implementation-model C; • Relate C to A via a retrieve function; • Use such function to show that C is a valid implementation of A. An alternative strategy consists of transforming A into C using a set of rules that implicitly guarantee the correctness of such a derivation. These rules are based upon the definitions given in Section 3. Let S = k[ A1 . . . Aj . . . An ]k be a Z specification, and P = k[ c 1 . . . c j . . . c n ]k be the corresponding functional prototype, where each Ai (with i : 1..n) is a Z paragraph, and each c i (with i : 1..n) is a definition in Miranda. We write k[ Aj ]k vproto k[ c j ]k to denote the fact that Aj is replaced by c j when the specification S is transformed into the prototype P. This subsection gives some example rules that may be applied for verification or derivation purposes. For example, the abstract state in the Z specification is refined into a more concrete state in the prototype containing matching state components with suitable invariants renamed appropriately in the prototype depending on the retrieve function: Rule s.1: k[

> validstate :: cstate -> bool > validstate (State (x_1,\ldots{},x_n)) = > inv x_1 \ldots{} x_n ]k

(∀ i : 1..n • Ti vT t_i) ∧ (∀ a_1\ldots{}a_n • invariant [(retr a_1)/C1 , . . . , (retr a_n)/Cn ] vpred inv a_1 \ldots{} a_n).

Abstract states are bindings of type
C1 : T1 , . . . , Cn : Tn  that satisfy the state invariant Ainvariant. “Valid” concrete states are objects of type cstate that make validstate return True. The state space described by (cstate, validstate) refines the state space described by Astate if the implementation of any abstract state is a valid concrete state.

4

> cstate ::= State (t_1, \ldots{}, t_n)

abstract state

Astate C1 : T1 ; . . . ; Cn : Tn invariant ]k vproto

5

References

[18] W. Grieskamp. A computational model for Z based on concurrent constraint resolution. In J. P. Bowen, S. Dunne, A. Galloway, and S. King, editors, ZB 2000: Formal Specification and Development in Z and B, volume 1878 of Lecture Notes in Computer Science, pages 414–432. SpringerVerlag, 2000. [19] W. Grieskamp and M. Lepper. Using Use Cases in executable Z. In Shaoying Liu et al. [27], pages 111–119. [20] I. J. Hayes and C. B. Jones. Specifications are not (necessarily) executable. In High-Integrity System Specification and Design [12], pages 563–581. [21] M. A. Hewitt, C. M. O’Halloran, and C. T. Sennett. Experiences with PiZA, an animator for Z. In J. P. Bowen, M. G. Hinchey, and D. Till, editors, ZUM’97: The Z Formal Specification Notation, volume 1212 of Lecture Notes in Computer Science, pages 37–51. Springer-Verlag, 1997. [22] M.G. Hinchey and J. P. Bowen, editors. Industrial-Strength Formal Methods in Practice. FACIT series. Springer-Verlag, 1999. [23] C. B. Jones. Systematic Software Development using VDM. Prentice Hall International Series in Computer Science, 1990. [24] C. C. Morgan. Programming from Specifications. Prentice Hall International Series in Computer Science, 2nd edition, 1994. [25] I. Morrey, J. Siddiqi, R. Hibberd, and G. Buckberry. A toolset to support the construction and animation of formal specifications. Journal of Systems and Software, 41(3):147– 160, 1998. [26] U. Nilsson and J. Małuszy´nski. Logic, Programming and Prolog. John Wiley & Sons, 2nd edition, 1995. [27] Shaoying Liu, J. A. McDermid, and M. G. Hinchey, editors. Proc. ICFEM 2000: 3rd IEEE International Conference on Formal Engineering Methods. IEEE Computer Society Press, 2000. [28] L. B. Sherrell and D. L. Carver. Experiences in translating Z designs to Haskell implementations. Software—Practice and Experience, 24(12):1159–1178, 1994. [29] L. B. Sherrell and D. L. Carver. FunZ: An intermediate specification language. The Computer Journal, 38(3):193–206, 1995. [30] J. M. Spivey. The Z Notation: A Reference Manual. Prentice Hall International Series in Computer Science, 2nd edition, 1992. [31] S. Thompson. Haskell: The Craft of Functional Programming. International Computer Science Series. AddisonWesley Publishing Company, 2nd edition, 1999. [32] H. Treharne, J. Draper, and S. Schneider. Test case preparation using a prototype. In D. Bert, editor, B’98: Recent Advances in the Development and Use of the B Method, volume 1393 of Lecture Notes in Computer Science, pages 293–311. Springer-Verlag, 1998. [33] S. A. Vilkomir and J. P. Bowen. Formalization of software testing criteria using the Z notation. In Proc. COMPSAC 01: 25th IEEE Annual International Computer Software and Applications Conference, Chicago, Illinois, USA, pages 351– 356. IEEE Computer Society Press, 8-12 October 2001. [34] M. M. West and B. M. Eaglestone. Software development: Two approaches to animation of Z specifications using Prolog. IEE/BCS Software Engineering Journal, 7(4):264–276, July 1992.

[1] A. E. Abdallah. Filter promotion transformation strategies for deriving efficient programs from Z specification. In Shaoying Liu et al. [27], pages 157–167. [2] A. E. Abdallah, A. Barros, J. B. Barros, and J. P. Bowen. Deriving correct prototypes from formal Z specifications. Technical Report SBU-CISM-00-27, SCISM, South Bank University, London, UK, October 2000. [3] J.-R. Abrial. The B-Book: Assigning Programs to Meanings. Cambridge University Press, 1996. [4] A. Barros. Formal Methods for Rapid Software Prototyping. PhD thesis, Department of Computer Science, The University of Reading, UK, December 1997. [5] R. Bird. Introduction to Functional Programming. Prentice Hall International Series in Computer Science, 2nd edition, 1998. [6] D. Bjørner, C. George, and S. Prehn. Scheduling and rescheduling of trains. In Hinchey and Bowen [22], chapter 8, pages 157–184. [7] J. P. Bowen. The ethics of safety-critical systems. Communications of the ACM, 43(4):91–97, April 2000. [8] J. P. Bowen. Z: A formal specification notation. In M. Frappier and H. Habrias, editors, Software Specification Methods: An Overview Using a Case Study, FACIT series, chapter 1, pages 3–19. Springer-Verlag, 2000. [9] J. P. Bowen, He Jifeng, and Xu Qiwen. An animatable operational semantics of the Verilog Hardware Description Language. In Shaoying Liu et al. [27], pages 199–207. [10] J. P. Bowen and M. G. Hinchey. Formal models and the specification process. In A. B. Tucker, Jr., editor, The Computer Science and Engineering Handbook, chapter 107, pages 2302–2322. CRC Press, 1997. Section X, Software Engineering. [11] J. P. Bowen and M. G. Hinchey. The use of industrialstrength formal methods. In Proc. COMPSAC’97: 21st IEEE Annal International Computer Software and Application Conference, Washington DC, USA, pages 332–337. IEEE Computer Society Press, 13-15 August 1997. [12] J. P. Bowen and M. G. Hinchey. High-Integrity System Specification and Design. FACIT series. Springer-Verlag, 1999. [13] P. T. Breuer and J. P. Bowen. Towards correct executable semantics for Z. In J. P. Bowen and J. A. Hall, editors, Z User Workshop, Cambridge 1994, Workshops in Computing, pages 185–209. Springer-Verlag, 1994. [14] P. Burton. An Introduction to Functional Programming and Miranda. International Thomson Publishing, 2000. [15] A. Diller. Animation using Miranda. In Z: An Introduction to Formal Methods, chapter 19, pages 271–278. John Wiley & Sons, 2nd edition, 1994. [16] N. E. Fuchs. Specifications are (preferably) executable. In High-Integrity System Specification and Design [12], pages 583–607. [17] H. S. Goodman. The Z-into-Haskell tool-kit: An illustrative case study. In J. P. Bowen and M. G. Hinchey, editors, ZUM’95: The Z Formal Specification Notation, volume 967 of Lecture Notes in Computer Science, pages 374–388. Springer-Verlag, 1995.

6