AFormal Approach to Design Patterns in

This paper uses a transformation from procedural design patterns to object-oriented design patterns for the re-engineering of legacy code. A formal semantics for design patterns is introduced in order to justify the preservation of functionality in the re-engineering process. We give examples of the technique on a case study of an industrial legacy system in COBOL.


Introduction
Design patterns are particular forms of collaboration structures of classes or objects which are used to achieve particular design goals in an elegant manner.For example, the Strategy" design pattern used in the case study replaces explicit conditional choices between di erent algorithm implementations by implicit polymorphic choices given by alternative subtypes of a class.Design patterns are not usually de ned in a precise manner, as their very generality makes this di cult.However, if design patterns are to be used within a development method for a formal language such as VDM ++ 4 , or to transform legacy applications into functionally equivalent but more maintainable forms, we need to be able to determine when their use results in a correct design step.
The semantics of object-oriented systems has been given in a logical axiomatic framework termed the Object Calculus 6 .Here, we will 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" application of the pattern and after" versions of a system, and to show that the after" version re nes has all the functionality of the before" version.
Section 2 describes the Strategy pattern using VDM ++ , and the informal expression of its correctness.Section 3 introduces the object calculus.Section 4 describes the case study and the re-engineering approach taken.Section 5 describes how patterns such as Strategy can be formalised and shown to be correct design steps.We also discuss how patterns can be classi ed on the basis of the techniques used in the proof of their correctness.Finally, w e conclude with a summary of what has been achieved and what extensions can be considered.

VDM ++
VDM ++ is an object-oriented formal speci cation language based on the VDM-SL notation, with extensions to cover concurrent and real-time behaviour in addition to structuring mechanisms such as classes and inheritance.It is suitable for the expression of design transformations such as patterns because it contains both highly abstract speci cation mechanisms allowing operations to be de ned by pre and post-conditions, akin to the operation schemas of Fusion 2 and design and implementation-level mechanisms.
As an example of its application to pattern description we present in VDM ++ a before" and after" version of a system to which the Strategy pattern can be applied.The papers 12, 8 and thesis 14 together give similar representations of all the patterns described in 7 .
1st Irish Workshop on Formal Methods, 1997 A F ormal Approach to Design Patterns in Re-engineering be used for a particular abstract operation, the choice between these algorithms embedded in particular Strategy subclasses being made by polymorphism.
Strategy can be used to transform a system described on the left hand side of Figure 2 to the form given on the right hand side.
Informally we can reason that the new version of the system achieves the same functionality as the old: the set type1 operation of a Context1 object obj results in obj :strategy becoming a memberofConcreteStrategyA, the set of existing ConcreteStrategyA objects.But this corresponds to the abstract operation of setting strategy type equal to type1 , i f w e i n terpret strategy type by the conditional expression if strategy 2 ConcreteStrategyA then type1 else if strategy 2 ConcreteStrategyB then type2 else nil Likewise, the e ect of the ContextInterface operation on obj results in execution of Code1 i f strategy 2 ConcreteStrategyA, and in execution of Code2 i f strategy 2 ConcreteStrategyB, which corresponds to the interpretation of the speci ed behaviour.We can see that there are some informal constraints on the validity of this re nement: strategy must be an existing object of one of the two subtypes of Strategy at the point where ContextInterface is called; strategy cannot move from one subclass to another during an execution of ContextInterface.More precise constraints on the correctness of the step will be derived in Section 5.

