Figure 3 (a) sketches the way protocol objects and algorithm objects interact. On the left side, protocol object a Object offers the services it inherits from its superclasses, as well as the new services that are specific to protocol . The actual algorithm implementing protocol is not part of a Object's code: instead, the latter uses services provided by strategy a Algo (on the right side of Figure 3 (a)). Whenever an operation related to protocol is invoked on a Object, the execution of the protocol is delegated to strategy a Algo. In turn, the services required by the strategy to run protocol are based on the inherited services of context a Object. Such required services merely identify entry point operations to underlying protocols needed to solve problem .
Figure 3: Strategy pattern in BAST
Each instance of class Algo represents one execution of protocol implemented by that class, and holds a reference to the context object for which it is running; any call to the services required by the strategy will be issued to its context object. There might be more than one instance of the same ProtoAlgo's subclass used simultaneously by a Object. At runtime, the latter maintains a table of all strategies that are currently in execution for it. Each message is tagged to enable a Object to identify in which execution of what protocol that message is involved, and to dispatch it to the right strategy. Figure 3 (b) presents the relationship between classes Object and Algo, using a class diagram based on the Object Modeling Technique notation . The correspondence between Algo strategy objects and layered protocol stacks is pictured in Figure 3 (c): at runtime, each strategy object represents a layer in one of the protocol stacks currently in execution.