BCS-FACS Northern Formal Methods Workshop

This paper views design patterns [5] as a transformation from a “before” system consisting of a set of classes (often a single unstructured class) into an “after” system consisting of a collection of classes organised by the pattern. To prove that these transformations are formal reﬁnements, we adopt a version of the Object Calculus [4] as a semantic framework. We make explicit the conditions under which these transformations are formally correct. We give some additional design pattern transformations which have been termed “annealing” in the VDM ++ world, which include the introduction of concurrent execution into an initially sequential system. We show that these design patterns can be classiﬁed on the basis of a small set of fundamental transformations which are reﬂected in the techniques used in the proof of their correctness.


Introduction
Design patterns are characteristic structures of classes or objects which can be reused to achieve particular design goals in an elegant manner.For example, the "State" design pattern discussed in Section 5.1 below, replaces local attributes of a class that record its state (in the sense of a finite state machine) by an object which provides polymorphic functionality in place of conditionals depending upon the state.If design patterns are to be used for formal object-oriented languages and methods, such as VDM ++ [2], the conditions under which their use leads to a functionally-correct refinement step need to be identified.
The semantics of object-oriented systems has been given in a logical axiomatic framework termed the Object Calculus [4].Here, we use an extension of this framework which allows the use of structured actions corresponding to programming language statements, in order to formulate the semantics of the "before" and "after" versions of a system to which a design pattern has been applied, and show that the "after" version refines the "before" version.
Section 2 introduces the object calculus and the syntax of VDM ++ [2] which we will use to illustrate design pat- terns.Sections 3, 4 and 5 consider some typical patterns from [5] and other sources, addressing creational patterns, structural patterns and behavioral patterns respectively.Section 6 gives a classification of design patterns and proof techniques.

