IO-reﬁnement in Z

We present a generalisation of data reﬁnement in Z, called IO-reﬁnement , that allows changes in input and output parameters of operations. Several informal motivations for the desirability of such a reﬁnement relation are given, followed by a formal derivation that demonstrates its theoretical soundness. It is proved that IO-reﬁnement indeed generalizes data reﬁnement. Several theorems are presented that give sufﬁcient conditions for IO-reﬁnement to hold in simpler situations, e.g. just adding inputs and outputs. Some examples of the use of IO-reﬁnement are also given.


Introduction
Data refinement is a well-established technique for transforming formal specifications in an abstract data type style into ones which are perceived to be closer to an eventual implementation.In particular, for the formal specification notation Z [16,18] rules for data refinement have been given.These rules also allow for the operations of an abstract data type to have input and output parameters.However, they allow only very limited changes to these parameters in refinement.(In fact, most representations of these rules suggest no change is possible at all.See for an example of what is allowed Section 3.1 of this paper.) Our particular interest in Z refinement is for its use as a semantics for partial specification in Z, as we will explain in more detail in Section 2.1.In brief, a collection of ("partial") specifications is satisfied by any (full) specification which is a development of each of them.Traditional data refinement in Z comes very close to having all desirable properties for such a development relation.One problem, however, is that it forces us to specify all possible inputs and outputs of every operation in each partial specification.This does not seem very convenient, and thus we have looked for a generalisation of Z data refinement which allows a little more freedom in this respect.Such a generalisation (called IO-refinement) is discussed in this paper, and we expect its relevance goes beyond providing semantics to partial specification in Z.
The next section extensively discusses possible motivations for allowing change of IO-parameters, by giving various answers to the question "Why IO-refinement?".The last of these is that it is possible to generalise the derivation of Z refinement given in the most authoritative account of Z refinement [18].Section 3 contains this generalised derivation.In subsequent sections, a definition of IO-refinement is given, based on this derivation.We show that it generalises ordinary Z refinement.The conditions for IO-refinement turn out to be very general, and as a consequence of that, fairly hard to use.For this reason, we also present rules for using IO-refinement in a restricted way which are much easier to use.Also, some examples of its use are presented.
Before we move on to answering "Why IO-refinement?", let us recall the conditions for data refinement as given in [16], and present the traditional Z example, so some of the answers can refer to that.

Infamous Example
Every area in formal methods has its canonical examples.For Z, it is not the factorial function, nor the alternating bit protocol.Any new technique for Z should preferably be illustrated with Spivey's ÖØ Ý ÓÓ example [16], which is In a section of the book called "Strengthening the specification" Spivey describes how an indication of success or failure can be added to this: Formally, however, none of the operations described so far is a refinement of ÖØ Ý 2 , so in what sense is it strengthened?Maybe a notion of refinement exists which formalises the "strengthening" that Spivey had in mind there.

Why IO-refinement?
We could think of (at least) six possible reasons for wanting or allowing refinement of input and output parameters in Z operations.One aspect of the question can be rephrased as: why would we call ÖØ Ý ËÙ ×× (which only adds a constant output) a refinement of ÖØ Ý?However, some of the answers indicate the possibility or desirability of IO-refinements much more radical than that -for example, to match notions of conformance of object interfaces.
A reader who is already convinced of the usefulness of IO-refinement may safely skip the rest of this section.

