Section 19.3. CROSSCUTTING THEMES: THE MODEL

19.3. CROSSCUTTING THEMES: THE MODEL

Themes that specify designs for crosscutting requirements were introduced, without in-depth discussion, as part of Theme/UML in [4]. Theme/UML supports separate design models as independent views called design themes (denoted with a ABthemeBB stereotype on a UML package). Within the model, design themes may specify crosscutting behavior to be composed with other design themes. Crosscut elements are not referred to directly by name, but are reasoned about within the design through the use of parameterized elements. A composition specification mechanism is provided to bind those parameters to "real" elements that will be crosscut. Composition specification is achieved with Theme/UML's composition relationship that allows the designer to identify those parts of the theme designs that are related to each other and that therefore should be composed.

19.3.1. Specifying Templates

The UML defines a template as a parameterized model element that cannot be used directly in a design model [17]. Instead, it may be used as the basis to generate other model elements using a "Binding" dependency relationship. A Binding relationship defines arguments to replace each of the template parameters of the template model element. The UML orders template parameters in a dotted box on the template class. Since a crosscutting theme may potentially have multiple pattern classes (classes that are themselves placeholders to be replaced by real class elements), the representation of all the template parameters for all pattern classes is combined in a single box and placed on the theme box. Within this box, template parameters are grouped by class (each class grouped within <> brackets), and ordering is important to support composition specification.

Figure 19-2 illustrates a crosscutting theme with one pattern class, tracedClass, denoting that any class may be supplemented with trace behavior. A template parameter is defined for the pattern class, called _TRacedOp(), which represents any operation requiring tracing behavior. One standard class, called trace, is also included in the design. The design of tracing behavior is now contained in the TRace theme model, with references made to the pattern class and template operation as required.

Figure 19-2. Specifying templates in a trace composition pattern.

19.3.2. Specifying Crosscutting Behavior

Crosscutting behavior essentially supplements (or merges with) behavior it cuts across. Theme/UML supports merging of operations by allowing a designer to identify operations in different design themes that correspond and should be merged. This means that execution of any one of the corresponding operations results in the execution of all the corresponding operations. This is achieved within the model with the generation of an interaction model realizing the composed (output) operation as delegating to each of the corresponding (renamed) input operations.

This semantics can be explicitly utilized for the specification of patterns of crosscutting behavior. The designer may explicitly refer to the input (i.e., pre-composition) and output (i.e., post-composition) operations separately. The designer defines an input operation as a template parameter and refers to an actual, replacing operation by prepending an underscore to the template name. The generated output operation is referenced with the same name but without the prepended underscore.

As specified by the theme in Figure 19-3 for pattern class tracedClass, execution of any operation that replaces the _TRacedOp(..) template will, in the output theme, result in the execution of traceEntry() before the execution of the replacing operation and in the execution of TRaceExit() after the execution of the replacing operation. Note that _tracedOp(..) was also given private visibility in Figure 19-2 as defined by merge integration [2, 3]. The ".." parameter specification of _tracedOp(..) indicates that an operation of any signature may replace the template. Possibilities in this specification relate to the scope within which the replacing operation is executed. For example, in Figure 19-3, the active period of the execution of tracedOp(..) defines the scope for this operation, and any parameters defined may be used within this scope. The parameter possibilities are defined in Table 19-1. This trace composition pattern theme effectively specifies the merging of trace behavior with any operation replacing _tracedOp(..).

Figure 19-3. Specifying patterns of crosscutting behavior.

Table 19-1. Parameter Scope

Parameter	Usage
op()	In this case, the replacing operation must have no parameters.
op(..)	Here, the replacing operation may have any signature.
op(.., Type, ..)	Here, the replacing operation may have any signature, but the pattern needs a Type object for execution.

19.3.3. Composition Binding Specification

Theme/UML defines a composition relationship to support the specification of how different themes may be integrated to a composed output, and UML defines a Binding relationship between template specifications and the elements that are to replace those templates. UML restricts binding to template parameters for instantiation as one-to-one. Theme/UML extends UML's notion of binding and includes a bind[] attachment with the composition relationship. This attachment defines the (potentially multiple) elements that replace the templates within the crosscutting theme. Ordering of parameters in the bind[] attachment matches the ordering of the templates in the pattern's template box. Any individual parameter surrounded by brackets {} indicates that a set of elements with a potential size > 1 replaces the corresponding template parameter.

In Figure 19-4, all classes within S1 are replacements for pattern class tracedClass, with every operation (denoted by {*}) in each class (in this example, just S1.X) supplemented with the pattern behavior specified for tracedOp(..). Where specific elements from classes replace templates, they may be explicitly named.

Figure 19-4. Specifying binding for composition.

19.3.4. Composition Output

As illustrated in Figure 19-4, a composition relationship's bind[] attachment may specify multiple replacements for pattern classes and template operations within those classes. Where multiple replacements are specified for a pattern class, the pattern class's properties are added to each of the replacement classes in the output theme. For example, in Figure 19-5, class X has class tracedClass's properties. Where multiple replacements are specified for operations, each operation is supplemented with the behavior defined within the pattern theme. Non-template-parameter elements (such as non-pattern classes) are added to each result scope once. Class trace is a non-pattern class defined in the trace theme (see Figure 19-2), and it therefore appears in the output theme.

Figure 19-5. Output from composition with TRace theme.

Wherever a pair of operations has been defined (e.g., op() and _op()) and referenced within the same scope in a theme (that is, inside the same pattern class), and one is a template parameter for that class, composition applies merge operation semantics. For each operation substituting the template operation, each reference to _op() is replaced by the suitably renamed substituting operation, and a new op() operation is also defined. Each operation's delegation semantics is realized by a new collaboration as specified within the theme.

Other implications of composition relating to the theme design model not demonstrated in this example are discussed elsewhere [2]. For example, merging generalizations may result in multiple inheritance in the composed theme, where there was only single inheritance in each of the input themes. Multiple inheritance is supported in UML, and therefore the output design is considered to be well-formed from a UML perspective. Multiple inheritance can be eliminated, if so desired, through the process of flattening [26]; this process may be automated during composition.

Composition of the design themes can occur during the design phase (via a design composition tool, for example), which would be useful for the purposes of checking the semantics of the composed theme and the correctness of the composition relationships. Implementation may be based on such a composed design, but ideally, composition should be delayed until after the implementation phase, with each design theme being implemented separately and being composed afterwards. We discuss a means of delaying the composition process until after the implementation phase in Sections 19.5 and 19.6, where we map the design to Hyper/J and AspectJ, respectively.