Revisiting Evolution

In Chapter 2, we noted that evolution was particularly difficult when you are faced with adding certain functionality to the object-oriented design for the expression system. We now revisit that evolution, this time applying the Theme approach.

The additional requirements are as follows:

• R12: Check-def-use capability to ensure that all variables used are defined, and all variables defined are used.

• R13: Check-style capability to ensure that expressions conform to local naming conventions.

• R14: Mix-and-match checking capability to ensure that clients can choose a combination of check-syntax, check-def-use, and check-style to be run on their expression programs when they invoke the check tool.

• R15: Check-style and check-def-use should be logged.

Now that we have these new requirements, let's see how to absorb these changes using the Theme approach. We start by finding any new themes that arise out of these requirements, and then design and compose those themes.

Finding the Themes

We follow the first steps of the Theme/Doc process again and arrive at some additional likely themes:

• check-def-use

• check-style

• mix-and-match

Once again, we look at the relationship view to see how the addition of the new potential themes affects the system. The new relationship view is shown in Figure 3-20. Each of the shared requirements has been expanded so that we can investigate them further.

Figure 3-20. SEE relationship view, with added themes and requirements.

Choose Initial Themes

First, we look at the themes and consider whether to keep them. In this case, we chose potential themes that seemed to be of the same style as the successful ones from the previous development cycle. It is not necessarily the case that your themes will always be the same size or style. In this case, though, we are happy with the new themes that we have chosen.

Examine Shared Requirements

Once you have settled on a set of themes that you're happy with, you move on to examining shared requirements to see if they reveal aspect behavior. As before, you apply the three rules (split if possible; dominance means association; and base triggers aspect) to help identify which themes are crosscutting. If those rules fail, you may need to rework either themes or requirements to handle requirements sharing. When you can't even do that, you can postpone the decision until later, when it becomes possible to deal with it.

Identify Aspects

We've already made the decision that log dominates and is triggered in R4. But this does not mean that log will necessarily be the aspect theme when looking at its other shared requirement, R15. Rather than just restating the rules, this time we ask the questions you would ask when looking at a shared requirement.

Can it be split? First, R15 is checked to see whether it can be split. Like R4, splitting it into two requirements (check-style should be logged, and check-def-use should be logged) does not completely remove requirement sharing.

Does one theme dominate? Once again, this requirement seems to be mostly about logging and the situations in which it's used.

Is the dominant theme triggered by the other themes? Logging, the behavior dominant to R15, is triggered by check-style and check-def-use.

Based on this reasoning, we associate R15 with the dominant theme, log, and so denote that log is an aspect of check-style and check-def-use.

Figure 3-21 shows the new crosscutting relationships from log to all the checking themes.

Figure 3-21. Evolved crosscutting-relationship view.

Rework Themes and Requirements

R12 is shared between define and check-def-use. We now examine R12 to assess whether it reveals crosscutting.

Can it be split? Not really. The requirement describes check-def-use with relation to define, and there is no rewriting that will change that.

Does one theme dominate? Once again, not really. While the theme is mainly about check-def-use, the define behavior is also quite central to the requirement. Since this test has failed, it's not necessary to move on to whether one theme triggers another. Instead, we need to look closer at this requirement to see how we can handle the sharing.

Most importantly, the sense in which define is used in R12 (variables must be defined and then used) is not the same sense in which it is used in R6 through R11 (an operator is defined as a . . .). We have encountered a synonym that needs to be resolved to remove the erroneous sharing. We can split the define theme to remove the sharing. Or, we could rename the define theme to something more specifically about grammar definition. The string "is defined as" is how each operation in the SEE is described. If we rename the define theme to is defined as, the sharing will be removed. Since is defined as isn't a very good name for a theme, we can rename it to reflect its design-level name, grammar.

Figure 3-21 displays the new grammar theme and shows that R12 is no longer shared.

Postpone as Needed

R14, as is visible in Figure 3-20, is shared between mix-and-match, check-style, check-def-use, and check-syntax. On first reading, it's clear that this is actually a requirement about which themes to compose; we would not design its implementation. This requirement is a good candidate for postponement. We can then be reminded to use it later when we are choosing which of the check themes to compose together. Postponing R14 changes its outline to dashed. The links between R14 and its constituent themes are also changed to dashed. The dashed postponement is shown in Figure 3-21.

Planning for Design

You can now look at the theme views for the new themes to advise you on how to design them, and you can use this crosscutting-relationship view to plan the theme bindings.

Designing and Composing the Themes

As we showed in Chapter 2, your options for adding new functionality to existing designs using standard object-oriented techniques are limited. The solutions considered either resulted in combinatorial explosions of classes when a noninvasive, subclassing approach was taken or required invasive changes to the existing design when we tried to retrofit the Visitor pattern. Here, we show how new functionality can be added to a system without making any changes to the existing design. You can do this because each new concern (as derived from the new requirements) is considered to be a theme in its own right. The new themes can be designed separately and composed with the full design using a composition relationship.

The previous step in the Theme process of finding the themes using Theme/Doc identified three new themes: check-def-use, check-style, and mix-and-match. The first two require a design, while the third will influence the composition. There is nothing different about designing check-def-use and check-style that is specific to the Theme approach, and so we do not show their detail. Suffice to say that for each, there will be an appropriate set of design models (structural and behavioral) that captures their design without consideration of any other expression concerns. As with the initial design, design decisions such as the nature of the class hierarchies will be specific to the theme under design.

Handling composition of the two theme designs with the existing expression design is more interesting. The output from the Theme/Doc process, as illustrated in Figure 3-20, tells you that inclusion of any of the three checking themes is optional, leading to any combination of checking possible. This means we would simply include only the desired checking themes in the composition process. As these are domain concept-sharing themes, the composition relationship to be used is similar to that shown in Figure 3-16. In Figure 3-22, we show all three checking themes included in a composition relationship with another theme. As an example, this other theme is the grammar theme, but could be any other (set of) theme(s)even the output theme of a previous composition.

Figure 3-22. Composing new themes.

For illustrative purposes, we show just the Expression class from the four themes in the composition and the impact of the composition on those classes. Each individual checking theme names the operation that does the checking check(). Therefore, the match[name] tag in the composition relationship deems these operations as matching. When operations are merged, the behaviors of each of the matching operations are joined together. This means that the execution of any one of the matching operations results in the execution of all matching operations. Mix-and-match behavior is achieved because any of the checking themes included in the composition will be included in any checking process. In Theme/UML's composition process, the specification of this behavior is achieved by generating interaction diagrams realizing the composed operation as delegating to each of the matching input operations when it is invoked. The order of operation execution specified in the interaction diagram is random. As you can see in Figure 3-23, input operations are renamed to avoid a name clash. Excluding any particular kind of checking entails simply removing it from the composition specification using the composition relationship.

Figure 3-23. Composed mix-and-match.

In Chapter 6, "Theme Composition," we show how to match elements in input themes that may not have the same name, but should be considered to match. We also show how to define a specific order of execution for matching operations.

A Final Word on Evolution

A major selling point for aspect-oriented software development is the improvements gained in the software evolution process. As manifested in the Theme approach, evolution suggests that there just happen to be some more themes to be composed with other themes. The whole approach is designed to ensure that separate themes are designed from their own perspective, without reference to other themes. Therefore, whether a theme design was created during the development of an initial version of the system or for later versions of the system makes no difference to the composition process. This is true whether the themes are concept-sharing themes or crosscutting themes.