Finding the Themes

The first step in the Theme approach is to examine the documentation of the system requirements. At this stage, you are trying to identify features and crosscutting concerns (aspects) that are described in the requirements from the EES (rewritten in Table 3-1) and also to find out which portions of the requirements document pertain specifically to those features and aspects.

Table 3-1. Expression Evaluation System Requirements
R No.	Requirement Text
R1	An evaluation capability, which determines the result of evaluating an expression.
R2	A display capability, which depicts expressions textually.
R3	A check-syntax capability, which optionally determines whether expressions are syntactically and semantically correct.
R4	The check-syntax, display, and evaluation operations should all be logged.
R5	`Expression` is defined as a `variableexpression` or a `numberexpression` or a `plusoperator` or a `minusoperator` or a `unaryplusop` or a `unaryminusop`.
R6	`plusoperator` is defined as an `expression` and a `plusoperator` and an `expression`.
R7	`minusoperator` is defined as an `expression` and a `minusoperator` and an `expression`.
R8	`unaryplusop` is defined as a `plusoperator` and an `expression`.
R9	`unaryminusop` is defined as a `minusoperator` and an `expression`.
R10	`variableexpression` is defined as a `letter` and an `expression`.
R11	`numberexpression` is defined as a `number` and an `expression`.

Finding the themes for your system has four main activities:

Choose a starting set of potential themes.
Refine the set of themes.
Identify which of the themes are aspects.
Prepare for design.

These activities are depicted in Figure 3-3, numbered and shaded in gray. In this chapter we will describe the activities linearly. However, in practice, they will most likely be intertwined.

Figure 3-3. Theme/Doc process, detailed view. Gray-shaded areas represent steps in the Theme/Doc process.

Identify Potential Themes and Entities

In object orientation, classes, or entities, are the main unit of modularity. In the Theme approach, concerns are as much a unit of modularity as entities: They represent themes, either base or crosscutting. The first step is to identify a set of concerns from your requirements (see Figure 3-3, step 1). So, rather than just sifting through our requirements looking for key entities, we also look for key concerns. In the next step, you iterate over that set, deciding whether to add, delete, split up, or group themes. As in OO, where we use at least some of the entities to motivate classes, we use some of the concerns to motivate themes. There are several ways to arrive at a starting point of themes. You may choose names of features, services, or use cases of your system if you know what those might be. In the EES, we have no use cases described and have not analyzed the requirements in terms of features or services. Instead, we scan the requirements for identifiable pieces of functionality. We identify six potential themes:

evaluation
display
determine
check-syntax
log
define

We also identify nine entities:

expression
variableexpression
numberexpression
plusoperator
minusoperator
unaryplusop
unaryminusop
plus
minus

The purpose in choosing potential themes and entities is to narrow down an eventual list of features and objects to design. Of course, this is a somewhat simplistic description of how to go about choosing those elements. Chapter 4, "Analysis," discusses in more depth how to go about choosing them.

Refine the Set of Themes

The Theme approach allows the individual design of different system features. In object orientation, not all the nouns in a requirements document are designed as objects or classes. Similarly, in the Theme approach, not all functionality is captured separately in its own theme. Some functionality is too minor to warrant separation. In this step, we set out to identify the themes of the system by identifying which of the potential themes are major enough to be modeled separately (once we get to the point of modeling). The operations that can be used for refining themes are shown in Table 3-2. The refinement step is depicted in Figure 3-3 as step 2.

Table 3-2. Operations on Themes and Requirements in Theme/Doc
Operations on Themes	Operations on Requirements
Add	Add/Split
Delete	Attach (to a theme)
Split	Associate (with a theme); selects the theme as an aspect
Group	Postpone (decision about requirement until design time)

For theme refinement, we use a Theme/Doc view called the theme-relationship view, or relationship view. The relationship view for the expression evaluator is shown in Figure 3-4. Relationship views are automatically created given a set of requirements and a set of themes. They represent requirements as rounded-corner boxes and themes as diamonds. If the name of a theme is mentioned in a requirement, there is a link from the requirement to that theme in the relationship view. R2, for instance, mentions display and so is linked to it in the view. Some requirements refer to more than one theme. R4, for instance, refers to four themes: evaluation, display, log, and check-syntax.