The Object Calculus
An object calculus [4] theory consists of collections of type and constant symbols, attribute symbols (denoting timevarying data), action symbols (denoting atomic operations) and a set of axioms describing the types of the attributes and the effects, permission constraints and other dynamic properties of the actions.The axioms are specified using linear temporal logic operators: (in the next state), u (in the previous state), U (strong until), S (strong since), 2 (always BCS-FACS Northern Formal Methods Workshop, 1996 FORMALISING DESIGN PATTERNS in the future) and (sometime in the future).There is assumed to be a first moment.The predicate BEG is true exactly at this time point.and u are also expression constructors.If e is an expression, e denotes the value of e in the next time interval, whilst u e denotes the value of e in the previous time interval.
The version used here is that defined in [7] in order to give a semantics to VDM ++ .In this version actions are potentially durative and overlapping, with associated times !(; i), "(; i) and #(; i) denoting respectively the times at which the i-th invocation of is requested, activates and terminates (where i 2 N 1 ).
Modal operators } "holds at a time" and ~"value at a time" are added: '}t asserts that ' holds at t, whilst e~t is the value of e at time t.
In order to give a semantics to a class C, in, for example, OMT [11], Syntropy [1] or VDM ++ , we define a theory C which has the type symbol @C representing all possible instances of C, attribute symbol C representing all the existing objects of C, and creation action new C (c : @C) and deletion action kill C (c : @C) which respectively add and remove c from this set.
Each attribute att of objects c of C is formally represented by an attribute att(c : @C) of C (written as c:att for conformance with standard OO notation) and each method act(x : X) is represented by an action symbol act(c : @C; x : X), written as c!act(x).Output parameters and local variables of methods are also represented as attribute symbols.
An additional attribute now is included to represent the current global time.Notice that C and now are class attributes and new C and kill C are class actions, whilst the c:att and c!act are at the object level.
We can define the effect of methods by means of the "calling" operator between actions: In other words: every invocation interval of is also one of .This generalises the Object Calculus formula ) to take account of the case where both actions are durative, and where may be composite.
Composite actions are defined to represent specification statements and executable code: pre G post P names an action with the following properties: In other words, G must be true at each activation time of , whilst P, with each "hooked" attribute ( att interpreted as the value att~"(; i) of att at initiation of , holds at the corresponding termination time.
A frame axiom, termed the locality assumption, asserts that attributes of an object a of C can only be changed over intervals in which at least one of the actions a!m(e) of a executes [3].Likewise, C can only change as a result of new C or kill C invocations.
Assignment t 1 := t 2 can be defined as the action pre true post t 1 = ( t 2 where t 1 is an attribute symbol.Similarly sequential composition ";" and parallel composition "jj" of actions can be expressed as derived combinators: The MAL [12] operator []P is defined as: where each pre-state attribute ( att is replaced by the value att~"(; i) of att at initiation of .Conditionals have the expected properties: Similarly, while loops can be defined recursively.
Some important properties of which will be used in the paper are that it is transitive: and that constructs such as ; and if then else are monotonic with respect to it: ( 1 2 ) ^( 1 2 ) ) ( 1 ; 1 2 ; 2 ) and Theories representing subsystems can be composed from the theories of the classes in these subsystems by theory union and renaming.Thus we can compare the functionality of a system (with no distinguished "main" class) with that of another system, via their theories rather than forcing all comparisons to be made between particular classes.This is useful in the case of design patterns, which usually concern sets of classes.

Interpretations and Refinement
The most important relationship between theories is that of theory interpretation: there is a theory interpretation morphism from a theory C to a theory D if every theorem ' of C is provable, under the interpretation , in D : where interprets the symbols of C as suitable combinations of symbols of D : actions are interpreted by actions (basic or composed), and attributes by terms.For example a single action of C could be interpreted by a sequential combination ; of actions of D . is lifted to formulae in the usual way.This concept will be taken as the basis of refinement.We shall say that a system D refines a system C if there is a theory interpretation from the theory C of C to the theory D of D. In the object calculus such interpretations are usually split into two parts (Figure 1), consisting of a conservative extension and a theory interpretation.The extension typically introduces new symbols which are defined by axioms of as being equal to some combination of symbols C() of symbols of D .These symbols then directly interpret the symbols of C .Here we will combine and D .

VDM ++ Specifications
A VDM ++ specification consists of a set of class definitions, where these have the general form: The types, values and functions components define types, constants and functions as in conventional VDM (although class reference sets @D for class names D can be used as types in these items -such classes D are termed suppliers to C, as are instances of these classes.C is then a client of D).The instance variables component defines the attributes of the class, and the inv defines an invariant over a list of these variables: objectstate is used to include all the attributes.The init statement defines a set of initial states in which an object of the class may be at object creation.Object creation is achieved via an invocation of the operation C!new, which returns a reference to a new object of type C as its result.This operation is interpreted as the action new C (c) for the created object c reference.
The methods of C are listed in the methods clause.Methods can be defined in an abstract declarative way, using specification statements, or by using a hybrid of specification statements, method calls and procedural code.Input parameters are indicated within the brackets of the method header, and results after a value keyword.Preconditions of a method are given in the pre clause.
Other clauses of a class definition control how C inherits from other classes: the optional is subclass of clause in the class header lists classes which are being extended by the present class -that is, all their methods become exportable facilities of C.
If we have a method definition in class C of the form: The initialisation of a class C can be regarded as a method init C which is called automatically when an object c is created by the action new C : Other axioms derived from a class description are given in [7].
In the following sections we prove that the theory of the "after" system (resulting from an application of a pattern) is an extension, via a suitable interpretation, of the theory of the "before" system.Usually we will only prove interpretation for selected axioms for the effect of actions, as many of the other axioms (eg, axioms that give the typing of attributes or actions) are trivially preserved.
In the examples we will use the names of classes given in the book [5].

Creational Patterns
Creational patterns make the way objects and systems are constructed and instantiated more general and flexible.For example, "hard-coded" object creation operations are replaced with more declarative operations in the following pattern.

Abstract Factory
This pattern decreases the level of coupling between classes in a system by enabling a client class to create objects of a general kind without needing to know what particular implementation subtype they belong to.The before and after structures of a system to which this pattern has been applied are given in Figure 2. The notation of [5] has been used: a dashed arrow indicates a creation dependency, whilst a solid arrow indicates clientship.The left-hand side of Figure 3 shows the initial structure of the system.The disadvantage of this approach is the necessity for a case statement and knowledge in Client of the names of the implementation classes ProductA1, ProductA2, etc.
In the revised version, on the right hand side of the figure, we factor out the implementation dependence into the factory objects.An initialisation action to set implementation kind in Client becomes an action creating factory in Client 1. ConcreteFactory1 is a concrete subtype of AbstractFactory.ConcreteFactory2 is defined similarly.The implementation kind attribute has been replaced by polymorphic behaviour depending upon which subclass ConcreteFactory1 or ConcreteFactory2 of AbstractFactory the factory object belongs to.
The theory Client of Client is the union (formally, the colimit) of the theories of AbstractProductA, AbstractProductB and of their subtypes, together with the axioms and symbols derived from the attributes and methods of Client itself.
The interpretation of the theory of Client into the theory of Client 1 is therefore as shown in Table 1.Symbols of ProductA1, etc, are unchanged in the translation.
In the theory of Client we have the axiom: productA : @AbstractProductA; productB : @AbstractProductB; implementation kind : This must be valid in the theory of Client 1.It is proved by using the definition of CreateProductA and CreateProductB in the respective ConcreteFactory classes.For example, using the definition of CreateProductA we have: Using oo:factory for obj and oo:productA for res, and the similar axiom for CreateProductB in the theory of ConcreteFactory1, we then have from the Client 1 axiom of settup: The other case of the interpretation of the axiom of settup in Client follows by consideration of oo:factory 2 ConcreteFactory2.
An important correctness property (preservation of the frame axiom) which must be true for any pattern which introduces an intermediate class such as AbstractFactory to implement attributes of a client class, is that objects of this intermediate class should not be shared between distinct clients.For example, if another object had access to the factory of a Client object obj then it could delete or change the class of factory during the execution of obj!settup, so invalidating the above reasoning.In general the frame axiom of a class C requires that if we have an interval [t 1 ; t 2 ] over which no method of oo : C executes, then we expect all the attributes oo:att of oo to have the same value at t 2 as at t 1 : oo:att~t 1 = oo:att~t 2 .If, however, some intermediate object obj is used to implement these attributes: oo:att being implemented by oo:obj:att 1, say, then methods could execute on oo:obj in the interval [t 1 ; t 2 ] without any action of oo executing -because some distinct client oo2 6 = oo has oo2:obj = oo:obj and calls methods of oo:obj in this interval.Thus it would be possible for oo:obj:att 1 to change in value over such intervals.

Structural Design Patterns
Structural patterns address ways of combining classes via inheritance or class composition to form larger structures useful in design.Before application of the pattern, the functionality of the initial version of the system is typically carried out via a direct but inflexible combination of objects.The new version introduces more objects and indirection, but provides a more adaptable and reusable architecture.Proof of correctness of these patterns is based on the observation that is transitive: if we implement a method m() == Def by defining an intermediate method n() == Def and redefining m to call n, then the resulting semantics of m is unchanged.

Adapter Pattern
In this pattern the interface of an existing class is adapted for use in a new system by placing an intermediate object or class between it and the system, which translates requests from the system into a form appropriate to the reused class.
An example of this transformation in VDM ++ could look as follows.The original unrefined specification (on the left of Figure 4) attempts to do the adaption directly within a client.Client 1 instead uses an intermediate object target.h(g(x)) = f (x) for x : X. target should be in the Adapter subtype of Target when target!request(g(x)) is executed.
The theory Client of Client incorporates the theory of Adaptee, and has action symbols obj!m(x : X) with the axiom obj 2 Client ) obj!m(x) (obj:C1; (obj:adaptee)!specific request(f (x)); obj:C2) The theory Client 1 of Client 1 also incorporates the theory of Adaptee, and additionally that of Target and its subclasses including Adapter.It has the local attributes of Client except that adaptee is replaced by target : @Target.It has the same local action symbols as Client, but the axiom for m is replaced by: obj 2 Client 1 ) obj!m(x) (obj:C1; obj:target!request(g(x)); obj:C2) where we know that target 2 Adapter at commencement of m(x): 8 i : N From the theory of Adapter we know that target 2 Adapter ) (target!request(t) (target:adaptee)!specific request(h(t))) Hence we can infer the axiom for Client from that of Client 1, by using the transitivity of and the monotonicity of ; with respect to and so Client 1 refines Client, as expected.
Other cases of the adapter pattern can be treated in a similar way.The key requirement for correctness is that the intermediate target exists and is in the correct subtype at the point in the client code where the interface call is made.

