Composing the Themes

By now, we have expended considerable effort modularizing the EES design, separating concerns wherever possible. The result is a set of theme designs, each containing all and only those design elements that relate to the requirement(s) the theme represents. In other words, there is no scattering or tangling manifest in the theme designs. However, as we know, the EES software as a whole is the amalgam of all the requirements and all the themes that contain the designs for the requirements. You must consider where the modularized theme designs relate to each other and how they interact. In all aspect-oriented approaches, there must be a way to designate how the aspects relate to the rest of the system. In this section, we look at how you designate the relationships between theme designs in Theme/UML and examine the impact of these relationships.

Specify Relationship Between Themes

Theme/UML defines a new kind of relationship, called a composition relationship, that allows you to identify the overlaps in the different themes, specify how to resolve conflicts between overlapping elements, and specify how overlapping elements should be integrated in a composed model. You can see two kinds of overlap. The first is the classic aspect-oriented crosscutting, where dynamic behavior in one theme is triggered in tandem with behavior in other themes. The second category of overlap is concept sharing, where different themes have design elements to represent the same core concepts in the domain. For example, the evaluate and check-syntax themes both talk about plus operators and minus operators, and they both have an Expression class. A composition relationship can be used to handle both kinds of overlap.

Relating Themes That Share Domain Concepts

A domain concept is represented as structural and/or behavioral elements in the design. A particular class is an example of a representation of a concept. As discussed above, themes can each provide designs for the same core concepts, each from its own perspective. For instance, both the check-syntax and evaluate themes have an Expression class, but each class only has methods relevant to the theme in which it resides.

Composing elements that represent the same core concepts and that have been given the same name (the name Expression is used in both check-syntax and evaluate) is the simplest composition case. All you need to do is draw a composition relationship between the relevant themes with a match[name] tag. The elements are merged in a composed design, with matching elements appearing once. Where the matching element is a container like a class, the elements in all matching containers appear in the one composed container. The simplest case is appropriate for this expression example, and Figure 3-16 illustrates how to specify a composition of the define, check-syntax, and evaluate themes. The ThemeName["base"] tag shows that a theme called base will be the product of the merged themes.

Figure 3-16. Composition relationship: shared concepts.

Of course, the simplest case will probably not be applicable in every situation. Theme/UML has a means to match elements with different names, exclude elements that may coincidentally have the same name but are not a representation of the same concept, and specify how to reconcile any conflicts in matching elements. These capabilities are discussed in later chapters, and we also describe an integration policy based on overriding elements in one theme with elements from another theme. This is useful for late-introduced themes that contain design changes to possibly obsolete elements in the existing design.

Relating Themes That Crosscut

As described for the log design, a theme that contains a design for crosscutting behavior specifies templates as placeholders for real design elements. The log theme, for instance, has a template parameter called LoggedClass.loggedOp(..). loggedOp(..) represents the actual method that triggers the logging behavior, as described in the sequence diagram in the log theme. We now specify which operation is the real trigger for the logging behavior. When we compose the log theme with its base theme (check-syntax, in this case), we want the trigger from the base theme to actually replace the references to loggedOp(..).

To specify that replacement, you use the bind[] tag for the Theme/UML composition relationship. You can see an example of binding in Figure 3-17. In this case, we want logging to occur when expressions are checked, when they are displayed, and when they are evaluated. These operations are handled by the Expression.check() method, Expression.asString() method, and Expression.evaluate() method, respectively. So, we list each method that we're interested in logging, each of which will separately replace the loggedOp(..)template. If these methods were the only ones in the Expression class, we could have simply used used a wildcard to represent all operations using Expression.*(..). The * is a wildcard that means any string, and the (..) is a wildcard that means any parameters. See Chapter 6 for details of how more interesting bindings can be achieved with the bind annotation.

Figure 3-17. Composition relationship: crosscutting.

Figure 3-17 also shows a note containing some AspectJ code that specifies which operations are the triggers for the logging behavior. Just as with the Theme/UML bind tag, we're looking for the execution of three particular methods: (Expression.check(), Expression.asString(), and Expression.evaluate()) regardless of their parameters ((..)). In AspectJ, you use a pointcut statement to capture all those methods. A pointcut is a way to specify the points of execution at which advice behavior should be triggered. Based on this pointcut specification, when the AspectJ code is compiled, the code in the advice is woven into the execution of the program before and after every specified method.

Composed Themes

At this point in the design process, you understand the internals of individual themes and have defined where you see overlaps between themesboth in terms of how they each may have elements that describe the same domain concept and also relating to crosscutting behavior. You can apply the composition relationships to compose the design. The composed design can be helpful for checking whether the composition relationships are written as intended or can be used as a guide for implementing your system in a non-aspect-oriented language. The composed design will, of course, display the nonmodular (tangling) characteristics that this whole approach is designed to avoid.

Shared Concepts Composed

The result of composing themes as specified in Figure 3-16 is illustrated in Figure 3-18. Design elements that have the same name are deemed to relate to the same concept, and so are merged in the output. In this case, all classes except the Literal class from the define theme design have a matching class in at least one of the other two themes being composed. For each class, attributes and methods from all matching input classes appear in the composed output.

Figure 3-18. The base theme: shared concepts composed.

Note also that all of the relationships defined in the input themes are added to the output, with redundant relationships excluded and duplications added just once. An example of a redundant relationship is a generalization between two classes in one theme that has an additional layer in another theme. Say ClassA inherits from ClassC in one theme, and in another theme, ClassA inherits from ClassB, which inherits from ClassC. In this case, the inheritance relationship from ClassA to ClassC is redundant in a composed hierarchy. You will also need to watch out for circular inheritance relationships that may appear. For example, ClassA inherits from ClassB in one theme, and ClassB inherits from ClassA in another theme. Such circular relationships will have to be removed. An example of a duplicate relationship is an aggregation relationship between two classes with the same role names that has been defined in more than one input theme. Aggregation relationships that appear for a subclass and also for its superclass are not duplicates, and are each added. Composing the themes gives you an opportunity to examine the relationships between classes in the input themes, and decide which relationships should be made explicit in an implementation.

Crosscutting Behavior Composed

The result of composing themes as specified in Figure 3-17 is illustrated in Figure 3-19. You may recall that aspect themes have template parameters, specified in angle brackets (< >), that specify the triggering operation. For each triggering operation, there is a sequence diagram specified in the composed theme. When we bound the template parameter operation to the actual triggering operation (found in the base theme), we were actually telling Theme/UML to generate a new sequence diagram for each bound operation in which the template parameter behavior and structure would be replaced with the bound operations.

Figure 3-19. Crosscutting behavior composed.

For instance, one of the bindings we specified was of <LoggedClass.loggedOp()> to Expression.check(), denoting that a sequence diagram should be generated in which all occurrences of LoggedClass are replaced with references to Expression. In Figure 3-19, you can see that there is no LoggedClass shown. Instead, there is an Expression class receiving the triggering call in the sequence diagram. All design elements in LoggedClass are added to the Expression class.

Additionally, all occurrences of_do_loggedOp() will be replaced with references to _do_check(), with the triggering call changed from loggedOp() to check().

Hidden behind the Expression.check() sequence diagram are corresponding diagrams for Expression.asString() and Expression.evaluate().

Once again, you can see a code snippet to illustrate what happened in the composition. In this case, we see the check() method of the Expression class. The LogFile.write()call is made before and after the code related to checking the syntax of expressions.