Exploring UML Development through Unification

Exploring UML Development through Uni cation Eerke Boiten and Marius Bujorianu Computing Laboratory, University of Kent, Canterbury, CT2 7NF, UK. (Email: [email protected].) One way of making UML more suitable for the development of critical systems is to de ne a notion of development (or re nement) for it. This paper explores development in an indirect way: through uni cation. Dierent UML diagrams may contain information on the same system element, which may or may not be contradictory. Such diagrams may be part of the same UML model, or they may be taken from dierent models representing \viewpoints". A representation of the combined information in dierent diagrams is a uni cation. Implicit in this de nition is a notion of \information content" which may be formalised in a number of dierent ways. A uni cation is not only a representation of combined information, it also bears witness to consistency between the original models. The theory of consistency and uni cations for viewpoint speci cation is well-developed for formal methods. In general, such uni cation methods are parameterised by a notion of re nement (i.e., how to compare information content), and a notion of correspondence (relating the information between speci cations). In particular, in Z all of these can be expressed syntactically, and a variety of re nement relations have been developed inspired by dierent styles of viewpoint speci cation. This paper considers a number of small simple case studies in UML, their intuitive \unifying" diagrams, and how these would relate to the uni cations of formalisations of the original diagrams. In this way, desirable properties for a development notion in UML emerge.

Abstract.

1 Motivation: Formalists' Pamphlet Our starting point is given by a number of reasonable questions that one might ask about a UML speci cation, but which are not currently answerable. These questions are listed here, with theorems describing how they are interrelated.

Conformance If we have made the eort of writing a UML model, either before or after writing the program, can we actually check that the speci cation and the program match? In other words, given a UML model S , and a program P , does P conform to S ? Let us write this as Conf (P ; S )

Consistency The various diagrams in UML describe systems from dierent

angles, but they are not entirely orthogonal. So we may ask whether, even if each diagram by itself is consistent, their combination imposes constraints that cannot be satis ed. Let us denote the consistency of UML descriptions S1 ; : : :; Sn as Consist (S1 ; : : :; Sn )

Theorem 1 (Consistency for free (1)). Given conformance, consistency

can be de ned by

Consist (S1 ; S2 ) =def

9 P  Conf (P ; S1 ) ^ Conf (P ; S2 )

Development Imagine we have written a rst UML speci cation, and obtained

agreement from all parties involved that it correctly re ects all their requirements. Unfortunately, it does not quite describe the system's workings in detail { we would like to change the UML description to re ect such extra detail. Can we determine whether the resulting description bears any relation to the original requirements without renewed consultation? I.e., is our second speci cation S2 a correct development of S1 , denoted Dev (S2 ; S1 )

Theorem 2 (Development for free (1)). Given conformance, development can be de ned by Dev (S2 ; S1 ) =def

8 P  Conf (P ; S2 ) ) Conf (P ; S1 )

Theorem 3 (Consistency for free (2)). Given development, consistency

can be de ned by

Consist (S1 ; S2 ) =def

9 S3  Dev (S3 ; S1 ) ^ Dev (S3 ; S2 )

Semantics Maybe this question is slightly less reasonable than the earlier ones. Nevertheless . . . we might ask what the acceptable models of a UML description S are. Let us denote the set of all of these as Models (S )

Theorem 4 (Development for free (2)). Given a model-based semantics, development can be de ned by

Dev (S2 ; S1 ) =def Models (S2 )  Models (S1 ) We might avoid trivialisation by additionally insisting that Models (S2 ) 6= ?

Theorem 5 (Consistency for free (3)). Given a model-based semantics,

consistency can be de ned by

Consist (S1 ; S2 ) =def Models (S1 ) \ Models (S2 ) 6= ?

Obviously, semantics is \for free" when we have conformance (all conformant programs as models) or development (models are all developments). The theory represented here, brie y hinted at in [7], is inspired by our earlier work on viewpoint consistency [3, 5]. In that work, a useful notion is that of a uni cation .

Uni cation Given two speci cations, one might create a single speci cation

that contains (exactly) the information contained in both. These we call (least) uni cations , let us denote the uni cation of S1 and S2 as S1  S2

Least uni cations can be characterised in terms of each of the preceding notions: Conf (P ; S1  S2 ) , Conf (P ; S1 ) ^ Conf (P ; S2 ) Consist (S1 ; S2 ) , Consist (S1  S2 ) Dev (S3 ; S1  S2 ) , Dev (S3 ; S1 ) ^ Dev (S3 ; S2 ) Models (S1  S2 ) = Models (S1 ) \ Models (S2 )