Facade
The facade pattern aims at bundling up a group of objects which are typically used together by client subsystems, via a few high-level operations.It replaces direct interfaces to these objects by a single simplified interface in a "facade" object (Figure 5).
This pattern has a similar structure to the previous pattern.The difference is that the facade object must interpret calls to a number of objects contained within the subsystem for which it serves as an interface.Thus a direct call obj1!m1(e) in a client of the subsystem could be replaced with a call facade!method1(e)where method1(e) simply calls obj1!m1(e).The interpretation interprets obj1 by facade:obj1, and similarly for each of the contained objects.
A more interesting case is where the external services offered by the facade are some combination of calls on the contained objects.For example, if an external service of the subsystem was usually achieved by two successive calls: BCS-FACS Northern Formal Methods Workshop, 1996 Proving that an invocation facade!m(e) refines the original combination of calls is direct.The theory of the new version of the system contains the additional Facade class and attributes and actions for it (its attributes include an attribute for each object obj that was originally in the system).For each client, the old version of its functionality has to be rewritten in terms of calls to a supplier facade object.The refinement relation is that each original object obj is now implemented by facade:obj.Again, we must be able to guarantee that facade exists at the points where invocations of its methods are made.In addition, the object references obj of the facade must be constant after its creation, assuming that the original objects they implement were constant in the initial version of the system.