The Object Calculus
An object calculus 6 theory consists of collections of type and constant symbols, attribute symbols denoting time-varying data, action symbols denoting atomic operations and a set of axioms describing the types of the attributes and the e ects, permission constraints and other dynamic properties of the actions.The axioms are speci ed using linear temporal logic operators: in the next state, U strong until, S strong since, 2 always in the future and sometime in the future.There is assumed to be a rst moment.The predicate BEG is true exactly at this time point.The version used here is that de ned in 9 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 16 , Syntropy 3 o r V D M ++ , w e de ne 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 attc : @ C o f , C written as c:att for conformance with standard OO notation and each method actx : X is represented by an action symbol actc : @ C ; x : X , written as c!actx.Output parameters and local variables of methods are also represented as attribute symbols of , C .
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 de ne the e ect of methods by means of the calling" operator between actions: 8 i : N 1 9 j : N 1 " ;j = " ; i ;j = ; i 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 de ned to represent speci cation statements and executable code: preG postP names an action with the following properties: 8 i : N 1 G " ; i 8 i : N 1 P att~" ; i= , att ; i 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 o f 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!me o f a executes 5 .Likewise, C can only change as a result of new C or kill C invocations.
Assignment t 1 := t 2 can be de ned as the action pretrue postt 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: 8 i : N 1 9 j ; k : N 1 " ; ;i = " ; j ; ;i = ;k " ;k = ; j and 8 j ; k : N 1 " ;k = ; j 9 i : N 1 " ; ;i = " ; j ; ;i = ;k The Similarly, while loops can be de ned recursively.Some important properties of which will be used in the paper are that it is transitive: ^ and that constructs such a s ; a n d if then else are monotonic with respect to it: 1 2 ^ 1 2 1 ; 1 2 ; 2 and If calls then every condition established by is also established by : P P 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 Re nement
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 , i n , 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 re nement.W e shall say that a system D re nes 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 i n terpretations are usually split into two parts, consisting of a conservative extension and a theory interpretation of , C in .The extension typically introduces new symbols which are de ned by axioms of as being equal to some combination of symbols C o f s y m bols of , D .These symbols then directly interpret the symbols of , C .Here we will combine and , D .

Re-engineering Legacy Applications
A n umber of approaches have been developed for reverse-engineering non-object oriented applications into an object-oriented form 18, 15, 10, 1 3 .The REORG approach o f 1 8 i n v olves a 10-step process to transform a procedural COBOL program into an object-oriented one.Object classes are derived from the existing data 1st Irish Workshop on Formal Methods, 1997 structures such as records, database views and working storage sections, and access and update operations allocated to these classes on the basis of data usage analysis in the program.A problem is that analysis of di erent programs in a system can produce equivalent classes which are not recognised as such because of di erent data names ie, attributes that are synonyms are created.The HOOSM approach of 15 addresses these problems.HOOSM is described as a hybrid between conventional OO modelling languages, state-based reactive speci cation systems and event-driven programming models.The approach again bases initial object recognition on the data of the application, but carries out a detailed alias analysis on the structure and types of records to identify possible synonyms.Additional objects are based on the program and its sub-procedures paragraphs" in COBOL.A normalisation procedure attempts to recognise subtyping relationships.
Both REORG and HOOSM may fail to recognise high-level design objects or intentions in the code, and do not provide systematic ways of retaining these objects in the re-engineered system.Our approach has some elements in common with the REORG and HOOSM approaches, but extends them by using transformations from procedural patterns to object-oriented p atterns as the underlying process.
The utility of this approach is that design patterns are not unique to object-oriented systems: designers have always used some design patterns in the design of procedural systems, however idiosyncratic they may b e to their particular environment.In as far as the existence of these patterns assist in program comprehension and maintenance, we do not want to erase or disregard them in the transformation to a new OO architecture, but instead to reuse and adapt them, and use them to select new OO design patterns which a c hieve the design goals in a more e ective w a y .The loss of maintainer understanding as a result of re-engineering is one of the major drawbacks with current re-engineering techniques.
In re-engineering, it is di cult to identify design level" objects, i.e., objects other than the ones derived directly from data structures, or the record structures of les 10 .In our approach the design pattern transformation guides identi cation of higher level objects in the transformed systems.These objects could be processes, computations or even objects that determine the control ow, as shown in the following case study.

The Billing System
The case study used here concerns a billing system for water charges used by a utility company.The code is currently being used and hence the case study is illustrative of a real-world" application.The system, implemented in COBOL, was originally developed in the early 80's for the IBM 4331.In the early 90's the hardware platform was changed to an AIX-based IBM Risc 6000.ISAM les are used for persistent storage, and the system is essentially batch-oriented.
During the platform change the code was re-engineered to an extent, with GOTO's being replaced by PERFORM's, and some modularisation added.
Bills are produced bimonthly based on, in the general case, the consumption of water read o from meters.For every billing cycle, rst the meter reading data is entered, then the bill processing step is executed.This computes the various charges due and updates the master le with the computed information.
The bill is a sum of water consumption charge, sewerage charges, meter rent and arrears, etc.For each consumer the water consumption charge is calculated in two main steps.In the rst step the consumption is computed and in the second, based on the consumption and other factors detailed below, the charge is calculated.
The consumption calculation involves di erentiating several types of consumption: tari 5" constant estimated consumption, metered consumption, estimated consumption where either the start or nish meter reading is unknown, etc.
The charge computation involves di erentiating commercial and domestic consumption, and di erent levies for di erent slabs" of consumption at various tari s.
1st Irish Workshop on Formal Methods, 1997