Figure 3-4. Initial theme-relationship view for the expression system.

As you can imagine, relationship views can become quite large if there are many requirements and many themes. We discuss how you can mitigate the size of relationship views in Chapter 4 under the section entitled "Dealing with Large Relationship Views."

In this view, we can either see requirements as labels (their requirement number), or we can enlarge them to see their content, as we have for R4. The relationship view is nonhierarchical, so even though it looks as though some themes are "higher" than others, this is just a coincidence of layout.

At this stage, what you want to take from this view is what role the behaviors play in the requirements, to determine whether they should be themes or just behavior (perhaps methods) within themes. We scan the potential themes and question whether it makes sense to have each of them as a feature in our system. If they are not feature-worthy, we remove them from our list.

The log concern makes sense as a theme: It is something that you would perhaps like to turn on or off, or at least model separately from the other actions you see in the view. A check-syntax feature makes sense for the same reason, as does a display feature. You can imagine that an evaluation feature would provide the functionality that R1 described, which is to determine results of an expression, and can imagine it as a group of classes and methods to perform that function. The define concern makes sense as a theme if you want to separate the grammar definition of the expressions from the rest of the implementation. The determine concern, however, does not seem to be as strong a potential theme as the rest. It is involved in two requirements, but in a relatively minor way, and it seems hard to imagine it as a collection of classes. It is more likely a method than a feature in and of itself. For this reason, we decide to remove determine from the list of potential themes.

Deciding which of the potential themes are too minor to be a theme is an intuitive and iterative process. This activity makes use of the operations on themes taken from Table 3-2: You may choose to remove, group, split up, or add new themes as you see fit. The changes you make are reflected in the relationship view, which may motivate you to make more changes. As usual in choosing the modules of your system, domain knowledge is helpful. Your set of themes may also continue to shift along with the development and aging of your system. It's probable that the next step in the analysis process (identifying crosscutting themes) will cause you to rethink and refine the themes you've chosen. Much more information on and examples of deciding on themes is provided in the Chapter 4 and in the case studies at the end of this book.

Identify Crosscutting Themes

As we discussed in the section "Structure of Themes," some of the themes we've chosen are crosscutting themes, or aspects, since their behavior is triggered by functionality found in other themes. The rest of the themes are base themes. This is depicted as step 3 in Figure 3-3.

You use the final theme-relationship view to help you determine which themes are base and which are aspects. This view is made up only of the remaining themes from the previous relationship view. You can see in Figure 3-4 that the determine node is no longer shown.

To identify aspects, you look for requirements that are shared between themes. R4 is an example of this, as is made clear by the fact that it is linked to more than one theme in the relationship view.

Generally speaking (though exceptions to this are discussed at length in Chapter 4, "Analysis," and Chapter 6, "Theme Composition"), requirements are "owned" by just one theme. As you can see, some requirements are already associated with only one theme. It's pretty easy to assume that whatever functionality is described in those requirements (even though you can't read it) should be provided by those themes. So, when we're designing the check-syntax theme, we know it should provide the functionality described in R3.

Shared requirements, however, represent a tangling of responsibilities and signal that we may have identified an aspect in our system. As described earlier, R4 (shown in Figure 3-5) is shared between several themes. You now have to decide whether this sharing represents an aspect-base relationship. But before jumping to any conclusions, you want to make sure that you have not encountered a vaguely written requirement that is masquerading as a shared one.

Figure 3-5. Theme-relationship view with R4 enlarged.

In fact there are three rules you apply to identify an aspect:

Splitting up doesn't work (there is no rewriting that can isolate the themes and remove sharing).
Dominance means association (associating a requirement with a theme selects that theme as an aspect).
Base triggers aspect (aspects are triggered from within base behavior).

