of the 2 nd BCS-FACS Northern Formal Methods Workshop , Ilkley , 14-15 July 1997 Coupling Schemas : Data Refinement and View ( point ) Composition

We define the notion of a coupling schemain Z, and describe the role it plays in data refinement, view composition, and viewpoint unification. In each case coupling schemas relate several state schemas. In data refinement they occur as retrieve relations (abstraction schemas). In specification by views, coupling schemas provide a link between the various views. For viewpoint specification, coupling schemas are closely related to correspondence relations between state schemas in the viewpoints. Simple properties of coupling schemas (e.g. totality, functionality, and consistency) are shown to have important consequences in the techniques listed, and to be very useful for exhibiting the relations between these techniques. It turns out that views and viewpoints can both be seen as variations on, or even as generalisations of, data refinement.


Introduction
More or less independently, three different techniques in Z have been described for developing and verifying specifications by creating operations of one abstract data type from the operations of another abstract data type.The oldest and most widely known of these is data refinement.More recent are view composition [13], and viewpoint unification [4], both of these are used in specification styles which seek to reduce complexity by decomposing along aspects rather than along components.It has long been clear that all these techniques are similar and yet different, but a coherent explanation of their similarities and differences has not been given so far.This paper addresses this issue by explaining all these techniques in terms of (what we call) coupling schemas.Informally, a coupling schema is a schema which relates two state spaces -in section 2 we give an exact definition.In the next section we define a number of properties of coupling schemas, like totality, functionality, and consistency.Then we discuss all three techniques individually.In section 4 it is shown how coupling schemas can be viewed as abstraction schemas (retrieve relations) and as such specify data refinements.In section 5 we show how coupling schemas are used as linking invariants between views.In section 6 it is demonstrated how coupling schemas are generated from correspondence relations in the process of unifying viewpoint specifications.Finally, in the last section we relate the different techniques, showing how they differ and under which conditions they coincide.

