4.5 UML-F tags for framework patterns
4.5 UML-F tags for framework patterns
Analogous with the Unification and Separation construction principles, the structure of a GoF pattern determines the particular set of UML-F tags. In the case of the GoF framework patterns, each pattern description has a section labeled Structure which shows a class diagram. The class and method names in such a diagram, together with the pattern name, form the set of UML-F tags: PatternName methodName , PatternName ClassName ; and for potential future Java- or C#-based versions of the GoF catalog or other pattern catalogs, PatternName InterfaceName . In situations where associations and attributes play a role, tags of the form PatternName-associationLabel and PatternName-attributeName are present as well.
This section illustrates the straightforward mechanism for the GoF patterns Factory Method, Composite, and Strategy as well as for a domain-specific pattern called Calculation.
Consider the layered relationship between the UML-F tag sets[7] for the design patterns, construction principles, and the template and hook tags (see Figure 4.24). The figure does not show the lower level UML-F tags fixed , adapt static , and adapt dynamic on which the template and hook tags are loosely based. In addition to presenting the sample UML-F tag sets for Factory Method, Composite, Strategy, and Calculation, this section discusses the layered relationships in further detail.
[7] The tags of a construction principle or pattern form one tag set. For example, the three tags of the Unification principle form the Unification tag set.
Figure 4.24. Layers of UML-F tag sets
The essential framework construction principles Unification, Separation, Composite, Decorator, and Chain of Responsibility represent the possible combinations of templates and hooks in one or two classes/interfaces. Since the GoF patterns Composite, Decorator, and Chain of Responsibility are identical with those core framework construction principles which result from combinations of templates and hooks via inheritance, we suggest the GoF names and structure of these three patterns as the basis from which to derive the UML-F tag sets. This section illustrates that derivation for the Composite pattern. Appendix B presents the tag sets for the Decorator and Chain of Responsibility patterns.
Though the other GoF framework patterns and domain-specific patterns rely on either Unification or Separation of templates and hooks, framework developers needing to express the richer semantic information inherent in these patterns, do so by annotating a framework by means of the corresponding UML-F tag sets. The application of one of these patterns expresses the intended use and adaptation possibilities beyond the static structure to which a pattern is often reduced. The semantics of a pattern tag are defined through its structural and behavioral constraints, as well as its intended use.
4.5.1 UML-F tags for the Factory Method pattern
Figure 4.25 shows the static structure of the Factory Method pattern according to the GoF catalog. Note that the diagrams in the catalog adhere to the Object Modeling Technique (Rumbaugh et al., 1994) notation which significantly influenced UML but which is no longer used in its original form. All the diagrams in this book adhere to the UML notation.
Figure 4.25. Structure of the Factory Method pattern (adapted from Gamma et al., 1995)
According to the static structure of the Factory Method pattern,[8] the UML-F tag set consists of these tags:[9]
[8] The tags adopt the Java convention of using uppercase first letters in class/interface names and lowercase first letters in method names. The use of the italics style indicates an abstract class, an interface, or an abstract method.
[9] We use the abbreviations FacM for Factory Method, and anOp for anOperation.
FacM Creator
FacM facM
FacM anOp
FacM Product
FacM ConcreteProduct
FacM ConcreteCreator
FacM facM
One could argue that the subclasses of Creator and Product are, in some cases, not appropriate for documenting that pattern. So an alternative, shorter list of UML-F tags would be: FacM Creator , FacM facM , FacM anOp , FacM Product .
Figure 4.26 attaches the UML-F Unification tags to the methods of class Creator. This illustrates in detail the relationship between the tag sets of the Factory Method pattern and the Unification construction principle. It also demonstrates the additional semantic information provided by the Factory Method pattern. For example, the Unification pattern does not deal with a Product class.
Figure 4.26. Application of the Unification construction principle in the Factory Method pattern
Definition of the UML-F Factory Method pattern tags
Table 4.6 summarizes the UML-F tags of the GoF Factory Method pattern.
| Tags | FacM Creator , FacM facM , FacM anOp , FacM Product , FacM ConcreteProduct , FacM ConcreteCreator , FacM facM . |
| Apply to | class ( FacM Creator , FacM Product , FacM ConcreteProduct , FacM Concrete-Creator ), method ( FacM facM , FacM anOp , FacM facM ), interface ( FacM Product ). |
| Type | String. |
| Motivation and purpose | The tags highlight the application of the Factory Method pattern in a framework by marking the corresponding methods as well as the classes/interfaces belonging to that pattern. |
| Informal explanation of effect | The Factory Method pattern implies that the creation of an instance of static type Product is deferred to a subclass of Creator. The subclass has to override the method marked by the tag FacM facM . |
| Expansion | The Factory Method pattern tags FacM Creator , FacM facM , and FacM anOp expand to the more basic UML-F Unification tags Unif TH , Unif t and Unif h (see Figure 4.26). |
| Discussion | The UML-F Factory Method pattern tags FacM Creator , FacM facM , FacM anOp , and FacM Product must always be used together. The tags FacM ConcreteProduct , FacM ConcreteCreator , and FacM facM are optional and can only be used in conjunction with the former list of tags. |
4.5.2 UML-F tags for the Strategy pattern
Figure 4.27 shows the static structure of the Strategy pattern according to the GoF catalog (Gamma et al., 1995). The original structure diagram shows three subclasses of the abstract class Strategy: ConcreteStrategyA, ConcreteStrategyB, and ConcreteStrategyC. In most situations where UML-F tags are attached to framework spots, these exemplar subclasses are not relevant. Thus, we reduce the structure of the pattern to the one shown in the class diagram in Figure 4.27. This demonstrates that class diagrams in the structure section of the GoF catalog don't have to be transformed 1:1 into UML-F tag sets. Using the basic tag adapt-static to mark the generalization relation explicitly as extensible demonstrates the intention of this pattern in a more general form than only through exemplar class diagrams. The appropriate use of UML-F tags provides additional descriptive power.
Figure 4.27. Structure of the Strategy pattern (adapted from Gamma et al., 1995)
Another aspect of the structure of the Strategy pattern is the fact that the association between the Context and the Strategy classes has the label 'strategy'.
This can also be included in the UML-F tag set. So the UML-F tag set for the Strategy pattern is:[10]
[10] We use the abbreviations Int for Interface, and alg for algorithm. Further abbreviations could be Ctxt for Context, and Strat for Strategy.
Strategy Context
Strategy anOp
Strategy strategy
Strategy Strategy
Strategy algInt
Strategy ConcreteStrategy
Strategy algInt .
or in a more abbreviated version: Strat Ctxt , Strat anOp , Strat strat , Strat Strat , Strat algInt , Strat ConcreteStrat , Strat algInt . An alternative shorter tag set would drop the tags of the concrete subclass(es) of Strategy.
The Strategy pattern relies on the Separation construction principle. Figure 4.28 attaches the UML-F Separation tags to the methods of the classes Context and Strategy.
Figure 4.28. The Strategy pattern is based on the Separation construction principle
Figure 4.29 shows the UML-F diagram of the case study where the rounding of class Converter is kept flexible by means of the Strategy pattern. The annotation applies the UML-F tags Strat ConcreteStrat and Strat algInt for a specific subclass of Strategy only to class DefaultRPol.
Figure 4.29. UML-F diagram with Strategy pattern tags
Again, a tool could be based on the UML-F pattern tags as was illustrated in the cases of the template and hook tags, and the Unification and Separation tags. Figure 4.30 illustrates this for the Strategy pattern. Let us assume that the group of UML-F tags has the name Rounding (not shown in Figure 4.29). A user would select a particular incarnation of the Strategy pattern by name. The tool would, for example, define the hyperlinks that link the methods and classes comprising the pattern structure to the corresponding framework spots and vice versa. As a consequence, tools that support UML-F would typically offer a view of various pattern structures, such as the one in the gray box for the Strategy pattern.
Figure 4.30. Tool-assisted mapping of the structure of a pattern to framework spots
Definition of the UML-F Strategy pattern tags
Table 4.7 summarizes the UML-F tags of the GoF Strategy pattern.
| Tags | Strategy Context , Strategy anOp , Strategy strategy , Strategy Strategy , Strategy algInt , Strategy ConcreteStrategy , Strategy algInt ; or their abbreviations Strat Ctxt , Strat anOp , Strat strat , Strat Strat , Strat algInt , Strat Concrete Strat , Strat algInt . |
| Apply to | class ( Strategy Context , Strategy Strategy , Strategy ConcreteStrategy ); method ( Strategy anOp , Strategy algInt , Strategy algInt ); interface ( Strategy Context , Strategy Strategy ); association ( Strategy strategy ). |
 | |
