Designing the Themes

By this point, you should be reasonably comfortable that you have a good set of themes identified from the requirements document. We now look at designing four of the themes that have been identified: define, check-syntax, evaluate, and log. First, though, a few words about the overall Theme/UML process.

The primary purpose of Theme/UML is to provide a means for you to consider the concerns of each theme separately. This allows you to work with separate design models for each concern. Bearing in mind, though, that all the concerns must work together in an executing system, you must at some point specify the relationships between the separate models and verify those decisions. Theme/UML, therefore, prescribes three high-level activities to add to the design process (depicted in Figure 3-11).

• Separately design the themes that were identified using Theme/Doc.

• Specify the relationships between the theme designs.

• Compose the themes for verification purposes.

Figure 3-11. Overview of the Theme/UML process.

This chapter takes you through these three steps. We begin in this section by designing the themes. As you can see in Figure 3-11, these steps are applied iteratively. Chapter 5, "Theme Design," and Chapter 6, "Theme Composition," discuss in more depth how to go about achieving these steps.

Theme Design

We look at the design of four of the themes identified: define, check-syntax, evaluate, and log. We do not have a lot to say in this book about how the internals of themes are designed; standard UML and standard object-oriented principles should be used. Except for small extensions to the UML required for designing crosscutting themes (aspects), there is no additional notation or semantics in Theme/UML for individual theme design. The main difference you will see is that when designing themes using Theme/UML, you do not have to worry about how an individual theme affects or is related to other themes.

The Define Theme

Figure 3-12 illustrates the structural design of the grammar required for expressions. This reflects the Theme/Doc representation of the specification from Figure 3-8. Of course, you are free to make detailed design decisions that result in design elements that might not be explicitly referenced in the requirements and shown in the Theme/Doc view. An example of this in the define theme is recognizing that this grammar represents a classic example for using the well-known Composite pattern, and that accessor operations (e.g., getOperand(), setOperand(), etc.) are likely to be useful. Another example is adding name and value attributes to the Variable class.

Figure 3-12. Define theme design.

In addition, each theme design will probably have a behavioral specification. Indeed, any UML model determined to be useful for specifying the design of the theme may be used here and considered part of the theme design. For the define theme, the UML class diagram is sufficient, as there is no particularly interesting behavior.

The Check-Syntax Theme

The requirements and the theme view do not thoroughly detail what "syntactically correct" means, so we take as a given that the define theme view indicates the correct syntax. As illustrated in Figure 3-13, the design has only the view of the grammar that it needs to successfully check the syntax of an expression. Notice that the hierarchy is differentwhen designing the check-syntax theme, we don't need to worry about the particulars of the grammar beyond what is needed to check the syntax. Anything else is handled by the define theme. This is the structure that emerges from designing the syntax-checking algorithm. When working through the details of the algorithm, you will determine which of the structural elements need to specify their own checking behavior. This hierarchical difference is a little contrived, perhaps, for this example, but the point is nonetheless important, as we will see throughout the book. You worry about the structure and behavior of the problem domain only as they apply to designing the theme of interest.

Figure 3-13. Check-syntax theme design.

As before, any other design models may be added to the theme design. For example, we are likely to add an interaction diagram representing the syntax-checking algorithm.

The Evaluate Theme

As before, the design illustrated in Figure 3-14 reflects the needs of evaluating expressions and does not concern itself with other issues. Only those classes that evaluation directly deals with appear in the structure diagram. We assume that the evaluate theme will probably also have a behavioral design to describe the evaluation algorithm from which the required structure emerges.

Figure 3-14. Evaluate theme design.

You might notice that since each theme was designed from its own perspective, each theme has its own view or version of the Expression hierarchies. We learn how to unify those versions when we discuss composition.

The Log Theme

The Theme/Doc individual view of the log theme (Figure 3-10) illustrates that this theme is triggered by behavior found in other themes in the expression systemin particular, the evaluation, display, and check-syntax themes. This makes it a classic example of a crosscutting theme, or aspect. However, we want to be able to design the log theme by reasoning about operations requiring logging without actually referring to them explicitly. This is where we find the first diversion from the standard UML.

The thing to keep in mind when designing an aspect theme is that some behavior in the theme is being triggered from the base themes. Notice in Figure 3-15 the dotted template box in the corner of the theme package box. In that template box, you specify a handle for the operation that triggers the aspect behavior. The triggering operation handle is a template parameter. In this case, the triggering operation is an operation being logged, and hence is called LoggedClass.loggedOp(..). At this point, you needn't worry about how to hook up this handle of the triggering operation to the actual triggering operation. You just design the behavior relevant to the theme and worry about composition later.

Figure 3-15. Log theme design.

A sequence diagram details the triggered behavior of the theme (the response to the triggering operation). For the log theme, the requirements tell us that the execution of operations in the affected themes should be logged. The requirements do not state exactly what this means, but in this case, we make a judgment call and say that before and after any operation is executed, a note will be written to a file. The actual logging behavior has no particular interest in the semantics of an operation being loggedjust that it is executing.

You can see the handle for the triggering behavior (loggedOp()) starting off the sequence in Figure 3-15. Next, the LogFile.write() method is called, which performs the actual logging of the operation. Then, since we still haven't executed the actual logged operation, we make a special call to _do_logged_op(), which represents the invocation of the actual triggering operation. When the triggering operation completes, there is another LogFile.write(), and then the triggering operation returns to the base flow of execution.

The log theme also includes a note to show how an AspectJ^[1] version of the sequence would look. Parts of the sequence diagrams that describe crosscutting behavior in a crosscutting theme map to advice in the asymmetrical separation paradigm, of which AspectJ is an implementation language. Advice is code that is executed before, after, or as a replacement for a trigger. Once again, we leave until later how to identify what the triggering operation is. For now, we concentrate on how the sequence diagram translates to AspectJ-style code.

^[1] http://www.eclipse.org/aspectj.

The log theme has become an aspect. In the aspect, you can see two pieces of advice: before and after. In each advice there is simply a call to LogFile.write(), just as there is in the sequence diagram. Notice that there's no AspectJ equivalent for the _do_loggedOp()call.That's because before and after advice imply the execution order in relation to the trigger. In AspectJ, unless you are using an around advice (discussed in later chapters), you do not have to explicitly invoke the triggering operation. When a method represented by the loggedOp()is reached in the base of the system, the before advice is called, then the loggedOp() itself, then the after advice. Chapter 7 discusses mapping your Theme/UML designs to AspectJ in more depth.