Coupling Schemas
We assume the traditional states-with-operations style of specification in Z [15].In this approach, an "abstract data type" is described by a collection of Z schemas.One of these is called the state schema, and all its component names are (by convention) given by standard identifiers, i.e. in particular they do not end in !, ?, or 0 .
Example 1 1F i l e left;right: seq Char is a valid state schema (leftand rightstanding for the text left and right of the cursor in an editor), and so is Grid lines : seq seq Char x;y :N lines 2 wrapped x;y 2 cursors lines For definitions of wrapped and cursors and other details of the editor specification, see the appendix.In brief, Grid requires that lines is a sequence of lines of limited length, with (x ;y) denoting a valid cursor position in it.2 Any other schema of the abstract data type is a so-called operation schema 2 .For simplicity, we make the (usual) assumption that any operation schema includes the following components.Assuming the state schema is called D, there is a declaration D which stands for both D (i.e.all its components -interpreted as the "before"-state of the operation) and D 0 (all D's components primed) which represents the "after"-state.Additionally there may be declarations of variables whose names end in !, denoting outputs of the operation, and variables with names ending in ?, denoting inputs.Finally there must be a predicate defining the relation between all these components (which may be just true).
Example 2 An operation on the F i l e state defined above could be csrRight F i l e right6 =h i left 0 =left a hheadrighti right 0 =tailright with no inputs or outputs, or insertChar F i l e c ? : Char left 0 =left a hc?i right 0 =right which does have an input.

2
Given the style of specification described above, we can define what a coupling schema is.

S D 1 D 2 pred S
such that D 1 and D 2 are state schemas (pred S may be any predicate).In this case we also say that S is a coupling between D 1 and D 2 (or between D 2 and D 1 ). 2 D 1 and D 2 may have component names in common -this is no problem if the types of these components are compatible 4 .One might observe that, since all its components are taken from state schemas, any coupling schema may also play the role of a state schema.This will turn out to be important later.
Example 4 A possible coupling between F i l e and Grid is: Editor F i l e ;Grid left a right= a = lines left=x+ i : 1 : : y , 1 lines i which links the states by requiring that both views represent the same text, and that the cursor positions match: left should be as long as all of the lines before line y together, plus all of line y up to column x: 2 A slightly more liberal notion is that of a proto-coupling defined below, which instead of including the complete state schemas only requires their declaration parts.Proof If the condition holds, T is equivalent to D 1 ; D 2 jpred T and thus a coupling between D 1 and D 2 according to Definition 3. Conversely, the condition is also the weakest guarantee for the predicates pred i to hold. 2 So far we have only defined the notion of a coupling schema, but we have not explained what its purpose is, or why it is a useful notion.Generally speaking, given a coupling schema between two states, and operations defined on one of them, we want to use the coupling schema to generate operations on one of the other two state spaces involved (the other state and the coupling) which are in some sense comparable to the original operations.In the rest of this paper we will describe three variants on this theme.In order to be able to characterise these more clearly, and to describe their relations, we first define some useful properties of coupling schemas.

Properties of Coupling Schemas
The notion of consistency derives from viewpoint unification, but it gives a clear indication why coupling schemas are more useful than proto-coupling schemas.Informally, consistency forbids the proto-coupling to link two states of which exactly one is excluded by its predicate.

Definition 7 (Consistency)
A proto-coupling schema T between D 1 and D 2 , all defined as in Definition 5, is  Proof From Theorem 6 it follows that pred 1 and pred 2 should both hold when pred T does, and both being true they are also equivalent.

2
Definition 10 (Functionality) A proto-coupling S between D 1 and D 2 is p-functional from D 1 to D 2 iff it can be interpreted as a partial function from D 1 to D 2 , i.e.
The schema Editor is p-functional from Grid to F i l e -for every Grid a unique pair of (left;right) can be found.However, it is not p-functional from F i l e to Grid -this represents the fact that in general a F i l e can be formatted as a Grid in many ways.In that case, the abstract data types (D 1 ;Ops 1 ) and (D 2 ;Ops 2 ) are isomorphic if Ops 1 and Ops 2 contain the same set of operation names, and if for each pair of corresponding operations Op 1 and Op 2 it is the case that S ^Op 1 ^S0 , S^Op 2 ^S0 .(However, abstract data types may be isomorphic even when their state schemas are not.) 2 S being a total function in both directions implies that it is a total bijection.

Example 18
x:N and y:Z are isomorphic, as witnessed by the coupling schema x:N ; y:Z y 2 N ^x = 2 y _ y6 2 N ^x = , 2y ,1 2 2nd BCS-FACS Northern Formal Methods Workshop

Data Refinement
Data refinement is a non-symmetric relation between abstract data types.One data type (the "concrete" one) is said to implement another (the "abstract" one) if their initialisations are compatible, and if every "abstract" operation is correctly represented by one "concrete" operation.We refer to [15,17] for the exact details of this -in particular, in this paper we have little interest in operation refinement, and do not consider forward vs. backward simulations.
As above, data refinement is often posed as a verification problem -given the two abstract data types, prove that data refinement holds.Central in this is the so-called abstraction schema or retrieve relation, which links the "concrete" and the "abstract" state.If this is indeed represented as a schema, it is a clear instance of a coupling schema: its signature is the combination of the abstract and concrete state schemas, and it has an additional predicate denoting which concrete value represents which abstract one.
Data refinement is often presented as a generalisation of operation refinement.A folk theorem in the Z world is that the aspect of operation refinement can be factored out.Thus, a data refinement step in the traditional sense consists of a "most general" data refinement (determined only by the retrieve relation -this idea probably derives from [12,14]) possibly followed by an operation refinement step.Woodcock and Davies [17] apply this in their section on "Calculating data refinements"; Ainsworth et al [3] specify a data refinement (indeed the most general one possible) by the retrieve relation only.
Following this folk theorem, we can interpret any coupling schema as specifying uniquely (up to some sensible equivalence) a data refinement from one of its state spaces to the other one.Generally this will only satisfy the conditions of data refinement in one of the two possible directions -an abstraction schema, apparently, is a coupling schema with a direction.
Note that this is only a candidate weakest data refinement: if there exists one, this is it.However, the data refinement condition for the initialisation schema, and non-totality of the coupling schema on the abstract state may prevent the existence of any valid data refinement for this particular coupling schema.The construction above is a straightforward generalisation of the construction used by Woodcock and Davies for calculating data refinements.

Coupling Schemas: Data Refinement and View(point) Composition
As is well known, the conditions for data refinement can be much simplified if the abstraction schema is a total function from the abstract to the concrete state.This shows the relevance of totality and p-functionality for coupling schemas in this case.Indeed, Woodcock and Davies calculate data refinements only when these conditions hold.It should be no surprise that the refinements can be "calculated" when the concrete state is "derived"' (our terminology) from the abstract state, i.e. when the implicit relational compositions in E O pare functional compositions.(Though the occurrence of an inverse function may still cause calculational problems.)

View Composition
The method of specification by views is presented by D. Jackson in [13]: A view is a partial specification of a program, consisting of a state space and a set of operations.A full specification is obtained by composing several views, linking them through their states (by asserting invariants across views) . . .Specification by views is proposed as a method to overcome problems of complexity, to allow separation of concerns, and as such it is comparable to viewpoint specification as discussed in the next section.One of the contributions of the current paper is to pinpoint the difference between these two techniques, see section 7.
The above description of views and how to link them bears a close resemblance to data refinement, and to our description of the general use of coupling schemas.Clearly "a state space and a set of operations" can be viewed to be an abstract data type -making explicit that the operations are indeed assumed to be on that state space.(Note that Jackson lists additional methods of composing views, viz.through their operations, which are closer to promotion-based techniques and which we will not discuss here.)The focus is on a different state space, however: view composition uses the fact that a coupling schema is a state schema itself.

Definition 20 (View composition)
The view composition of abstract data types D and E with state schemas D and E with respect to a coupling schema R between D and E is an abstract data type which includes only the following: R as its state schema For each operation Opin D, an operation ROp b = RjOp For each operation Opin E, an operation ROp b = RjOp If D and E have operation(-name)s in common, the new abstract data type includes the conjunction of the two modified operations for each of those instead of the modified operations.

Example 21
By composing the F i l e and Grid views, using the Editor coupling, the following operations are added to the newly generated abstract data type (whose state schema is Editor): One could almost say that view composition is a symmetrical variant of data refinement.In the final section we will be more specific.
2nd BCS-FACS Northern Formal Methods Workshop

Viewpoint Unification
The central idea in the viewpoint specification approach [10] is that a specification consists of a collection of interlocking partial specifications, each of which describes the envisaged system from a different viewpoint.The main argument in favour of this is that this "horizontal decomposition" gives a more natural separation of concerns.Z is considered suitable for this approach because it naturally allows a great degree of underspecification.For collections of partial specifications to be meaningful, consistency between them has to be established.This is because viewpoints describe aspects of the same system, and thus, in general, overlap.Characterisations of overlaps are called correspondences, using the terminology of the Open Distributed Processing viewpoints framework.Our interpretation of consistency between viewpoints [5] is that common developments (refinements) of the viewpoints must exist.A constructive way of checking this is by producing (least) common refinements, so-called unifications.If the refinement relation involved possesses suitable theoretical properties (which refinement in Z does), consistency checking between a series of viewpoints can be done by repeatedly replacing two viewpoints by their least common refinement until only one consistent specification is left.
Viewpoint specification in Z has been extensively described in papers by Ainsworth, Wallis et al [2,3] and ourselves [7,4].The explanation given here summarizes the discussion in our earlier papers.Consistency checking and unification is performed separately for each data type occurring in the two viewpoints.Thus, the simplified unification problem is between two abstract data types.A behavioural approach might be to relate traces of one data type with the possible traces of the other, but the more obvious approach is to directly relate the state spaces involved.This, in its turn, will have to consider all components of the state schemas.If both contain a declaration, say, count:N, and these represent conceptually the same counter, then the unified state will probably have to contain this component as well.However, if one contains valueseq: seq 1 N and the other valueset: P N , it is not clear what the unified state should include.Maybe both represent a set of values in the state -but only the second one allows this set to be empty, how should we deal with that?Clearly more information is needed than just the two state schemas only -we need a correspondence, which will tell us exactly which value in one state space is "conceptually the same as" which value in the other state.Here the link to the general idea in this paper emerges: 5Definition 22 (Correspondence relation) A correspondence relation between state schemas D and E is a protocoupling between D and E. 2 We will restrict the discussion in the rest of this section to state schemas which have only one component.This does not restrict expressiveness of the approach, since the type of the single component can be a product or a schema type -it only serves to reduce the amount of distracting detail.For the same reason we will only discuss cases where the different components have different names.These proto-couplings only differ in how they treat the empty set/sequence.N E m p links the empty set, a valid inhabitant of E, to the empty sequence, which is not included in D. In E m pthese two are not connected.Observe (trivially from Theorem 6) that E m pis actually a coupling schema, but N E m p is not. 2 Our interpretation of a value from one viewpoint state not being linked by the correspondence relation to any value from the other viewpoint state is that it is an allowed value which, however, is not modelled in the other viewpoint.This allows us to model all kinds of unions, for example adding values to free types, cf.[4].Moreover, this issue bears a direct relation to the unification being a refinement of the viewpoints.The only way to ensure that any possible operation of the viewpoint can be refined by a unified operation is called state consistency in [4], see that paper for further details.
Theorem 24 Two viewpoints (abstract data types) are state consistent [4] iff the correspondence relation between their state schemas is consistent. 2 Thus far we have established that we need consistency, and also that using a coupling schema rather than a protocoupling schema would guarantee consistency.So, do we really need the extra generality offered by proto-couplings if it only brings trouble?The answer to that is "Yes".We need to be made aware that of two values which are linked by the correspondence, one is excluded through an additional invariant of the other viewpoint!It is much better for troublesome assumptions to show up as state inconsistencies rather than as (possibly undesirable) restrictions on operations.
For example (returning to Example 23), if D and E are indeed intended to describe the same set of values, giving N E m p as the correspondence relation allows us to discover that the viewpoints have inconsistent assumptions as to whether this set may be empty or not -this will be exhibited by N E m p being state inconsistent.On the other hand, if we use E m pthe empty set will be considered as an intermediate state in which only operations from E's viewpoint may be applicable -not an inconsistency for D, only additional refinement of the state space.Now for the next difference with view composition.Like with view composition, in viewpoint unification we are going to create an abstract data type whose state schema is derived from the (proto-)coupling involved.However, our goal is now not to have syntactic simplicity like in view composition (and the Z schema calculus in general).For viewpoint unification we want refinement between the new abstract data type and each of the viewpoint abstract data types.Moreover, we want the refinement to be the most general one possible which respects the correspondence relation, implementing as many elements from the original state spaces as possible.This means that (for a consistent correspondence) three kinds of values will occur in the unified state space: pairs of values from the correspondence; values from one viewpoint which are not related by the correspondence; and similar for the other viewpoint.Formally, this amounts to a totalisation6 of the proto-coupling, which can be modelled using the optional construct [8].This gives for any type the type of sets from that type with at most one element, which implements that a value may be either undefined (empty set), or a defined value from that type (singleton set).optional X == fxs: P X j xs 1g Finally this allows a definition of viewpoint unification.The coupling totalisation of the proto-coupling will be the state schema of the generated abstract data type.definition below) of the two modified operations for each of those instead of those modified operations.

2
Definition 29 (Operation unification) (Also called amalgamation [3] or demonic join [11].)The operation unification of two operations Op1 and Op2 on the same state schema is given by The usefulness of this is given by the following: Theorem 30 (Operation consistency and refinement) If two operations Op1 and Op2 have a most general common operation refinement, it is their operation unification.Their operation unification is a refinement of both operations iff they are operation consistent, viz.

2
Theorem 31 The viewpoint unification of two abstract data types is their least common data refinement whenever they have a common refinement (e.g. when the proto-coupling is consistent and all matching modified operations are operation consistent).

2
It is important to observe that not in all cases as much formal machinery is necessary in order to construct a unified state space.Most importantly, if the proto-coupling R is a total coupling on any one of the states involved, the corresponding component in R will always be defined, and thus does not need to be of the optional type.To put it differently, a schema, isomorphic to R, will exist which does not have that component optional.
Example 32 Using the Editor schema as a (proto-)coupling between F i l e and Grid, and a straightforward extension of the above definitions for multiple component schemas (where the components from one viewpoint state are either all defined, or all undefined), the viewpoint unification of these has as its state schema x;y :optional N de nedleft , de nedright de nedx , de nedy , de nedlines de nedx _de nedleft de nedlines thelines 2 wrapped de nedlines thex ;they 2 cursors thelines de nedleft^de nedlines the left a theright= a =thelines de nedleft^de nedlines theleft=thex + i : 1 : : they ,1 thelines i unde nedlines : 9 Grid Editor theF ile=File unde nedleft : 9 F i l e Editor theGrid=Grid (using the abbreviated substitution the Grid=Grid for "the" applied to each component).However, because Editor is total on Grid, this is isomorphic to EditorTot F i l e lines:optional seq seq Char x;y :optional N de nedx , de nedy , de nedlines de nedlines thelines 2 wrapped ^thex ;they 2 cursors thelines de nedlines left a right= a =thelines de nedlines left=thex + i : 1 : : they ,1 thelines i unde nedlines : 9 Grid Editor theF ile=File Its operations might include an adaptation of csrRight which due to totality of Editor on Grid could be written as csrRightE b = EditorTot jcsrRight and an adaptation of csrUp (cf. the appendix) which could be simplified to: csrUpE EditorTot unde nedy ^unde nedy 0 _ they 1 ^they 0 = they ,1 ^thex 0 = min thex ; thelines they 0 ^thelines 0 = thelines which is essentially csrUp decorated with lots of occurrences of "the", plus an additional disjunct which represents the fact that a F i l e which cannot be formatted as a Grid has no sensible interpretation of moving the cursor up. 2

Comparisons and Conclusions
Figure 1 illustrates the differences between the constructions in the three techniques.In all three, new operations are generated from old ones according to a (proto-)coupling.In the last two techniques a new state is constructed as well -in view composition this state is the coupling schema, in viewpoint unification it is constructed from the coupling 2nd BCS-FACS Northern Formal Methods Workshop schema.In the rest of this section we will show the semantic relationships between these techniques: when do their results coincide, and which specifications are refinements of each other?In each case we will assume a coupling schema R b = D; E jpred R between state schemas D and E as in the figure.

Data Refinement and View Composition
Clearly in data refinement (according to Definition 19) the resulting abstract data type is a data refinement, provided the initialisation condition is met and the state space is not unduly restricted.If this is not the case, there is no data refinement with the given coupling schema, as discussed before.
Data refinement from D to E can only coincide with view composition if the operations generated in both cases are on the same state space.Thus, D needs to be subsumed by E in R, making E (or R) the resulting state space in both cases.The fact that there is a restriction like that implies that neither technique is a special case of the other.When Theorem 33 Data refinement from D to E according to R coincides with view composition between D and E when E subsumes D in R. 2 This may create the impression that view composition always results in refinements.However, this is not the case in general (for more exceptions see the next subsection).

Theorem 34
The data type resulting from view composition is, in general, not a data refinement of its operand data types.
Proof (By counterexample:) the datatype consisting of F i l e and insertChar is not data refined by the datatype consisting of Editor and insertCharE.The cause of this is related to Editor not being total on F i l e (cf.Example 13): the situation where a character is added to a word which was of maximum line length is included in (the precondition of) insertChar but not in insertCharE (since in that case there is no Editor 0 which satisfies the predicate).
Additionally, if the data types involved have an operation in common, this might also prohibit the view composition being a refinement.It is a well-known fact that the operation S^T is not in general an operation refinement of S or of T. 2

View Composition and Viewpoint Unification
The remarks at the end of the previous section already indicated that one crucial issue in this comparison is totality.In fact, we have Theorem 35 With respect to a proto-coupling which is a total coupling on both state schemas involved, the state schemas resulting from view composition and viewpoint unification are isomorphic.The trivial coupling schema which witnesses the isomorphy is TotalIso R;

R x =thexx y =theyy
This tells us in which case the generated state schemas are (as good as) equal.Additional conditions are necessary for the operations on the generated state to be equally close.It is clear that the ways in which operations are modified to the new state are comparable, with what is added to operations in Definition 28 closely resembling TotalIso above and TotalIso 0 .
Theorem 36 If, in addition to the conditions of Theorem 35, the sets of operation names in both abstract data types are disjoint, the abstract data types resulting from view composition and viewpoint unification are isomorphic.

2
If the abstract data types have operations in common, for view composition and viewpoint unification to coincide, conjunction and demonic join have to coincide.For a different motivation (viz.finding cases where demonic join can be expressed in the schema calculus), this is investigated in [3].Conjunction and demonic join turn out to coincide for operations whose preconditions are equivalent.Thus we can generalise the previous theorem to:

Theorem 37
If, in addition to the conditions of Theorem 35, for each operation common to both abstract data types, both its versions for the new abstract data type have equivalent preconditions (either in view composition or in viewpoint unification), the abstract data types resulting from view composition and viewpoint unification are isomorphic.
2 Furthermore, we can observe that the demonic join of two operations is an operation refinement of their conjunction, and totalisation is a total injection.The consequence of this is interesting but not very useful:

Theorem 38
The viewpoint unification of two abstract data types according to a particular coupling is a data refinement of their view composition according to that coupling.

Refinement and viewpoint unification
Theorem 31 already presented an important relation between refinement and unification: unification is the least common refinement provided one exists.Also, results from the previous subsections can be combined to deduce relationships between refinement and unification from their respective relationships to viewpoint composition.The most important relation between refinement and unification is actually a result of the general theory of development and unification as we have described it in [5]  7 : unification generalises refinement.
Given two abstract data types A and B such that A is a data refinement of B with respect to coupling schema S, the viewpoint unification of A and B with respect to S is not identical to A, and their state schemas are not isomorphic in general.(The unification state schema will include all components from the state of B in addition to those of A.) However, the unification of A and B is isomorphic to A in that situation, using the normal definition of isomorphism as mutual data refinement (which generalises the special case mentioned in Definition 17): Theorem 39 (Unification generalises refinement) If abstract data type A is a refinement of abstract data type B with respect to coupling schema S, the abstract data type C resulting from viewpoint unification of A and B with respect to S is isomorphic to A. Proof We need to prove that A and C are data refinements of each other.Clearly A and B have a common refinement (viz.A), thus according to Theorem 31 C exists and is the least common refinement of A and B. Thus, C is a refinement of A. Moreover, because A is also a common refinement of A and B, it is also a refinement of C since C is the least of these common refinements.
2 7 Or rather an instance of the general lattice property that a b a ub =a.
2nd BCS-FACS Northern Formal Methods Workshop

Conclusions
Three techniques for developing and verifying Z abstract data types have been explained in terms of the notion of a coupling schema.Coupling schemas turned out to provide a powerful framework in which to understand these techniques.The best illustration of that is probably the sheer simplicity of Figure 1, which makes the structural differences between the techniques clear.Complementary to that, the semantical properties and differences between the techniques have been reduced to properties of the coupling schemas involved.
Besides for these three techniques, coupling schemas could also be used to describe (bi-)simulation relations, used in behavourial interpretations of Z (for example [6]).
We have presented all these techniques for the specific language Z, but clearly the individual techniques, and thus probably also the general idea, are applicable to a much wider range of specification languages (for example B [1] or the binary relations as used by Frappier et al [11]).The presentations would be quite different, however, since much of the current paper revolves around Z schemas being interpreted and used in varying ways.

Definition 5 ( 2 Theorem 6
Proto-coupling) Any schema of the form -coupling schema for schemas D 1 b = Decls 1 jpred 1 and D 2 b = Decls 2 jpred 2 For proto-coupling T, D 1 and D 2 as in Definition 5, T is a coupling between D 1 and D 2 iff pred T pred 1 ^pred 2

pred 2 2 Example 8
Let D b = x:N and E b = y:Zj y 0 , then S b = x:N; y:Zj x=y is an inconsistent proto-coupling between D and E: Informally, D's legal value 0 is linked to E's illegal 0.

2 Theorem 9
Every coupling schema is consistent.

Example 23
Given state schemas D b = valueseq: seq N jvalueseq6 =h i and E b = valueset: P N , two possible proto-couplings between D and E are N

Definition 28 (
Viewpoint unification) The viewpoint unification of abstract data type D with state schema D b = x:S j pred D and abstract data type E with state schema E b = y:T j pred E according to a proto-coupling R b = x:S ; y:T jpred R is the abstract data type which includes only the following: as its state schema R, the coupling totalisation of the proto-coupling; for each operation Op b = D; Decls jpred in D, an operation Op R Decls de nedxx ^de nedxx 0 let x =thexx ; x 0 = thexx 0 pred similarly, for each operation Op b = E; Decls jpred in E, an operation 2nd BCS-FACS Northern Formal Methods Workshop Op R Decls de nedyy^de nedyy 0 let y =theyy; y 0 =theyy 0 pred If D and E have operation(-name)s in common, the new abstract data type includes the operation unification (cf.
:optional seq Char lines:optional seq seq Char

Figure 1 :
Figure 1: The various techniques depicted graphically.The line at the top in each denotes a coupling R between D and E. A stack of circles denotes an abstract data type (state above operations).The parts generated by the technique are indicated by double circles, with dotted arrows showing what they are generated from.
E subsumes D (and additionally, E's datatype has no operations defined on it initially) the result of view composition and most general data refinement do indeed coincide.Assume that DOp b = D; Decls j op .Then the result of data refinement for this operation is given by E; Decls j9D nE ; D 0 n E 0 pred R ^op^pred R 0 2nd BCS-FACS Northern Formal Methods Workshop Coupling Schemas: Data Refinement and View(point) Composition f E subsumes D, so D nE is empty g E; Decls jpred R ^op^pred R 0 f from subsumption it follows that E^pred R , R g R; Decls jop f schema calculus g R jDop which is indeed what would have resulted in view composition.In summary: Let the total coupling be given by R b = D; E jpred R and w.l.o.g.D b = x:S jpred D , E b = y:T jpred E .

2 Definition 12 (Totality) A
proto-coupling S between D 1 and D 2 is total on D 1 iff Editor is total on Grid, and it takes a little reasoning to show that it is not total on F i l e .Lines can only be formatted by breaking them between words, and the lines in a Grid are of a limited length.Thus, if a F i l e contains a word that is longer than the maximum line length, there is no corresponding Grid.2Theorem 15 For a proto-coupling S between D 1 and D 2 , D 1 is derived from D 2 by S iff S is total on D 2 and p-functional from D 2 to D 1 .iff S , E j pred S .When no coupling schema is mentioned, D is subsumed by E implies it is subsumed for all possible coupling schemas (i.e. in D; E jtrue ).

Definition 19 (Data refinement from coupling)
Given an abstract data type D with state schema D and a coupling schema R defined by the (weakest candidate) data refinement from D determined by R is the abstract data type E whose state schema is E, and which contains for each operation in D given by DOp D Decls op an operation in E given by :T jpred R , its coupling totalisation R with respect to D and E is given by yThe first predicate totalises the relation characterised by pred R ; the other predicates effectively turn the proto-coupling into a coupling by restriction to the state predicates.