| Type | String. |
| Motivation and purpose | The tags highlight the application of the Strategy pattern in a framework by marking the corresponding methods as well as the classes/interfaces belonging to that pattern. |
| Informal explanation of effect | The Strategy pattern implies that the handling of a request in a Context object is deferred to a subclass of Strategy, or a class that implements the interface Strategy. Specific Strategy classes override/implement the abstract method marked by the Strategy algInt tag. |
| Expansion | The Strategy pattern tags Strategy Context , Strategy anOp , Strategy Strategy , and Strategy algInt expand to the more basic UML-F Separation tags Sep T , Sep t , Sep H , and Sep h . The figure above illustrates this, though the templates and hooks are not explicitly marked by the Separation tags. |
| Discussion | The UML-F Strategy pattern tags Strategy Context , Strategy anOp , Strategy Strategy , and Strategy algInt must always be used together. The tags Strategy strategy , Strategy ConcreteStrategy , and Strategy algInt are optional and can only be used in conjunction with the former list of tags. |
4.5.3 UML-F tags for the Composite pattern
Figure 4.31 shows the static structure of the Composite pattern according to the GoF catalog (Gamma et al., 1995). The getChild(int) method in the classes Component and Composite has been dropped as this represents a quite specific way of accessing the objects in the Composite object tree. The resulting UML-F tags are[11] :
[11] We use the abbreviations op() for operation(), add() for add(Item), and remove() for remove(Item).
Figure 4.31. Structure of the Composite pattern (adapted from Gamma et al., 1995)
Composite Client
Composite Component
Composite op
Composite Composite
Composite children
Composite op
Composite add
Composite remove
Composite Leaf .
The Client and Leaf tags could be omitted in a shorter tag set.
Consider as an example the classes Item and Folder in Figure 4.32. Folder manages any number of objects of static type Item (such as TextDoc and DrawDoc instances) because the association between Folder and Item has the cardinality *. Folder also manages any future specializations of Item, such as VoiceDoc. As Folder is a subclass of Item, Folder instances can also manage any number of other folders. Thus, Folder allows the definition of a tree hierarchy of objects this is a core characteristic of the Composite pattern.
Figure 4.32. Sample application of the Composite pattern
The schematic annotations point out that class Item corresponds to H and class Folder to T at the abstraction level of templates and hooks. The names of the template and hook methods are the same in the Composite pattern. The template method typically iterates over the collection of managed objects. In the case of the getSizeInBytes() method, the hook method is an abstract method that defines that the size of an item should be calculated. The corresponding template method in class Folder iterates over the collection of items and adds the results to calculate the overall size of a folder. Though the method has a recursive flavor by passing the method call getSizeInBytes() on to all objects in the object tree, it is not a recursive method in the classic sense. Due to the structure of a template method in the Composite pattern, the composed tree can be treated as one object the methods forward the corresponding messages along the tree.
The methods addItem( ) and removeItem( ) provide basic support for managing the contained items. More elaborate solutions would, for example, provide methods for iterating over the contained items.
Figure 4.33 shows a sample object tree. The root Folder object manages another Folder instance and a TextDoc instance. The other Folder instance contains a DrawDoc instance and a TextDoc instance. Due to the forwarding mechanism inherent in each template method, messages flow through the object tree from the root down to the leaves. So a Folder object can be treated in the same way as a single object of static type Item.
Figure 4.33. Sample object tree
Definition of the UML-F Composite pattern tags
Table 4.8 summarizes the UML-F tags of the GoF Composite pattern.
| Tags | Composite Client , Composite Component , Composite op , Composite Composite , Composite children , Composite op , Composite add , Composite remove , Composite Leaf . |
| Apply to | class ( Composite Client , Composite Component , Composite Composite , Composite Leaf );method ( Composite op , Composite op , Composite add , Composite remove ); interface ( Composite Client , Composite-Component ) ; association ( Composite children ); see Figure 4.32. |
| Type | String. |
| Motivation and purpose | The tags highlight the application of the Composite pattern by marking the corresponding methods as well as the classes/interfaces and associations belonging to that pattern. |
| Informal explanation of effect | The Composite pattern implies that a tree of Component objects form a Composite object. The Composite object can be treated as a single object. The Leaf classes override/implement the methods of class/interface Component. If Leaf classes are added, the methods marked as Composite op have to be overridden/implemented and can be annotated by the tag Composite op . The Composite class implements the methods for managing a tree of Component objects. These methods are marked by the tags Composite add and Composite remove . |
| Expansion | The Composite pattern tags Composite Component and Composite op correspond to the hook class[12] and the hook method, Composite Composite , and Composite op to the template class and template method. Figure 4.32 illustrates this expansion. |
| Discussion | The UML-F Composite pattern tags Composite Component , Composite op , Composite Composite , Composite children , Composite add , and Composite remove must always be used together. Composite Client , Composite op , and Composite Leaf are optional and can only be used in conjunction with the former list of tags. |
[12] That is, the class containing a hook method.
4.5.4 UML-F tags for a domain-specific pattern
Frameworks contain numerous patterns that are not published in pattern catalogs, but which rely on one of the framework patterns, and thus on the essential framework construction principles. In many situations it might be useful to introduce UML-F tag sets that refer explicitly to these domain-specific patterns. The definition of these domain-specific UML-F tag sets works in the same way as for the pattern tags. The structure of a domain-specific pattern defines the tags. The structure of a domain-specific pattern should also be annotated by GoF pattern tags or the tags of the core construction principles. This ensures an explanation of the domain-specific pattern in terms of already understood designs.
The following example illustrates the introduction of a domain-specific pattern. Chapter 7 provides another example where the introduction of a domain-specific pattern is appropriate. The case study below assumes that a framework needs to keep various calculation algorithms flexible, with rounding as one specific calculation algorithm. Figure 4.34 shows the structure of the Calculation pattern. The UML-F tags for the Calculation pattern are:
Calculation Calculator
Calculation calcOp
Calculation CalcAlgorithm
Calculation calcAlg
Calculation ConcreteAlgorithm
Calculation calcAlg .
Figure 4.34. Structure of the Calculation pattern
Figure 4.35 annotates the Calculation pattern by means of the UML-F tags for the Strategy pattern. This points out that the Calculation pattern is a refinement of that GoF pattern. An alternative annotation of the Calculation pattern with the UML-F tags for the Separation construction principle would have served the same purpose.
Figure 4.35. Calculation pattern annotated with the Strategy pattern tags
Figure 4.36 applies the UML-F Calculation pattern tags to the currency converter example. The Calculation pattern tags could annotate any framework spot that keeps a calculation flexible.
Figure 4.36. UML-F annotation of the currency converter design
Definition of the UML-F Calculation pattern tags
Table 4.9 summarizes the UML-F tags of the Calculation pattern.
| Tags | Calculation Calculator , Calculation calcOp , Calculation CalcAlgorithm , Calculation calcAlg , Calculation ConcreteAlgorithm , Calculation calcAlg . |
| Apply to | class ( Calculation Calculator , Calculation CalcAlgorithm , Calculation ConcreteAlgorithm ); method ( Calculation calcOp , Calculation calcAlg , Calculation calcAlg ); interface ( Calculation CalcAlgorithm ): |
 | |