The second equation holds for any uni cation; the rst and third become implications for uni cations which are not \least". The last equality needs to be weakened to an inclusion if the image of Models is not closed under intersection. All this clearly demonstrates that the various notions are very closely related. A proposed semantics or re nement relation for UML might be described directly { we will be taking a fresh, indirect, approach by observing uni cations. In the next section we will argue why consistency and uni cation are, by themselves, relevant issues for UML, and discuss some of the approaches taken in the literature.

2 Consistency and Viewpoints for UML The UML combines multiple notations into a single modelling language. This gives modellers the opportunity to apply appropriate notations for dierent aspects of the system; however, the various UML notations are not orthogonal or disjoint in scope. As a consequence, UML has a consistency issue: dierent diagrams may put contradictory constraints on some element of the described system. This is in addition to structural consistency requirements (or better: well-formedness conditions) of UML models, e.g., forbidding circular inheritance, which may be represented as OCL constraints in the UML meta-model [13].

For architectural descriptions in UML in particular, a viewpoints [15] method has been proposed [11]. In such a context, consistency is an even more prevalent issue [14]. However, the problem of determining consistency between two UML \viewpoint" models is not fundamentally dierent from that of determining consistency within a single UML model. In either case, the source of any inconsistency will be a collection of diagrams (or OCL constraints, etc.) which, between them, put unsatis able restrictions on some element of the system. In a \viewpoints" situation, the possibility increases that these are diagrams of the same type, e.g., state charts describing the same class. Most approaches to consistency checking for UML rely on a formalisation of all UML diagrams in a single semantic framework, which may be CSP [6, 12], algebraic speci cation [2], CSP-OZ [21], etc. UML consistency is then reduced to consistency of the underlying framework. Such approaches to consistency checking are non-constructive: they provide no feedback in terms of UML indicating whether consistency held or not. A more constructive approach is the Promela based approach of Lilius [18], where model checking is used to generate a counter-example of consistency in the form of a sequence diagram. In a fully constructive approach to consistency, for example the one for Z [4], the underlying semantic model remains hidden. Inconsistencies are thus reported in terms of the speci cations themselves. Moreover, also the result of a successful consistency check is represented as a speci cation, which is called the uni cation . Uni cations can also be used as the basis for incremental consistency checking of n > 2 speci cations. See [3, 5] for a full discussion of consistency checking based on uni cations. In this paper, we explore some possibilities for constructive consistency checking in UML. The completeness of a method for this would, obviously, require a complete formal semantics for UML, which is not our concern at this point. Instead, we consider intuitive (maybe even naive!) formalisations of UML fragments whose meaning seems non-controversial, and explore whether these formalisations can substantiate, again, intuitive \uni cations" in UML. These uni cations are in the same spirit as rules for \joining" in Catalysis [10]. Unsurprisingly, we will use Z for the formalisation of UML, as the constructive method for Z may lead to uni cations that may have direct counterparts in UML. In the next section we present two small UML models, and consider an intuitive uni cation of them. Then, in Section 4 we translate the example into Z, apply the Z uni cation techniques to the translation, and evaluate the result. Section 5 presents some conclusions.

3 Example: Flight Booking System In this example, we consider two views of a ight booking system. In both cases, the UML model consists of a class diagram and a state diagram. In the rst viewpoint, reservations can be made, but not cancelled. Moreover,

the ight itself is not subject to cancellation. The class structure of this model comprises three classes:

