Structure and Relationships of Themes

The Theme approach involves identifying and designing separate themes, which are then combined to make a whole system. Themes can be thought of as analogous to features or concerns. So, in a sense, the Theme approach lets you design each feature of your system separately, and then offers a way to combine them. In the introduction, we discussed the nature of themes and how they relate to one another. We now review the nature of themes at a high level, but this time using the EES example from the previous chapter as a basis.

Themes at Analysis, Design, and Composition

Figure 3-1 depicts themes at analysis, at design, and then retangled after composition. Themes "look" different as you move from requirements to design. At the requirements level, the parts that make up a theme are fairly abstract: They are participants and actions, as described in a set of requirements. As you can see, at requirements analysis, a single theme is represented by a diamond and is linked to the description of a particular functionality from the requirements. As shown in Figure 3-1, a requirement for the EES from Chapter 2 was a feature for checking the syntax of expressions.

Figure 3-1. Themes at analysis, at design, and then retangled after composition.

At the design level, these parts are more concrete, consisting of classes, methods, and relationships between them. These parts are both structural and behavioral: the "things" and "actions" that work together to provide a feature of your system. At the design level, many classes were needed to implement the check-syntax feature, including the Expression class and all its subclasses. If the check-syntax feature was described as a theme (as depicted in the middle column of Figure 3-1), all these classes would be included in the theme. However, each theme contains only the relevant portions of the design. You'll notice that the check-syntax theme does not contain the asString() method. The classes and methods related to the check-syntax feature provide only functionality related to checking syntax.

Relationships Between Themes

Themes can relate to one another in two ways: by sharing concepts and by crosscutting. It is also possible for themes to be completely independent. This is rare; independent themes relate in no way to the rest of the system.

Concept Sharing

Different themes may have design elements that represent the same core concepts in the domain. A design element might be a particular class, method, or attribute. A concept relates to something from the domain. In the banking system, described in Chapter 1, a core concept might be a bank account. The concept of a bank account could be described by classes of varying names, such as Account, or BankAccount.

In the Theme approach, each theme describes the classes it requires from its own perspective, regardless of whether other themes also have classes that describe the same concepts. Conflicts and overlaps are resolved later, when deciding how to recombine the themes. For instance, you need an Expression class for most of the features in the system. You can see that both check-syntax and display have a version of the Expression class. When considering each theme, you include the entities and behavior needed to capture the analysis and design of that theme, regardless of whether the underlying domain concepts have also been described elsewhere. The arrow labeled "share" in the middle column of Figure 3-1 depicts that the check-syntax and display themes share concepts (the Expression class, in this case).

You can see that the composed system has merged the different Expression classes into one single class: Both the asString() method from the display theme and the checkSyntax() method from the check-syntax theme are now included in the Expression class.

Crosscutting

Themes can also crosscut one another. One theme crosscuts another if its behavior is triggered by the behavior of the other theme. While independent themes and themes that share concepts can operate without knowledge of one another, crosscutting themes require an abstract knowledge of the themes they crosscut, and they cannot operate independently. The log feature in the EES system is a good example of a crosscutting theme. The logging behavior appeared throughout the system but could not operate unless other behaviors in the system were also in operation (otherwise, what would be logged?). The arrow marked "trigger" in the middle column of Figure 3-1 shows that the log and check-syntax themes have a crosscutting relationship. The log theme is parameterized to show that it contains the triggered behavior.

Crosscutting themes are also called aspects; noncrosscutting themes are the base upon which the aspects operate.

The trigger arrow between log and the other two themes depicts that the log() method is triggered by the behavior associated with those themes. In asymmetric separation parlance, it has been woven into those methods. You can see the result of the weaving in the composed methods: log() is called before the main functionality of the asString() and checkSyntax() methods.