| Type | String. |
| Motivation and purpose | The tags highlight the application of the Calculation pattern in a framework by marking the corresponding methods as well as the classes/interfaces belonging to that pattern. |
| Informal explanation of effect | The Calculation pattern keeps the calculation algorithm flexible. Specific algorithms are implemented in subclasses of the CalcAlgorithm class or in classes that implement the CalcAlgorithm interface. They override/implement the method Calculation calcAlg . |
| Expansion | The Calculation pattern tags Calculation Calculator , Calculation calcOp , Calculation CalcAlgorithm , Calculation calcAlg , Calculation ConcreteAlgorithm , and Calculation calcAlg expand to the Strategy pattern tags Strategy Context , Strategy anOp , Strategy Strategy , Strategy algInt , Strategy ConcreteStrategy , and Strategy algInt (see Figure 4.35). |
| Discussion | The UML-F Calculation pattern tags Calculation Calculator , Calculation calcOp , Calculation CalcAlgorithm , and Calculation calcAlg must always be used together. The tags Calculation ConcreteAlgorithm and Calculation calcAlg are optional and can only be used in conjunction with the former list of tags. |
4.5.5 UML-F tags for non-framework GoF patterns?
This book focuses on how to support framework development and adaptation with the UML-F profile. The mechanism for defining UML-F tags for framework-related patterns in the catalog might be extended to the other patterns in the catalog as well one could simply take their structure and define the UML-F tag set. In principle, there is no objection to supporting the annotation of these GoF patterns in UML-F. On the other hand, that might become tricky in some cases. For example, the GoF Fa ade pattern actually deals with the problem of defining an interface for a subsystem. The structure of that pattern only shows the name Fa ade in a box that encloses a subsystem of unnamed classes. Thus, the resulting UML-F tag Fa ade Fa ade would not really help. On the other hand, the Proxy pattern is an example where the tag definition would make sense. One could argue that the Proxy pattern should be regarded as framework pattern which relies on the Separation construction principle. To conclude, it is up to the developer to choose further GoF patterns, or patterns from other catalogs, and to define the corresponding UML-F tags according to their structure. In this sense UML-F provides the mechanism for defining pattern tags without prescribing certain tag sets or restricting them. Applying the standardized template table for the definition of tags allows a systematic and easily conveyable definition of new tag sets.
EAN: 2147483647
Pages: 84