Surely it's only a convention?
We have a particular interest in alternative definitions of refinement for Z, because we wish to use Z for partial specification (or viewpoint specification), as explained in [4,3].In our framework [7], the meaning of a partial specification is the set of all its possible developments according to a particular development relation -and the obvious development relation for Z is (data) refinement.Composition of two partial specifications, in that approach, is finding their most general common refinement.In [4] we have shown how to generate a least common refinement of two Z specifications with this purpose in mind.This type of partial specification, however, only allows viewpoints which satisfy the following restrictions: 1.Each operation in every partial specification can be invoked by the environment, i.e. none of them are internal.
(Refinement allows weakening of preconditions, which is undesirable for internal operations.At ZUM'97 [6], there were at least four papers which touched upon this issue.) 2. All partial specifications are at the same level of granularity, e.g.no single operation in one partial specification corresponds to a larger collection of operations in another.

3.
All partial specifications of one operation have exactly the same inputs and outputs.
2 However, Ê ÖØ Ý is a refinement of ÖØ Ý ËÙ ×× and of ÐÖ ÝÃÒÓÛÒ.In fact, due to the preconditions of these operations being disjoint, it is their least common refinement.
3rd Northern Formal Methods Workshop, 1998 The first of these restrictions is removed by a slight generalisation of Z refinement, called weak refinement [9].The second one suggests a move towards action refinement.This paper aims at relaxing the third restriction, which appears to be orthogonal to the other two.We wish to allow viewpoints which need only describe part of the required functionality of an operation -it seems logical to apply this principle to inputs and outputs as well, particularly in the object-based contexts in which we wish to use viewpoint specification (cf.[7]).For example, in a system which logs all user requests, the specification of a particular request in the "user" viewpoint should not have to have a ÐÓ output -these should only occur in the specification of that same request in the "logger" viewpoint. 3 comparable argument can be found in [11], which demonstrates the usefulness of separating user interface and functionality in Z.Our work can be viewed as a natural extension of theirs, in that it studies how refinement combines with this separation.
Clearly one way out for us would be to leave Z refinement for what it is, and define a "new" refinement relation for Z from scratch.It might solve our problem, but we think it would be much more profitable to stay as close as possible to generally accepted approaches.Fortunately, as will be made clear later, this poses no serious problems.

The Informal Answer
Adding a constant output shouldn't hurt, should it?
From the perspective of "information content", there is no difference at all between observing that a particular operation occurs, and observing that it occurs with a particular output which is known always to have the same value.This seems similar to giving an operation a different name -which is allowed in Z data refinement.Also, one might wonder whether the name of an output should have relevance in Z refinement -in most languages outputs do not have names, only types.Another branch of our research is concerned with relating specifications in Z with specifications in other formal notations.For some of these, e.g.LOTOS [8] we have indeed needed to adopt the convention that names of outputs (and inputs) are irrelevant in Z.
The argument here will be continued in a more formal way in other answers."There is no difference at all" would suggest more than just refinement -it suggests equivalence, for example in the sense of refinement in both directions.Note that here we talk about "observing" an operation happening -this is fully in accordance with the model used in [18] to derive Z refinement, which we will also be using later to derive a more general refinement relation.

The Perspective of Operation Interfaces
If no one is looking at Ö ×ÙÐØ , there is no difference.
The standard Z view of refinement (simulation) between abstract data types is that the environment observes the occurrence of operations, and for each of those, all its inputs and outputs with their names and types.As a consequence of this, the types of input and output parameters may not be changed 4 , though the refinement conditions do allow their declarations to change 5 .
Looking at these restrictions from the perspectives of operation interfaces and object-oriented style typing, this all seems more restrictive than necessary.We would, like in interface definition languages, an operation's interface, viewed as a type, to be satisfied by operations whose interfaces are subtypes of that type: taking inputs and outputs from extended sets; adding inputs and outputs (by generalising imagined constant inputs and outputs to variable ones).The type system of Z (being essentially flat) is not well suited for defining subtyping directly.We will instead (implicitly)

IO-refinement in Z
define subtyping as the existence of functions with particular properties that relate the types.The conditions that emerge for inputs and outputs are different, as one might have expected from issues of covariance and contravariance in function subtyping.
In the research area of object-oriented languages, the need for interface refinement has indeed been acknowledged.The most striking example of this is the work of Mikhajlova and Sekerinski [14] on class refinement and interface refinement, which independently of our work comes up with very similar rules and conditions for alteration of inputs and outputs in refinement.

A Schema Calculus Answer
Schema conjunction generally precludes refinement -but through applicability, not through correctness.
It is well known in the Z community that the interplay between refinement and the schema calculus is not always smooth.The conjunction of two operations, for example, may not be a refinement of either even when a common refinement of the two exists [4].Conversely, the disjunction of two operations is only the least common refinement of both if their signatures are identical and they are identical where their preconditions overlap (e.g. when the preconditions are exclusive [2], like for ÐÖ ÝÃÒÓÛÒ and ÖØ Ý ËÙ ×× above).A more positive result is the following.

Theorem 1
The operation Ç Ô ´ ÇÔ Pµ is an operation refinement of ÇÔ if 1. Ç Ô has the same signature as ÇÔ, i.e.P does not refer to variables not in ÇÔ; 2. pre Ç Ô pre ÇÔ, i.e.P does not have the effect of excluding before-values that ÇÔ allowed.
Proof The correctness condition is automatically guaranteed by the second condition.The second condition above is only a formal strengthening of the applicability condition, since pre´ ÇÔ Pµ µ pre ÇÔ follows from the first condition.

¾
Of the two conditions of the above theorem, surely the second one should be considered the major one.Now look at ÖØ Ý and ÖØ Ý ËÙ ×× . . .Their preconditions are equal, so they only fail to be in the refinement relation because of the first, minor syntactical, condition.Clearly from this perspective removing that condition, and thus putting these operations in a refinement relation, would not be very revolutionary.
This line of reasoning, however, will not be pursued much further in the rest of this paper, because even if we manage to overcome the problem described above, it still seems impossible to completely remove all problems between schema calculus and refinement.

A Mathematical Answer A¢1 1 A
Contrary to what was suggested by the previous answer, in moving from ÖØ Ý to ÖØ Ý ËÙ ××, "conjunction" is really irrelevant, being only a consequence of Z's syntactical conventions.Consider the following tautologies on sets (in mathematics, not in Z): Now combine these set comprehensions in a particular syntactic way, by concatenating their declarations and taking the conjunction of their predicates:

IO-refinement in Z
Now would we call the resulting set A B ?Of course not -what is being constructed is a product set.The same goes for ÖØ Ý ËÙ ×× -maybe we should say that it is unfortunate that product schemas in Z appear as conjunctions 6 , because products as a concept are too important to be lumped in with conjunctions.
Once we have established that ÖØ Ý ËÙ ×× denotes a product schema, let us consider its factors.ËÙ ×× is peculiar, in that it has only one possible inhabitant.Viewed as a set of bindings, it is a singleton set.One notion of equivalence in a theory of products is that of isomorphism, and the product of a set A with a singleton set is isomorphic to A. (This formalises the argument given in the "informal" answer.)There is another pair of isomorphic types involved in these schemas.Consider the type of all outputs of ÖØ Ý -there are none.One way of modelling a value from an empty product type is by defining it to be the anonymous unique value * of the predefined type 1 1.The output signature of ËÙ ×× is ËÙ ×× itself, and the product of these two output signatures is isomorphic (if not equal!) to ËÙ ××, and isomorphic to 1 1.
Isomorphisms between state schemas in Z induce data refinements in both directions.Isn't it strange that isomorphisms between input-or output types do not?
As a response to this question we expect to hear "inputs and outputs are observed, whereas states are not".This is an acceptable answer within certain limits, as will be explained in Section 3.1.However, taking a different view on this introduces no inconsistencies or new anomalies.
"Isomorphism" again suggests IO-refinement in both directions.It is clear that less stringent conditions will suffice for having IO-refinement in one direction only.Such conditions will emerge from the derivation given in the next section.
Finally, we would like to point out the similarity between this issue and the generalisation or embedding strategy in program transformation [15] (or indeed in proofs in general): input types can be extended by generalising constants to variables; output types can be generalised as long as the originally required output can be reconstructed from it.

A Methodical Answer
We can derive it, so it must be okay.[18] motivate the Z data refinement conditions by deriving them from a characterisation of simulations between abstract data types, modelled as binary relations.Using exactly the same set up, by generalising identity functions to more general functions in their derivation, we managed to obtain conditions for a generalised type of refinement, which we call IO-refinement.This involves only a very marginal relaxation in the "rules of the game", very similar to the implications of having initialisations observable.

Woodcock and Davies
Of course, a formal derivation, however reassuring, on its own means nothing.However, the generalisation we choose is the obvious one given Woodcock and Davies' derivation (replacing explicit occurrences of identity functions by more general functions), and the resulting refinement relation encompasses all the relaxations suggested by the answers above, and possibly quite a few more.
Stepney, Cooper and Woodcock in recent work [17] have also observed that more powerful rules than the standard rules for Z can be derived from the binary relation characterisation.

A Derivation of the Conditions for IO-refinement
In this section we will derive conditions for IO-refinement in a derivation that generalises the derivation of refinement from simulation in [18, pages 254-255].In order to appreciate the subtleties of IO-refinement, we first need to discuss the issue of unwinding -transforming a system where all input occurs at initialisation and all output occurs at finalisation into one where every operation can have input or output.

Unwinding: the Relation between Initialisations and Input
The canonical theory of simulations on which the notion of refinement in Z is based [12,13] is one of binary relations.A "run" of the system consists of three parts: an initialisation, a sequence of operations, and a finalisation.If the state space of the environment is G and the state space of the system is S, then initialisation is a relation between G and S; every operation is a relation on S; and the finalisation is a relation between S and G.As in [18], let us concentrate on a system which has only one operation -multiple operations, each with their own input/output types, would make everything that follows unnecessarily complicated.This simplification has the additional consequence that, apart from the initialisation condition for data refinement (which is unaffected by our modified derivation), IO-refinement is a condition on a single pair of operations.We will sometimes say that an operation IO-refines another one when strictly speaking we are talking about the systems, each consisting of one operation and the implied state, refining each other.
The first part of the derivation in [18] ("relaxing") results in conditions for data refinement of a system as described above, i.e. one with no individual inputs or outputs for every operation.These conditions are the relational versions of the correctness and applicability conditions given in Section 1.1.For a relation Ó to refine a relation Ó given abstraction relation r: A particular class of such systems is interpreted as modelling a system with inputs and outputs for every operation, namely ones where the following is the case.The state contains two sequences, an input sequence and an output sequence.Initially, the output sequence is empty; in the final state, the input sequence is empty.Every time an (the) operation is executed, the first value is removed from the input sequence, and a value is added to the end of the output sequence.The outcome of the operation does not (directly) depend on any other value in the input or output sequence.

Example 4
The system (call it A) (it has no outputs, to simplify the presentation) is modelled by the system (let us call it A £ ) where all inputs are provided at initialisation time, which is The description at the level of binary relations of this construction uses a number of auxiliary functions defined below, which will also be used in our modified derivation.×ÔÐ Ø removes one input from the input sequence; is a kind of parallel composition; Ñ Ö adds an output to the output sequence.
3rd Northern Formal Methods Workshop, 1998 Using these operations, the relation between an operation ÓÔ in a system with IO and its counterpart ÓÔ s in a system without IO is where the identity relation ensures that the rest of the input and output sequence are unaffected in the current operation.
The second part of the derivation then translates the refinement conditions between Ó s and Ó s (substituting these for Ó and Ó in ( 2) and ( 3)) into conditions between Ó and Ó, using as a retrieve relation on the extended state where Á Ò Ô and ÇÙØÔ are the types of the input and output of ÓÔ.The conditions that result, when translated to conditions on Z schemas, are those given in Section 1.1.Note, however, that there is a small problem with representing a system with input in the way described above.(This is not observed in [18], but solved by the more general rules in [17].)It is best illustrated by means of an example.

Example 6
Continuing from Example 4, assume that A, the set from which the input parameter y is taken is properly contained in another set B. Clearly the first system can be refined by replacing the declaration of y in ÇÔby y B, and let us call this system B. Now B £ is equal to A £ , except for the declaration of ÒÔ×, which is now of type seq B. However, B £ fails to be a forward simulation refinement of A £ !Consider the condition which in this particular case (abstraction relation is injection of abstract state space into the concrete one) translates to x ¼ S ÒÔ× ¼ seq B ¯x¼ a µ ÒÔ× ¼ ¾ seq A which is false for A being a proper subset of B ¾ Conclusion: after "unwinding", refinements are allowed that were not allowed before.The relevance of this problem is as follows.When using input-refinement, the initialisation condition for "all input at initialisation" translates to: for every concrete input, there is an abstract input which is linked to it by the inputtransformer.This implies that new inputs may freely be added, but that no input may have its type extended.This is clearly undesirable given our motivations, but the issue needs to be resolved for "standard" Z refinement as well.
Of course the problem is in viewing the initialisations as independent.For the "input as initialisation" notion, it is important to realise that the inputs are provided by the environment.In the original relational refinement set-up, initialisation and finalisation are functions from-and to the environment, respectively.In other words, a fair model of A £ would have as its initialisation: such that, with appropriately modified refinement rules for initialisations with inputs, A £ would still be refined by B £ .This construction solves the paradox inherent in [18] -in the following derivation we assume that a similar construction can also be given to discharge the undesirable condition for IO-refinement deriving from the initialisation condition.[17] presents a solution which is essentially similar, by always keeping a reference to the global environment G in the refinement rules.

The Derivation
In this section we paraphrase the second part of the derivation in [18], allowing for an easy comparison between the two.The crucial step lies in generalising the identity functions in (5) to arbitrary maps.We will use the following relational generalisation of "map": The starting point of our derivation is the assumption that we have refinement rules for a particular relation between concrete and abstract states for a set of operations that have no inputs or outputs.If we want to derive similar conditions for operations that do have inputs and outputs, we need to apply the standard method: the state contains extra components representing the sequence of inputs still to be dealt with and the sequence of outputs already computed.
Assume we wish to compare operations Ó and Ó which consume input and produce output.Their equivalent operations that expect input and output sequences are given by Ó s ×ÔÐ Ø Ó ´ Ó µ Ó Ñ Ö and similarly for Ó s .Given a relation r between states without input and output sequences, we must construct an equivalent relation that acts on the enhanced form of the state.If r is a relation of type

ËØ Ø ° ËØ Ø
then we require a relation r s of type ËØ Ø ¢ ´seq ÁÒÔ ¢ seq ÇÙØÔµ ° ËØ Ø ¢ ´seq Á Ò Ô¢ seq ÇÙØÔµ in order to compare Ó s and Ó s .For the comparison to make sense, the two operations should have lists of outputs and inputs that are equally long.Moreover, the relation between input and output sequences should be between elements in comparable positions only.Not to assume that would imply the system cheated in some way -by making use of "future" input or "past" output, for example.If the relation between individual input elements is Ø and that between individual output elements is ÓØ, the relation r s between enhanced states is then defined by: r s ´r Ø £ ÓØ £ µ For r s not to exclude combinations of states in r, we need to require that Ø and ÓØ are total on the abstract input and output types.(This condition is formally a little too strict -it rules out input and output transformers which reduce the input and output types to the values that can actually occur.However, this can still be done as operation refinement, using just predicates.) The rules for the correctness of a forwards simulation require that ´dom Ó s µ ´rs Ó Ó s µ Ó s Ó r s which requirement is equivalent to ´dom Óµ ´´r Øµ Ó Óµ Ó Ó ´r ÓØµ The other requirement, that Ó s is defined everywhere that Ó s is defined, leads to a second constraint7 : ran´´dom Óµ ´r Øµµ dom Ó

IO-refinement in Z
The first derivation in [18] also contains an initialisation condition that needs to hold between the initialisations of the two systems involved, which is claimed to be independent from the "unwinding" construction and thus does not change for the second derivation.This is not strictly true, as demonstrated above.Similarly, this condition would have its effect on our modified version of unwinding.The resulting condition would be that for every concrete input, an abstract input exists.(Compare with the situation in Example 6.) In addition, a finalisation condition exists for a simulation to hold between two systems with no inputs or outputs.This condition becomes moot in Woodcock and Davies' unwinding, but in our modified approach it has an important consequence: ´ÓØ Ó ÓØ µ ÇÙØÔ which is to say, ÓØ needs to be injective.This condition guarantees that different abstract ("original") outputs can be distinguished in the concrete cases because their concrete representations will be different as well.
The next section will define the analogues of the retrieve relation for changing inputs and outputs in refinement steps, called IO-transformers, and some other notations useful for expressing the IO-refinement rules at the Z schema level.

IO-transformers
For convenience, we first define the notion of a signature.Definition 7 (Signatures) For a schema S, its signature ¦S and its input and output signatures S and S are given by ¦ S S S S ¦ ´ "all components of S whose names don't end in !"¯Sµ S ¦ ´ "all components of S whose names don't end in ?"¯Sµ ¾ By definition of schema negation, a signature schema has all components declared as being from their type (rather than a subset of it) and an everywhere true predicate (which we usually forget about).If S has no inputs, S turns out to be true , the schema whose only inhabitant is the empty binding (similarly for S if S has no outputs.)This schema plays the role of the unit type 1 1 mentioned in Section 2.5.
The following operations on names, which extend componentwise to signatures (similarly to the standard convention for decorations) are defined.Definition 8 (Decorations for input and output) For all x, x x ; x x .

¾
(The overline operator is chosen in analogy with CCS -in piping communication when they are both present in the right direction, x and x become hidden.) We will need to change inputs and outputs of operation schemas without (directly) affecting their changes on the state.For that purpose we will use schemas which contain inputs and outputs only, which will be connected to the operations using piping .Hayes and Sanders [11] use piping in much the same way: to represent the equivalent of relational composition for inputs and outputs in Z schemas.They use the term "representation schema" for what we call "transformers".
An input transformer for a schema is an operation whose outputs exactly match the schema's inputs, and whose signature is made up of input-and output components only; similarly for output transformers.

¾
An IO-transformer will normally have a predicate relating its inputs and outputs.For every schema, input-and output transformers can be defined that act as identities with piping: . A generator used as the first argument of a piping fixes an input value, e.g.Ò ÇÔis (no renaming needed): It is most obvious to have generators as input transformers, and terminator as output transformers.However, the reverse is possible as well for operations that have no inputs or no outputs.
Example 13 Continuing the birthday book example from Section 1.

È Ö
such that the following conditions hold: and schemas Á Ì and ÇÌ exist such that transformers Á Ì is a total input transformer for ÇÔ; ÇÌ is a total and injective output transformer for ÇÔ.
applicability Ç Ô is defined on all representatives of A and Ç Ô on which ÇÔ is defined (modulo retrieve relation and inverse input transformation): correctness wherever ÇÔ is defined, Ç Ôwith the input transformation should produce a result related by R and the output transformation to one that ÇÔ could have produced: This definition easily extends to multiple operations.
A very important point about IO-refinement is that, when we have done a refinement step using transformers IT and OT, we can not forget about them (unlike the abstraction schema).We will need to administrate all IO-transformers used, so they can be "plugged in" in the final result of our refinement derivation in order to get inputs and outputs as they were originally specified.
Observe that we have chosen for both IO-transformers to have abstract inputs and concrete outputs, so that they are typically used in opposite directions.Strangely enough, the correctness condition looks like the corresponding condition for normal data refinement between (Á Ì Ç Ô ) and ( ÇÔ ÇÌ), whereas the applicability condition looks like the corresponding condition between Ç Ô and Á Ì ÇÔ.

Example 15
For the birthday book example, in order for Ê ÖØ Ý to be an IO-refinement of ÖØ Ý, we need (instantiations or, as observed above, "correctness" of operation refinement between the following two operations:

¾
An obvious observation is that IO-refinement is a proper generalisation of data refinement (of course it already follows from the derivation being a generalisation).
Proof For Á Ìsubstitute Iid Ç Ô , for ÇÌ substitute Oid ÇÔ, this reduces the first condition to the traditional one.For the second condition, observe that Iid Ç Ô Iid ÇÔ and that Iid S Iid S for any S, then it also reduces to the traditional condition.

¾
The next thing to be proved is that, compared to data refinement, it has equally nice properties.The previous theorem ensures one of these already: Corollary 17 IO-refinement is reflexive.

¾
The following theorem does not follow directly.

Proof
The proof is completely analogous to a proof that data refinement is transitive.The witnessing abstraction relation for the two-step refinement is a composition of the two abstraction relations (conjunction of both, hiding components of the intermediate state), the input and output transformers for the two-step refinement are constructed by piping the transformers of the individual steps together.
Proofs like these are best done in the set up of binary relations as in Section 3, rather than in the schema formulation.

¾
Now if the conditions for data refinement were already complicated, the ones for IO-refinement add an extra level of complication to them.Even if the relevant input and output transformers are fixed, the formulas are quantified over two more variables than the data refinement ones.The complexity of the rules for data refinement has been observed before, and a solution has been proposed which separates out the "most general data refinement", which is completely determined by the abstract type and the abstraction relation.The operation refinement implicit in the data refinement 3rd Northern Formal Methods Workshop, 1998

IO-refinement in Z
rules is then carried out in a separate step.This strategy is originally described in [13], and more explicitly for Z in [5, section 4]; the chapter on calculating data refinements in [18] describes a special case of it.
We will make IO-refinement more tractable by proposing a similar strategy: first do an IO-refinement step in which no data refinement occurs (often resulting in ¸holding where the conditions require µ), and then do any data refinement.Unlike with the solution for most general data refinement described above, we will make no claims about completeness of this strategy.In other words, not all IO-refinements allowed by the general rules can actually be described as a restricted IO-refinement followed by data refinement.Further investigation may provide a complete rule that is nevertheless easy to use.The essence of our suggestion for restricted IO-refinement lies in the following theorems, which give sufficient conditions for IO-refinement.
First, the result of applying bijective IO-transformers to an operation will always be a refinement, i.e. inputs and outputs can be replaced by "isomorphic" values:

Theorem 19 (Isomorphic IO)
If Á Ìis a total injective functional input transformer for ÇÔ and ÇÌ is a total injective output transformer for ÇÔ, then Á Ì ÇÔ ÇÌ IO-refines ÇÔ. ¾ Also, we can add inputs and outputs to an operation which previously did not have any.

¾
Moreover, inputs and outputs can also be added to an operation which did have some already.
Proof Note that Ò and Ì Ö Ñ are not necessarily input and output transformer for Ç Ô , so the IO-refinement rule cannot directly be used.This can be fixed by taking the equivalent ´ Ò Iid ÇÔµ Ç Ô ´Ì Ö Ñ Oid ÇÔµ.
Then for Á Ì ´ Ò Iid ÇÔµ and ÇÌ Ì Ö Ñ Oid ÇÔ the conditions of IO-refinement are satisfied, analogous to the proof of Theorem 20.

¾
A pictorial representation of this theorem illustrates how by IO-refinement we can change the boundaries of a system while we are developing it: In the above diagram, Ç Ô IO-refines ÇÔ, using a fixed generator Ò and a terminator Ì Ö Ñ .

IO-refinement in Z
Theorems 19 and 21 can also be viewed in the context of [11]: they give a kind of soundness conditions for separating out the user interface from the functionality of an operation.
In summary, using IO-refinement we can ¯add inputs; ¯add outputs; ¯change inputs and outputs by applying injective functions to them; and of course all possible combinations of the above, resulting in a quite powerful refinement calculus.

Coffee machine
A very simple and, in our view, convincing example of the usefulness of IO-refinement is that of coffee machines which have more buttons and outputs than "strictly needed".Now ÜÄ Õ Ë Ó Ö Øis the obvious unparameterised sorting on sequences of natural numbers.By Theorem 20, Ë Ó Ö Ø is thus an IO-refinement of that.
Continuing this example, clearly not all binary relations are sensible as inputs to the sorting operation.We will add some error handling to this, using a new type for output reports called Ñ× :

Ñ× ÛÖÓÒ Ó
The error case, and a more robust version of the sorting operation are now described by:

3rdDefinition 9 (
Northern Formal Methods Workshop, 1998 IO-refinement in Z Input and output transformer) Schema S is an input transformer for schema T iff ¦ S ´ S Sµ S T and it is an output transformer for T iff ¦ S ´ S Sµ S T

Definition 10 (
Input and output identity) For a schema S its input identity is defined by Iid S S S all x in S ¯x x and its output identity by Oid S S S all x in S ¯x x where all x in S ¯P x denotes universal quantification over all component names in S, i.e.P x P y P z if the components of S are x, y and z. ¾ Clearly Iid S S S and S Oid S S. Another special kind of IO-transformers are terminators and generators, IO-transformers that only consume input or only produce output.Definition 11 (Terminator and generator) For IO-transformer S: Now we have defined the equivalent of schema composition for input and output parameters, we can rephrase the conditions of IO-refinement as conditions on Z schemas.Given abstract data types A ´A ÇÔ ÁÒ Øµ andC ´C Ç Ô ÁÒ Øµ, then C is an IO-refinement of A if there exists an abstraction schema Proof Considering the conditions of IO-refinement as in Definition 14, abstract state A, concrete state C and abstraction relation are all identical.Taking Ç Ô Á Ì ÇÔ ÇÌ, observe that for injective functional Á Ì , Á Ì Á Ì Iid ÇÔ, and for total ÇÌ, pre´Á Ì ÇÔ ÇÌµ pre´Á Ì ÇÔµ.
Consider the (stateless) machine for black coffee These two are indeed related by IO-refinement: define Term and Gen by and thus by Theorem 21, Ó is an IO-refinement of Ð .datatype of sequences of natural numbers could be defined by a type Ë Õwith initialisation ÁÒ ØË Õ and sample operation :Now a very general sorting operation, which takes a binary relation as a parameter, is defined by: j dom s ¼ ¯i j µ ´s¼ i s ¼ j µ ¾ Ð Õ How does the normal sorting operation on sequences of natural numbers relate to this operation, in terms of IOrefinement?This can be answered using a generator: A i x y AE ¯´x yµ ¾ Ð Õ ¸x y ÊËÓÖØ may appear to be an IO-refinement of Ë Ó Ö Ø .However, it is not, because ÊËÓÖØ is not a data refinement of Ë Ó Ö Ø ËÙ ××.(The preconditions of Ë Ó Ö Øand ÒØËÓÖØ overlap.)Nevertheless, ÊËÓÖØ is an IO-refinement of 3rd Northern Formal MethodsWorkshop, 1998