Annealing a Map
This pattern is a standard VDM ++ annealing step.It is more specific to the formal specification context than the pre- vious patterns, but the same approach can be used in proving that it is a refinement.The abstract version of the system (on the left of Figure 6) contains an attribute which is a map.In the refined version we have eliminated the abstract mathematical map data type, as a step towards implementation.The VDM type [S] is shorthand syntax for the union type S j nil.Similarly, for lookup the interpretation of the condition t 2 dom(obj:att) in System is the condition 9 tobj 2 obj:att 1 tobj:t val = t.

The interpretation of System into
The axiom for init System is: obj 2 @System ) obj!init System pre true post obj:att = f7 !g The interpretation of this axiom is: obj 2 @System 1 ) obj!init System 1 pre true post (obj:att) = f7 !g and (obj:att) is ft:t val 7 !t:mapsto:s val j t 2 obj:att 1g which, from the axiom of init System 1 in System 1, has the value f7 !g as a result of init System 1 , as required.

Behavioural Patterns
Behavioural patterns are more complex than structural patterns as they concern algorithm definition and distribution between objects, and the patterns of communication between objects.The interpretation mappings are thus more complex than in the previous cases, and resemble more the type of data refinement transformations used in languages such as Z and VDM.

State
This pattern replaces a variable state : CState which records the current state of an object (where CState is an enumerated type), and tests on this state, with a new subordinate object which implements the state-dependent behaviour of the object via polymorphism.The aim is to avoid excessive case-considerations within the method definitions of the object, and to factor out state-independent functionality.It is similar in some respects to the Factory pattern, but involves more general behaviour than object creation.
The transformation of the Context class from [5] is shown in Figure 7. The