First, we check to see whether the requirement can be rewritten into several requirements that each refers to only one theme. You can see that in this case the only possible rewriting would be to break it into three sentences that each mention log and another of the themes (a log capability that logs the evaluation activity, a log capability that logs the display capability, etc.). There is no rewriting that gets a one-to-one relationship between themes and requirements: The log feature must be described with relation to the evaluation, display, and check-syntax features. We have passed the splitting up doesn't work rule.

Additionally, the log theme "dominates" this requirementR4 mainly describes logging as opposed to the behavior of evaluation, display, or syntax-checking. Based on the dominance means association rule, the log theme is the aspect, since we would associate R4 with log.

It is clear from the requirement that these three themes trigger the log operation; logging happens at the time of syntax-checking, display, and evaluation. Once again, the log theme is the aspect due to the base triggers aspect rule.

We can now say conclusively that the log theme is appropriate as an aspect of check-syntax, display, and evaluation.

You denote that the log theme crosscuts the other three by associating the shared requirement, R4, with it. This association clips the links from R4 to the other three themes. In its place, a gray arrow indicating a crosscutting relationship is placed from the aspect theme to the base themes. These relationships are shown in a special Theme/Doc view called a crosscutting-relationship view, shown in Figure 3-6.

Figure 3-6. Crosscutting-relationship view.

There are no other shared requirements, so you can now move on to examining your themes individually and planning for design.

Preparing for Design

The individual-theme view (also called the individual view) helps determine which objects and behavior should be modeled in Theme/UML. Individual views show all the requirements connected to the theme of interest. Additionally, they include themes crosscut by the theme of interest, and depict the crosscutting relationships as shown in the crosscutting view. They also include structural components, or entities if they are specified and fed into the Theme/Doc view-generation tool. We now go over individual views for both base and crosscutting themes.

Viewing Base Themes

When we formed the crosscutting-relationship view shown in Figure 3-6, we associated particular requirements with particular themes. You may also recall that when we were picking the theme keywords, we also chose entity keywords: a set of things that might be considered participants or objects in the system. The individual-theme view is a combination of that list of keywords and the crosscutting-relationship view. Since base themes do not crosscut other themes, there will be no crosscutting relationships depicted. There may, however, be postponement relationships depicted between themes, as taken from the main crosscutting view.

Each theme can be viewed in an individual view, which shows the requirements associated with the theme, the actions (major and minor) derived from the requirements, and the entities we chose earlier. For instance, the theme view for check-syntax is shown in Figure 3-7.

Figure 3-7. Check-Syntax individual theme view.

Notice that in the theme view for check-syntax, only R3 is shown, and not the requirement that check-syntax be shared with the log theme (R4). This is because you design the check-syntax theme without any regard for the logging functionality.

From this view, you can predict some of the classes and methods needed when you design your themes. Themes and other functionality described in the requirements loosely translate into methods, and entities loosely translate into classes. You can tell that you will likely have a class representing an expression. There will probably be a method specifically related to the check-syntax behavior.

Figure 3-8 shows the theme view for the define theme. This theme is made up entirely of the structural components of an expression. Once again, this view helps you predict many of the structural entities in the design. It is likely that this theme will just define the structure of an expression, but will have no active components.

Figure 3-8. Define individual-theme view.

The evaluation theme is shown in Figure 3-9. It has two entities: result and expression. You can see that the evaluate theme shares a concept with the check-syntax and define themes: the expression entity. As we discussed before, themes can share concepts freely. In Chapter 6, we discuss how to resolve sharing conflicts and how to recombine concepts.

Figure 3-9. Evaluate individual-theme view.

Viewing Aspect Themes

Individual-theme views for crosscutting or aspect themes are a little different from those for base-theme views. As you can see in Figure 3-10, some nodes are shown in gray, indicating that these are external elements: elements that are crosscut by the log theme rather than elements that are unique or internal to it. You can see here that there actually are no elements described in the requirements that are internal to this theme. The log theme is described only in terms of how it affects other themes in the system. It will be up to the designer to determine all appropriate structure and behavior for logging.

Table 3-1. Expression Evaluation System Requirements