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 [19]. 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.