Mediator
The mediator pattern aims to decouple direct interaction between two objects.A typical example (Figure 8) is the representation of a one-many association via buried pointers where an invariant linking the two parts of the association is present in the theory of the specification, i.e. the union of the two class theories (1): The system is transformed into a version which avoids direct reference between A and B by defining a mediator (right hand side of Figure 8) where B1 and A1 are B and A without the embedded pointers or method met1 (or other methods which modify or access the pointers).
The theory of the new system is as for the old system but with the new attributes and axioms for Mediator, and without the attributes a of B and b of A. A specific object oo 2 Mediator is defined such that oo:r table contains exactly the pairs in the original relationship, and such that dom(oo:r table) = B 1 -the creation of an instance b of B1 must be carried out by this oo via an operation that also sets a link from b to some existing A1 object.
The axiom defining met1 is replaced by the definition of met1(a) in the new system.The definition of is given in Table 3. y : @B and x : @A in the last three definitions.Creation and deletion actions of A and B are likewise  Suitable new actions are needed in Mediator in order to add new pairs or delete pairs from the relation, and to maintain this invariant, in particular, to ensure that every link recorded in r table is between existing objects.
Given these interpretations of the symbols of A and B, we can show that all the axioms of the original version of the system are still true in the new system.The requirement that the attributes a and b are mutually inverse follows directly from their derivation from r table : (1) is interpreted as: which is clearly true.Similarly the proof of the interpretation of the axiom for met1 is direct.

Factoring Operations into Concurrent Parts
This pattern takes an operation which can be divided into two or more independent parts and splits them into methods of separate objects, to be invoked in parallel from the implementation of the original operation.An example is shown in Figure 9.