{ BookingS describes the basic operations of a booking system: openFlight for

opening a new ight, close for closing a ight and reserve for reserving a seat on a ight; { Flight contains a basic attribute of a ight: the number of free seats seats noFreeSeats; { Seat represents for a seat, whether it is reserved or free.

BookingS

Flight

0..*

0..*

+freeSeats : int

Seat +reserved : Bool

+openFlight() : Flight +close(fl:Flight) +reserve(fl:Flight)

Fig. 1.

First viewpoint: class diagram

Associations are de ned between the classes: multiple instances of class Seat are associated with an instance of Flight, and multiple ights are associated with the BookingS class. reserve() [ freeSeats>1]

NoReservation

reserve()

Reservation-Open

openFlight() close()

Closed

reserve() [ freeSeats=1]

FullyBooked close()

Fig. 2.

First viewpoint: state chart

The state diagram contains four states, apart from the initial and nal ones: NoReservation (corresponding to the system state immediately after the ight was opened), ReservationOpen (the state where the ight has seats booked and the booking process is still ongoing), FullyBooked (the state where all seats are

booked) and Closed (the seats booking process has stopped { for example two hours before take o). Observe that a ight can be closed even if not all seats are reserved (the transition from ReservedOpen to Closed). In the second viewpoint, ights and reservations may be cancelled. BookingS

Flight

0..*

0..*

+freeSeats : int +openFlight() : Flight

Seat +reserved : Bool

+reservedSeats : int

+close(fl:Flight) +reserve(fl:Flight) +cancel(fl:Flight) +cancelFlight(fl:Flight)

Fig. 3.

Second viewpoint: class diagram

The class diagram has a very similar structure to that of the rst viewpoint. Two more methods have been added to the Book Sys class (corresponding to BookingS): cancel for cancelling a seat reservation and cancelFlight for cancelling a ight. Also, rather than recording just the number of free seats, we also record the number of reserved seats. The state diagram, compared to the previous one, reserve [freeSeats>0]

openFlight() NoReservation

reserve()

Reservation-Open

cancel() [reservedSeats>1]

cancel() [reservedSeats=1] close()

cancelFlight() Cancelled

Closed

Fig. 4.

Second viewpoint: state chart

has an extra state for cancelled ight, but does not identify fully booked ights. It also adds transitions corresponding to cancellations of seats or entire ights. An intuitive uni cation of the two viewpoints consists of the second class diagram (which contains more information than the rst), and a state diagram which represents all the states and transitions available in the previous ones.

reserve [freeSeats>1]

openFlight() reserve()

NoReservation

Reservation-Open

cancel() [reservedSeats>1]

cancel() [reservedSeats=1] cancelFlight() Cancelled

cancel()

reserve [freeSeats=1]

close()

Closed

FullyBooked

close()

Fig. 5.

Uni ed state chart

4 Uni cation from Z Here, we formalise the UML diagrams in Z, and derive a uni cation of these formalisations. In the rst instance, we will concentrate on the behaviour of an individual ight.

4.1 First viewpoint The class diagram of the rst viewpoint tells us it has an attribute freeSeats : int ; according to the state diagram, it can also be in a number of states. We abbreviate their names in the Z speci cation. States1 ::= NoRes j ResOpen j Full j Closed

As there are no transitions leading into the initial state, nor labelled transitions into the nal state, we can omit those for now. The transition leading out of the initial state corresponds to the initialisation. Flight1 s1 : States1 freeSeats : Z Init1


Flight1 s10 = NoRes

When doing such formalisations \by hand", it is very tempting to introduce extra information which is not present in the UML though evident from our \understanding" of the real-life situation represented. However, we do not include any constraint on freeSeats in Init as none is implied in the diagrams. 0

Operations correspond to the disjunctions of all transitions in the state diagram which have the same label. Reserve1


Flight1

(s1 = NoRes ^ s1 = ResOpen )_ (s1 = ResOpen ^ freeSeats > 1 ^ s1 = ResOpen )_ (s1 = ResOpen ^ freeSeats = 1 ^ s1 = Full ) 0

0 0

Again, it is tempting to include a predicate like freeSeats = freeSeats 1, or to assume freeSeats > 0 for the initial state, but it is not actually implied. 0

0

Close1


Flight1

s1 = ResOpen _ s1 = Full s10 = Closed

In our class diagrams, all attributes were indicated to be public. This was done, however, because the decision on visibility should be postponed until a later stage. In order to fully represent the attributes being public, we would need to include Z operations representing accessors and mutators on all attributes as well.

4.2 Second viewpoint There are four states in the second state chart, with the initial and nal states omitted for the same reason as above. States2 ::= NoRsv j RsvOpen j Clsd j Cancld

Note that we use dierent abbreviations for the state names, in order to distinguish between the two viewpoints. Flight2 s2 : States2 free ; reserved : Z Init2


Flight2 s20 = NoRsv

The operations are once again disjunctions of transitions with the same label.

Reserve2


Flight2

(s2 = NoRsv ^ s2 = RsvOpen ) _ (s2 = RsvOpen ^ free > 0 ^ s2 = RsvOpen ) 0

0

Cancel


Flight2 s2 = RsvOpen reserved > 1 ) s20 = RsvOpen reserved = 1 ) s20 = NoRsv CancelFlight


Flight2

s2 = NoRsv ^ s20 = Cancld Close2


Flight2

s2 = RsvOpen ^ s20 = Clsd

4.3 Uni cation For the states-and-operations style in Z, the process of uni cation is described in detail in [4]. Lacking space to repeat all details, we illustrate this process by example. This sample uni cation approximates a development relation for UML in the following way. Uni cation in Z is de ned in terms of re nement : it is the \least" (-prescriptive) common re nement of two speci cations. A hierarchy of re nement relations in Z exist, see [8], leading to slight dierences in the rules for uni cation. Viewing this in reverse: we should select the parameters for Z uni cation of the UML formalisations in such a way that we end up with a Z formalisation of the combined state diagram above. In this way, we establish desirable properties of UML re nement, which we will highlight as they appear. This we consider to be the main contribution of the paper.

State uni cation As it will turn out later, the crucial step in the uni cation

is the identi cation of its state space. If the state spaces of the two views are identical, this step can be avoided. However, the schemas Flight1 and Flight2 are dierent. In terms of the required re nement relation, this implies that we need data re nement , rather than the simpler operation or algorithmic re nement.

Requirement 1: UML re nement needs to include data re nement, to allow for hidden state with abstraction from internal details. In order to continue uni cation, we need to establish the relationship between the variables in the two state schemas. This will be documented in a combined schema, which we call a correspondence . We de ne this in a number of steps, starting with the non-controversial relations between the states. Corr0 Flight1 Flight2 free = freeSeats s1 = NoRes , s2 = NoRsv s1 = Closed , s2 = Clsd

Next, we are faced with the problem that the second viewpoint has a variable reserved that does not occur in the rst viewpoint. We might reasonably assume that free +reserved remains constant in the second view; let us name this constant capacity . As reservation is possible from the initial state, its value should be at least 1. capacity : N 1

The next issue is with the state RsvOpen , from which Reserve2 may or may not succeed, depending on the value of free ; this does not quite match the state ResOpen from which Reserve1 is always de ned. This is addressed by stating that the state RsvOpen is represented by either ResOpen (when there are free seats) or Full (when there are none). This completes the correspondence relation1 : Corr Corr0 free + reserved = capacity s1 = Full , s2 = RsvOpen ^ free  0 s1 = ResOpen , s2 = RsvOpen ^ free

>0

Note that we could have chosen many other correspondences, but the current one represents our intuition about the speci cations, including the supposition that they are actually consistent. Unlike in the mechanical process of formalising the UML diagrams, it is necessary to insert knowledge about the intention of the speci cations at this stage.

Totalisation A correspondence relation like Corr might serve as the state space

for the uni cation already. However, in this case it will not be suÆcient: there 1

Inclusion of a Z schema's name in a new schema implies inclusion of all its declarations and predicates.

is no mention of the state Cancld . Corr represents a kind of dependent product of the two state spaces, in relational data base terms: a \theta-join". What is required for the combined state space (in order to guarantee re nement) is an \outer join" which contains representations of every member of both viewpoint state spaces; one might also view this as a totalisation of the correspondence relation. In this case, the outer join would link Cancld to a \null" value for Flight1 ; because the variables free and reserved play no r^ole in Cancld , we present a simpler equivalent schema where only States2 is extended with a null value. States1 ::= NoRes j ResOpen j Full j Closed j Null

The full state schema for the uni cation is then (using the latest de nition of States1 ): TCorr Corr s1 = Null

, s2 = Cancld

Adaptation Once we have de ned a common state schema, all viewpoint operations can be \adapted" to operate on this common state. Technically, this is a data re nement step, determining the least re nement [9] for the retrieve relation which injects the viewpoint state space into the common one. Syntactically, it involves little more than a change of the state name. The rst viewpoint's operations become AdReserve1


TCorr

(s1 = NoRes ^ s1 = ResOpen )_ (s1 = ResOpen ^ freeSeats > 1 ^ s1 = ResOpen )_ (s1 = ResOpen ^ freeSeats = 1 ^ s1 = Full ) 0

0 0

AdClose1


TCorr

s1 = ResOpen _ s1 = Full s10 = Closed

where additional requirements are hidden in
TCorr { in particular, variables from Flight2 are constrained to preserve the correspondence. The operations of the second viewpoint are adapted analogously.

Operation uni cation Any data re nement can be factored into a \least" data re nement and an operation re nement { operation adaptation handled

the former, so we can restrict ourselves to operation uni cation now. This is a well-known technique, rst described for Z by Ainsworth et al [1]. In Catalysis, it is used for \joining" pre/post-speci cations, but [10] does not draw the link with re nement. Two operations Op1 and Op2 de ned in terms of
S are consistent, and can thus be successfully uni ed whenever pre Op1 ^ pre Op2 ) pre(Op1 ^ Op2 ) i.e., whenever they are both applicable, a result consistent with both exists. In that case, their uni cation is Op1  Op2


S

pre Op1 _ pre Op2 pre Op1 ) Op1 pre Op2 ) Op2 This de nition holds when we assume that a precondition represents a \contract": within the given area, the operation should deliver the right result, and outside this area, we do not care. This is the common assumption for Z; however, for behavioural interpretations we may also view the precondition as a \guard": outside the precondition the operation should be disabled. In this interpretation, we additionally require that pre Op1 = pre Op2 for consistency, which means that the uni cation reduces to Op1 ^ Op2 . For a detailed discussion of \guards" vs. \contracts", see [8]. The preconditions of the two adapted Reserve operations coincide: either there are no reservations yet, or reservation is open and there are still free seats. The latter condition is encoded in the state in the rst view, and in the variable free in the second view. Their outcomes are also consistent, and lead to AdReserve1  AdReserve2