The Re-engineering Process
The information used for re-engineering was the source code 14 and the available documentation: a two line description of the purpose of each of the programs.
The rst step in re-engineering the code was to derive a control ow graph for the programs, and rearrangement of this control ow graph to reveal more systematic structure 11 .Next the code within control ow nodes was divided up on the basis of which les and records objects it updated, and utility procedures often called from several locations separated out.The data-ow b e t w een program variables was examined to determine a formal speci cation of the functionality o f e a c h separated control-ow segment, as described in 11 .Low-level objects corresponding to les, records and screens are recognised, and le accesses, etc are replaced by method calls 10 .
Each program is then converted into a single object, whose methods correspond to signi cant control-ow nodes such as paragraph start nodes.Subsequent re-engineering steps take this as the starting point for the introduction of design patterns and further objects.Examples of such transformation are given below for the two modules.In this paper we will focus on the smaller of the two re-engineering tasks, that of the charge calculation module.

The Consumption Calculation Module
This module consists of two `layers'.The top layer consists of the control mechanism and the bottom consists of the computation procedures.The control layer determines which of the four procedures metered consumption, average consumption, in-between meter, tari 5 consumption in the computation layer will be used.As part of maintenance, both the control mechanism and the computation procedures may c hange independently.Hence the need for separation of concerns.As the rst step in introducing a new object structure for this system, we therefore break the monolithic object that contains the entire program into ve ner grain objects, one encapsulating the control mechanism and one for each of the consumption computation procedures.The four procedures are alternatives for the same computation, so their objects are given a uniform interface.
The control layer is structured as a number of cascading IF-THEN-ELSE statements.The pattern to be observed is that each successive IF statement c hecks for the non-standard computation case.If such a condition is found the control ow branches o to the relevant procedure in the computation layer.Otherwise it heads forward checking for other non-standard conditions until no such condition remains, in which case the standard computation is performed.Such a procedural pattern could be termed a sieve structure.
In re-engineering this pattern into the OO context, we use a combination of the Decorator and Chain of Responsibility patterns 7 .Chain of Responsibility is appropriate because the sieve procedural pattern involves a delegation of a request through a series of entities conditional tests and processing until a suitable receiver is found.Decorator is appropriate because each of the conditional handlers may i n v olve speci c additional processing which m a y b e c hanged independently of other handlers.
In this solution, each conditional method in the original class becomes an object of a class Conditional Figure 3.  Using these conditional objects one can build an arbitrarily complex control structure by class composition.A correctness condition is that each o f t h e c hains of responsibility should end with a ConsumptionCalculation object ie, with no further conditional processing in order to avoid endless loops in the object reference structure.In this program the chaining of conditional objects is shown in Figure 4.
The individual conditionals in the program are all based on some variable of either the master le of customers or the meter reading le.For example, the condition class 2000MetDataConsm has the condition expression mast:tari = 5 and the class 2100CalcReadingCond has the expression mtr:meter read = 0. Hence the former needs a reference to the MasterRec class and the latter to MeterRec only.The 2000MetDataConsm class is as follows: In terms of structure, the conditionals are linked together in a recursive pattern like that of the Decorator pattern, with the Conditional objects acting like Decorator objects and calling other CondHandler Component objects, and with the consumption calculation objects acting as leaf nodes ConcreteComponents in the recursion.In terms of behaviour, however, the chain resembles the Chain of Responsibility pattern.Each object in the chain checks for the condition it is equipped to recognise, and forwards requests to either a if" successor or an else" successor depending on this condition.The di erence between this and the Chain of Responsibility pattern is that the handling" of a request consists of transferring control to an appropriate object.Some alternative patterns that could have been used are Strategy and State.However neither pattern provides the exibility in recon guring the conditionals which the above approach gives.In addition these patterns are best suited to the case where there is a relatively simple distinction between the various states" of a component, and transitions between these states, which is not the situation in the consumption calculation module.

The Charge Calculation Module
The charge calculation module is quite di erent in structure from the consumption calculation module.In the latter there was an elaborate control structure which ultimately transfers control to one of four calculation modules, which are mainly independent of each other.That is, the intermediate nodes of the control ow graph a tree in this case are primarily for control transfer purposes with relatively little processing, and the leaves" of the tree contain all the functionality.In contrast the charge calculation module involves signi cant processing throughout, and the control structure is very much a part of the algorithm Figure 5.In the consumption calculation module the re-engineering was focussed on achieving greater exibility in the control mechanism, whilst in the present case it is required in the composition mechanism.Thus the selection of patterns for re-engineering re ects this di erence.
The initial formal speci cation, obtained by deriving low-level object classes from the records, les and statements1 etc represent straight-line segments of code or code containing only utility procedures and straight-line code.The precise details of these segments does not a ect the global restructuring of this class.
An important observation here is that at a very early stage the control ow bifurcates into two distinct branches which do not interact until a call is made to 1400 dom water charges and 1500 com water charges, at which stage each of the branches terminates.In addition cond1 is independent o f a n y of the preceding processing statements and hence is una ected by them.It can, therefore, be moved out of the loop, and so bifurcate the control at the very start.

Introducing OO Patterns
The above observations suggest the use of the Strategy design pattern, because according to 7 , it is appropriate for situations where a class de nes many behaviours, and these appear as multiple conditional statements in its operations" and where di erent v ariants of an algorithm are needed.
1st Irish Workshop on Formal Methods, 1997 By introducing this pattern we are able to de ne an overall structure of the calculation of the consumption charges by using an abstract ChargeCalculation class.The two branches of the tree represent the two algorithms strategies that can be used to perform the actual calculation.The choice depends on cond1 whether tari 5 applies or not.The two strategies are encapsulated as NormalChargeCalculation and Tari 5ChargeCalculation classes, and made subclasses of ChargeCalculation Figure 6.We assume that the persistent objects such as les which the program manipulates are also declared as instance variables of the appropriate classes in the above pattern structure.
The restructured design of the system is much more complex than a simple de nition of new classes for data objects.We h a v e i n troduced a number of new objects in the system.So the issue is whether this has unnecessarily increased the complexity of the system, or whether there are de nite bene ts in the new structure.In detail: OO Implementation The new system can be more readily implemented in an OO language such as C++ or Object COBOL 19 .However a design only introducing data-based objects would have been su cient for this.
Maintenance requirements Particularly for the consumption calculation the re-engineered system should be more maintainable, as new calculations can be added and the conditions under which calculations are performed can be changed more readily due to the more exible method object composition of combining conditionals in the new system.
Reuse potential The most important bene t of the new designs are their reuse potential.For example, the program structure of the consumption calculation module characterises a large class of batch processing programs, where a complex set of conditions lead to a relatively limited number of processing procedures.By using the decorated chain of responsibility" design we h a v e decoupled the logic of the program from the functionality.The programmer simply con gures the system with the appropriate conditions and their associated computation procedures.These can be revised for a number of di erent applications.
E ciency By introducing a number of objects, the execution path in both modules has become more complicated, compared to a straightforward IF-THEN-ELSE condition checking.Hence, purely in terms of execution e ciency, there might not have been any bene t.At the same time it should be noted that in such batch processing applications, the bulk of the processing time is consumed by database le access.The computations take up an insigni cant proportion of the total time.
The formal justi cation of such re-engineering steps is given in the following section.

Veri cation of Design Transformations
In this section we show h o w code transformations using patterns can be formally veri ed using the object calculus semantics given in Section 3.

Strategy Pattern
The object calculus theory interpretation between the old and new version of the system in the case of the Strategy pattern is given in Table 1.

Symbol of Client
Term of Client1 @Client @Client1 @Context @Context1 newClient All actions of the abstract system are interpreted by corresponding actions of the same name in the new system.The only signi cant c hange in representation is the interpretation of obj :aContext:strategy type by a conditional expression in obj :aContext:strategy.
The typing axioms of the abstract system are therefore directly provable, in their interpreted versions, in the concrete system.For example, the constraint that obj :aContext 2 In addition, because the frame axiom of Context must also be true in interpreted form in Context1, strategy can only change its existence or subclass during the execution of set type1 o r set type2.In particular, although a Strategy object could, in principle, be shared between two or more Context objects, these objects must simultaneously set its type.Otherwise, there could be time periods t1; t2 over which an object obj 2 Context1 will be idle not executing any action but during which the type of obj :strategy changes, which contradicts the interpretation of the frame axiom for Context which asserts that the strategy type attribute can only be changed during executions of the set type1 o r set type2 actions of obj .
In the case of the charge calculation restructuring, we h a v e the interpretation of actions given in  This interpretation provides a formal trace of the origin of the elements of the re-engineered system back to the initial system.It can be directly checked that the properties of the abstract actions are also true of the concrete actions that interpret them.

Classifying Design Patterns
The design patterns discussed in this paper and in 7 can be decomposed into 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: i n troducing an intermediary object in place of an original object-valued attribute.This is used, particularly in combination with Generalisation to create greater exibility 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.
4. Introduction of polymorphism: replacing explicit conditionals in a code segment b y 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.6. Introduction of recursive structuring: de ne an aggregation structure between a subclass and its superclass thus allowing unlimited compositions of subclass objects.Used in combination with generalisation, objects belonging to other non-recursive subclasses act as terminating elements in the recursive tree structure.7. Decentralise control: arrange a set or sequence of server objects into a linked list.Each object in the list decides whether to carry out processing itself and or to forward control to the next object in line.Figure 7 shows the structure of the rst three of these basic patterns.In the generalisation pattern one of the directions of access between C and S may be missing.Each form of design has an associated proof technique.These are summarised below, where oo denotes any object-valued attribute of C which is being transformed and att any non-object valued attribute of C .obj denotes an introduced intermediate object: 1. Annealing: i n terpret 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.A n y update of att in C is achieved by a call to a method of S which performs this update.2. Indirection: i n terpret 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: i n terpret 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.1st Irish Workshop on Formal Methods, 1997 More generally, there may be a new subclass for each v alue 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 12 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.6. Introduction of recursive structuring: w e m ust show that the abstract functional elements are implemented correctly at some depth of recursion in the new structure, and that, within the original speci ed domain of behaviour, the recursion terminates.7. Decentralise control: w e m ust show that the original functional elements are correctly implemented by some object in the chain or network of objects, and again, that this network does not contain cycles that could lead to non-terminating computations in cases where a de ned behaviour was speci ed.This set of basic proof techniques and interpretations allows us to compose proofs of correctness and re nement 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-ow graph structures, then inference rules corresponding to composition mechanisms allow us to compositionally prove programs correct.

Conclusions
This paper has demonstrated a technique for re-engineering procedural code into object-oriented designs, using design patterns to retain design information from the source code.Veri cation methods for this process have also been given.
Tool support for the re-engineering method illustrated in this paper is being developed, along the lines of the REFORM tool 20 .This tool will be equipped with a number of procedural and OO design patterns, and will provide assistance in the discovery of procedural patterns by using pattern-matching.Given a procedural pattern, it could also suggest the valid transformations to OO patterns that could be applied, and would carry out the selected transformation.

Figure 1 Figure 1 :
Figure 1 describes the general form of the Strategy pattern.The pattern allows multiple algorithms to

Figure 3 :
Figure 3: Decorated Chain of Responsibility Structure

Figure 4 :
Figure 4: Chain of Conditional Objects in Consumption Calculation

Figure 6 :
Figure 6: Architecture of Re-engineered System The new set of classes are as follows.

Figure 7 :
Figure 7: Basic Design Pattern Steps

4 .
Introduction of polymorphism: i n terpret 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.
If e is an expression, e denotes the value of e in the next time interval.

Table 1 :
Interpretation of Client into Client1 @Context for obj 2 Client in the theory , Client is interpreted by the predicate obj 2 Client1 obj :aContext 2 @Context1 in , Client1 .But this is a theorem of , Client1 from its own typing axiom for aContext, as required.The axiom for the e ect of obj :aContext!settype1in Client is: :aContext!settype1newConcreteStrategyA obj:aContext:strategy Similar reasoning shows that the interpretation of the axiom for the e ect of m in , Client is provable from the corresponding axiom for m in , Client1 .This follows from the proof for ContextInterface:In the case that obj :aContext:strategy 2 ConcreteStrategyA the axiom for AlgorithmInterface in , ConcreteStrategyA then yields the desired result.We obtain the other case if we can assume that obj :aContext:strategy 6 2 ConcreteStrategyA implies obj :aContext:strategy 2 ConcreteStrategyB when AlgorithmInterface is called.We can now make more precise the assumptions required for this reasoning to be correct: obj :aContext:strategy 2 Strategy at the point where ContextInterface is called; obj :aContext:strategy must remain in the same subclass of Strategy during the execution of obj

Table 2 ,
in addition to the standard interpretation for the Strategy pattern.The notation obj !Class`Method denotes

Table 2 :
Interpretation of ChargeCalculation into MeterRate 1 the action which behaves as the version of Method de ned in class Class, provided obj 2 Class, and which is otherwise unde ned in its behaviour.