BCS-FACS Northern Formal Methods Workshop, 1996
The axiom for the effect of update in System is: pre true post obj:att1 = f ( ( obj:att1; x) ^obj:att2 = g ( ( obj:att2; x) We can prove, on the basis of the axioms for update in Class1 and Class2, that these methods separately achieve their half of this effect as a result of the calls obj:obj1!update(x) and obj:obj2!update(x)invoked from obj!update(x) in System 1.However, we also need to know that, for example, if #(; j) < #(;k)for the instances (; j) and (;k) of these calls involved in the parallel composition, where is obj:obj1!update(x),etc, then no further change to att1 in obj:obj1 can occur until (;k)terminates.Similarly if (;k)terminates first.These properties are automatically true if obj:obj1 and obj:obj2 are exclusively owned by obj.Under this assumption, the theory interpretation can be shown.

Observer
The intent of this pattern is to separate out aspects of an object which are conceptually distinct, and to maintain consistency between the states of the factored objects.A classic example is a system that displays data in several different formats: the presentation of the data (in windows, etc) should be separate from the storage of that data.
An abstract, unstructured version of such a system could have subjectstate as the basic data of the system, and observerstate representing some presentation of this data (left hand side of Figure 10).There can be many different observers in general.Usually Setstate will lead immediately to a call of Notify: Setstate ) System (Notify).
A refined version using the Observer pattern would have a form where there are a number of subclasses of Observer, each with their own definition of Update.In this way, knowledge of how to convert data for presentation is held only in the presentation classes, and Subject does not need to be modified to cope with new presentation formats.
The theory of System thus consists of attribute symbols for subjectstate and observerstate, type symbols for SState and OState, etc, and action symbols for Setstate and Notify.The new version of the system consists of linked Observer and Subject objects, so its theory contains that of Subject, ConcreteSubject and Observer, together with the appropriate attribute, type and action symbols from these theories and subclass theories.We additionally assume that subject 2

ConcreteSubject.
for the interpretation of System into System 1 is shown in Table 4

Classifying Design Patterns
The above patterns can be composed from a number of simpler transformations: 1. Annealing: the introduction of object-valued attributes for non-object valued attributes.This can be used to (i) protect a system from over-dependence on the form of this attribute; (ii) to introduce concurrency; (iii) to share common values.
2. Indirection: introducing an intermediary object in place of an original object-valued attribute.This is used, particularly in combination with Generalisation to create greater flexibility in a system.
3. Generalisation: extending a class by a superclass to allow alternative specialisations of behaviour or meaning, and re-directing references to it to references to the superclass.

Introduction of polymorphism:
replacing explicit conditionals in a code segment by polymorphic behaviour of supplier objects.Often this involves an annealing and/or generalisation.

5.
Bundling: placing a class wrapper around a collection of objects frequently used in combination.
Figure 11 shows the structure of the first three of these basic patterns.In the generalisation pattern one of the directions of access between C and S may be missing.The patterns described in this paper can now be decomposed into these basic patterns: Factory is an example of the 4th basic pattern -it is more specialised than State because it is assumed that the object whose polymorphic behaviour will be used to replace conditional behaviour will be of a constant type once it is created.In contrast the State pattern allows this object to change type after creation.
Adapter is a combination of indirection plus generalisation; Facade is an example of bundling; Annealing a map is an example of two successive applications of annealing -first we could anneal the elements of the map into Maplet objects with t and s values, and then we further anneal the s value of Maplet into the SClass; State is an example of the 4th basic pattern.Mediator (in [5]) is an application of generalisation twice (once to the domain class A and once to the range class B).Factoring Operations is an example of applying annealing twice -once to the att1 attribute and once to att2.
Observer is an application of annealing to obtain separate Observer and Subject classes from the original system, and then a double application of generalisation, as with the mediator pattern.1. Annealing: interpret att by obj:att.Ensure that obj is existing when reference is made to it, and that it is unshared.Any access to att in C is replaced by a query to the value of obj:att.Any update of att in C is achieved by a call to a method of S which performs this update.

BCS-FACS Northern
2. Indirection: interpret oo by obj:oo.Correctness conditions are as for annealing -the requirement that the obj is unshared can be weakened to requiring that each of the obj:oo is constant throughout its lifetime, and that the types of these objects are not changed, if these object references and their types were constant in the original system.
3. Generalisation: interpret oo by itself, but correctness proof against original functionality will require an assumption that oo 2 S where C 1 just expects oo 2 AbstractS.More generally, there may be a new subclass for each value of a certain expression in the attributes of C, rather than just the values of a particular attribute.Correctness conditions are as for 1.We also have to ensure that creation and deletion of elements of the subclasses ConcreteSi are only performed in cases that correspond to changes to the value of att in the original system. 5. Bundling: as for the facade pattern -the intermediate object must exist as soon as accesses to the subsystem are required, but can be shared, provided it keeps the references to the enclosed objects constant, and does not change their types.
This set of basic proof techniques and interpretations allows us to compose proofs of correctness and refinement steps when we build a pattern out of these basic steps.The situation is akin to that of compositional correctness proofs of structured programs: if we know that every program can be constructed hierarchically out of certain basic constructs (or control-flow graph structures), then inference rules corresponding to composition mechanisms allow us to compositionally prove programs correct.In the present case however, it is not clear that we have a complete set of basic steps.In addition, each proof of correctness of a basic step requires detailed knowledge about the classes involved.

BCS-FACS Northern Formal Methods Workshop, 1996
This paper has provided a formal justification for a number of design patterns in a way which connects them with formal refinement in object-oriented specification languages.We have shown that a number of design patterns, when expressed as transformations of VDM ++ specifications and designs, can be proved to be formal refinements in a se- mantic framework for VDM ++ .Other examples of structural transformation and refinement in VDM ++ are given in [8], [9] and [10].We have also applied this approach to proving correct some of the subtyping steps for statecharts defined in [1].
Current work is attempting to address the transformation from continuous real-time to discrete reactive descriptions of a system via more general forms of theory interpretation [6].

then(Figure 2 :
Figure 2: Application of Abstract Factory Pattern

Figure 4 :
Figure 4: Designs before and after use of the Adapter pattern

Figure 8 :
Figure 8: Designs before and after use of the Mediator pattern

Figure 9 :
Figure 9: Designs before and after factoring an operation into concurrent parts

4 .
Introduction of polymorphism: interpret att by if obj 2 ConcreteS1 then value1 else : : : , where we have a new subtype ConcreteSi of a new supplier class S of C 1 for each possible value valuei of att.
The definition of ; yields the usual axiom that [; ]' [][]' if ' has no ( att terms.

.. sync ... thread ... aux reasoning ... end C
where each attribute att of C occurring in Pre m;C is renamed to a:att in a:Pre m;C and similarly for Code m;C .v := D!new is interpreted as new D (a:v), self !n(f ) as a!n(a:f ), etc.

Table 2 :
1 (target 2 Adapter)}"(m(x); i) and that C1 does not change this property: target 2 Adapter ) [C1](target 2 Adapter).Part of the map for this interpretation is shown in Table 2. new and kill actions are also mapped from Client to Client 1.Other symbols are left unchanged by .The interpretation of the axiom of m in Client is then: Interpretation of Client theory in Client 1 theory obj 2 Client 1 ) obj!m(x) (obj:C1; (obj:target:adaptee)!specific request(f (x)); obj:C2) System 1 maps att into the term ft:t val 7 !t:mapsto:svaljt 2 att 1g and init System into init System 1 , @System into @System 1, etc.For example, the axiom for the effect of enter in the theory of System is:obj 2 System ) obj!enter(t; s) pre true post obj:att = ( obj:att f t 7 !sg The interpretation of the axiom of enter of System in System 1 is: val 7 !t:mapsto:s val j t 2 obj:att 1g = ft:t val 7 !t:mapsto:s val j t 2 ( obj:att 1g f t 7 !sg and this specification is clearly satisfied by the definition of enter in System 1.
Proof of correctness of the interpretation is direct, under the assumption that only existing objects are stored in att 1, that t 2 att 1 implies t:mapsto 2 SClass, and that the translation (att) is always a function.These can be proved to be invariants of System 1 by induction since enter and lookup preserve these properties.BCS-FACSNorthern Formal Methods Workshop, 1996 if 9 o : @TClass o 2 S ^o:t val = t then let o : @TClass be st o 2S ^o:t val = t in o : @TClass := TClass!new; new t!set(t; s); att 1 := att 1 [ f new t g); lookup(t : T) value s : [S] == let tobj = findObject(att 1; t) in if tobj 6 = nil then (s := tobj:mapsto:s val; return s) : T; s : S) = = (dcl sobj : @SClass := SClass!
attribute state has been replaced by stateobj.Other attributes of Context remain in Context 1. handle has definition Code1 in ConcreteState1 and Code2 in ConcreteState2 and in other subclasses of State representing concrete states.Likewise, transitions from one state to another are implemented in Context 1 by object deletion and creation: state := < statei > becomes CState = < state1 > j < state2 > j ::: Code1 0 is Code1 with each attribute att in its text replaced by stateobj:att, and similarly for Code2 0 .But this is implied by the axiom for request in Context 1 because obj:stateobj!handle has the semantics of the above conditional in this class.
else if ::: Other attributes att in Context are interpreted by att in Context 1 if att is not mentioned in Code1 or Code2.Attributes att used in either of these codes need to be moved into State and are interpreted by stateobj:att.@Context is interpreted by @Context 1 and Context by Context 1. Similarly for the creation and deletion actions of these classes.The theory of Context contains attributes and actions for its attributes and methods, and the axiom obj 2 Context ) (obj!request if : : : ) The theory of Context 1 has additionally the theory of State and its subclasses, and state is replaced by stateobj : @State, with the axiom for request changed to: obj 2 Context 1 ) (obj!request (obj:stateobj)!handle)The axiom for request in Context is then interpreted by: where ConcreteState0 n f stateobjg ĈoncreteStatei = ( ConcreteStatei [ f stateobjg) BCS-FACS Northern Formal Methods Workshop, 1996

Table 3 :
Interpretation of Theory of A, B into Mediator Theory interpreted as the corresponding actions of A1 and B1.