TCorr

(s1 = NoRes ^ s1 = ResOpen )_ (s1 = ResOpen ^ freeSeats > 1 ^ s1 = ResOpen )_ (s1 = ResOpen ^ freeSeats = 1 ^ s1 = Full ) 0

0 0

where all the eects of AdReserve2 are already implied by the combination of AdReserve1 and TCorr 0 . AdClose1 and AdClose2 are also equivalent to each other, and thus also to their uni cation. The rst viewpoint has no further operations; the second has also Cancel and CancelFlight . Formally, we can treat this by the operations being de ned with a precondition of false in the rst viewpoint; the uni cations would then be Cancel and CancelFlight . The fact that we would unify two operations with dierent

preconditions shows that we do need to take the \contract" interpretation of preconditions.

Requirement 2: UML re nement should allow widening of precondi-

tions.

As we could not actually distinguish in a state diagram between an operation that is never applicable (appearing as 0 arrows labelled with its name), and one that does not exist, we also have:

Requirement 3: UML re nement should allow introduction of extra

operations.

For a solid grounding of this requirement in an OO context, see the \constraint rule" of Liskov and Wing [19]. Finally, observe that the uni ed Z speci cation is indeed equivalent to the intuitive formalisation of the state diagarm we presented earlier. There are ve states, corresponding to the four states of the rst view plus the Cancld state of the second view. The RsvOpen state of the second view is split into two states, depending on whether free > 0. The only information that the formal uni cation adds, compared to the state diagram, is that freeSeats = 0 in state FullyBooked. This information has ltered through operation conditions and correspondences into a state invariant; however, it corresponds to the intuition about the speci cation.

5 Concluding Comments This small case study has substantiated a number of intuitions about the nature of re nement in UML. In its nature, it should be similar to re nement for Z (and B, and VDM, etcetera). However, in accordance with the Catalysis approach, we believe that a more complicated case study would have introduced additional requirements, leading to a more liberal notion of re nement. First, the operations we formalised had no inputs or outputs. UML practice appears to allow for inputs and outputs to be elided when they are not relevant { as a consequence, we would need to allow interface re nement [20], which is a sound generalisation of normal re nement, see [8, Chapter 10]. Second, decomposition of (inter)actions plays an important r^ole in UML. This could be addressed by having uni cation based on a notion of action re nement , which is an independent and compatible generalisation as well [8]. Clearly, issues of consistency, uni cation, and re nement could have been addressed on the basis of a dierent formalisation as well. In particular, a CSP formalisation [6, 12] seems an obvious candidate. However, de ning the correct re nement relation on the CSP side is non-obvious, for example because most CSP re nement relations do not allow widening of guards, or because uni cations may be expressible semantically but not syntactically [22].

References 1. M. Ainsworth, A. H. Cruickshank, P. J. L. Wallis, and L. J. Groves. Viewpoint speci cation and Z. Information and Software Technology, 36(1):43{51, February 1994. 2. E. Astesiano and G. Reggio. An attempt at analysing the consistency problems in the UML from a classical algebraic viewpoint. In Recent Trends in Algebraic Development Techniques, Selected Papers of the 15th International Workshop WADT'02, Lecture Notes in Computer Science. Springer, 2003. To appear. 3. E.A. Boiten and J. Derrick. Integration of speci cations through development relations. In H. Ehrig, B.J. Kramer, and A. Ertas, editors, IDPT 2002. SDPS, 2002. Extended version to appear in Journal of Design and Process Science, September 2003. 4. E.A. Boiten, J. Derrick, H. Bowman, and M. Steen. Constructive consistency checking for partial speci cation in Z. Science of Computer Programming, 35(1):29{75, September 1999. 5. H. Bowman, M.W.A. Steen, E.A. Boiten, and J. Derrick. A formal framework for viewpoint consistency. Formal Methods in Systems Design, 21:111{166, 2002. 6. J. Davies and C. Crichton. Concurrency and re nement in the Uni ed Modelling Language. Formal Aspects of Computing, 2003. Special issue on REFINE'02, to appear. 7. J. Derrick, D. Akehurst, and E.A. Boiten. A framework for UML consistency. In Kuzniarz et al. [17], pages 30{45. 8. J. Derrick and E.A. Boiten. Re nement in Z and Object-Z: Foundations and Advanced Applications. FACIT. Springer Verlag, May 2001. 9. John Derrick and Eerke Boiten. Calculating upward and downward simulations of state-based speci cations. Information and Software Technology, 41:917{923, July 1999. 10. D.F. D'Souza and A.C. Wills. Objects, Components and Frameworks with UML: The Catalysis Approach. Addison-Wesley, 1998. 11. A. Egyed and N. Medvidovici. Extending architectural representation in UML with view integration. In France and Rumpe [16], pages 2{16. 12. G. Engels, J.M. Kuster, L. Groenewegen, and R. Heckel. A methodology for specifying and analyzing consistency of object-oriented behavioural models. In V. Gruhn, editor, Proceedings of the 8th European Software Engineering Conference (ESEC) and 9th ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE-9), pages 186{195. ACM Press, 2001. 13. A.S. Evans and S. Kent. Meta-modelling semantics of UML: the pUML approach. In France and Rumpe [16], pages 140{155. 14. A.C.W. Finkelstein, D. Gabbay, A. Hunter, J. Kramer, and B. Nuseibeh. Inconsistency handling in multiperspective speci cations. IEEE Transactions on Software Engineering, 20(8):569{578, August 1994. 15. A.C.W. Finkelstein, J. Kramer, B. Nuseibeh, L. Finkelstein, and M. Goedicke. Viewpoints: a framework for integrating multiple perspectives in system development. International Journal on Software Engineering and Knowledge Engineering, Special issue on Trends and Research Directions in Software Engineering Environments, 2(1):31{58, March 1992. 16. R. France and B. Rumpe, editors. UML'99, volume 1723 of Lecture Notes in Computer Science. Springer, 1999.

17. L. Kuzniarz, G. Reggio, J.L. Sourrouille, and Z. Huzar, editors. UML'02 Workshop on Consistency Problems in UML-based Software Development, Research Report 2002:06. Blekinge Institute of Technology, 2002. 18. J. Lilius and I.P. Paltor. vUML: a tool for verifying UML models. In R.J. Hall and E. Tyugu, editors, Proceedings of ASE'99, pages 255{258. IEEE Computer Society, 1999. 19. B. Liskov and J. M. Wing. A behavioural notion of subtyping. ACM Transactions on Programming Languages and Systems, 16(6):1811{1841, 1994. 20. A. Mikhajlova and E. Sekerinski. Class re nement and interface re nement in object-oriented programs. In J. Fitzgerald, C. B. Jones, and P. Lucas, editors, FME'97: Industrial Application and Strengthened Foundations of Formal Methods, volume 1313 of Lecture Notes in Computer Science, pages 82{101. Springer-Verlag, September 1997. 21. H. Rasch and H. Wehrheim. Consistency between UML classes and associated state machines. In Kuzniarz et al. [17], pages 46{60. 22. M. W. A. Steen, H. Bowman, and J. Derrick. Composition of LOTOS speci cations. In P. Dembinski and M. Sredniawa, editors, Protocol Speci cation, Testing and Veri cation, XV, pages 73{88, Warsaw, Poland, 1995. Chapman & Hall.