Theme/Doc Views and Tool SupportBefore we start going over the process of applying Theme/Doc views for aspect-oriented analysis, we're going to go over the Theme/Doc views themselves. There are three Theme/Doc views: the relationship view, the crosscutting view, and the individual view. Later (in the section "Overview of the Theme/Doc Process"), we discuss what the views are used for. Here, we mainly outline what they look like and what information they present.
Theme/Doc views are created automatically by the Theme/Doc view-generation tool. For each view we describe in this section, we also discuss what inputs are needed for the tool to construct it. Theme-Relationship ViewThe theme-relationship view shows, as you would expect, relationships between themes. Figure 4-2 shows an abstract example of a theme-relationship view (sometimes called simply a relationship view). Themes are each shown in diamond-shaped nodes. The theme's name is the label for the node. Requirements are also displayed in this view, shown in rounded-corner boxes. Requirements can be labeled with their entire text or simply with the requirement number. Most of the views in this chapter show just the requirement number. Figure 4-2. Abstract example of a Theme/Doc-relationship view.The relationship view is formed by providing a list of theme names and a list of requirements to the Theme/Doc view-generation tool. The relationship view doesn't show direct relationships between themes. Instead, it shows how themes relate to requirements. If a requirement's text contains a reference to a theme name, a link is depicted connecting the requirement to that theme. If a requirement mentions more than one theme (like Requirement 1 in Figure 4-2), then it is linked to more than one theme node. Requirements that refer to more than one theme are called shared requirements. If two themes are linked to the same requirement, we say that these themes share that requirement and that the themes are related. It will most likely be the case that some requirements do not contain any references to the themes listed. If that's the case, then those requirements are not linked to any themes in the views. We call these orphaned requirements. Later in this chapter, we talk about how to use the features of the Theme/Doc tool to resolve synonyms to help deal with orphaned requirements. Crosscutting Theme ViewShared requirements often describe crosscutting behavior. We don't get into what crosscutting behavior really is at this point, or how you might identify it. Instead, we go over how this view can represent choices you make based on shared requirements. As in the relationship view, themes are shown as diamonds, and requirements are shown as rounded boxes. These elements are present in Figure 4-3. Figure 4-3. Abstract example of a Theme/Doc crosscutting view.Generally, behavior described in requirements has to be "associated" with just one theme, which is to say that a theme is held responsible for a requirement's behavior. This is not a hard and fast rule, as you will see both later in this chapter and in the discussion of overriding behavior in one theme with behavior in another (Chapter 6, "Theme Composition"). But in the initial phases of the analysis process, we try to sort out which themes are basically responsible for which functionality in the system, so it's useful to think of it as an N:1 requirement to theme relationship. There are two choices about how to associate a shared requirement. The first is to associate it with the theme that you believe to be the "aspect" in the situation. Associations are depicted in the crosscutting view as thick gray arrows extending from the aspect theme (the one held responsible for the shared behavior) to the base theme (the one with which the requirement is no longer associated). Figure 4-3 depicts a crosscutting relationship from First Theme to Second Theme. Association relationships alter the links between a requirement and the themes to which it refers. If a requirement is associated with a theme (the aspect theme), it is shown as linked only to that theme. All the other themes to which the requirement refers (the base themes) are shown as crosscut by the aspect theme. There are no links from the theme to the base themes, though textual references to those themes are still present in the requirement. Notice that there are no links from Requirement 1 to Second Theme. The second choice is to postpone the decision about how the shared theme should be associated. Postponements are depicted in the crosscutting view with dashed lines, labeled with the requirement whose association has been postponed. You can see an example of a postponed requirement association in Figure 4-3. The dashed line linking First Theme and Third Theme denotes that association of Requirement 3 (which refers to both First Theme and Third Theme) has been postponed. Just the requirement number is used to label the postponement relationship, rather than the requirement's text. The crosscutting view and the relationship view are actually just two extremes of a continuum. The relationship view extreme includes all the relationships between themes and requirements, but it includes no crosscutting relationships. The crosscutting view extreme includes association relationships between themes and requirements, and depicts those as associations between themes. It includes no shared requirements. In practice, though, these views are integrated so that you'll likely be looking at a relationship view that has some crosscutting relationships but also some shared requirements. You can think of the relationship view as the starting point and the crosscutting view as the eventual goal. The crosscutting view is created by the Theme/Doc view-generation tool by providing four inputs: a list of themes, a list of requirements, a list of associations, and a list of postponements. Individual ViewThe individual view is the crosscutting view extreme (no shared requirements) for just one theme. Additionally, it includes key entities. The Theme/Doc view-generation tool forms the individual view by taking all the inputs given to the crosscutting view (themes, requirements, associations, postponements, and entities). An abstract example of the individual view is shown in Figure 4-4. Figure 4-4. Abstract example of a Theme/Doc individual theme view.Associations affect requirementtheme links in the individual view in the same way they do in the crosscutting view. Postponement relationships are depicted a little differently to accommodate viewing of the text of requirements rather than just the requirement label, as is usually used in the crosscutting view. Notice that Requirement 3 is depicted as a requirement shared by First Theme and Third Theme, and that dashed lines are used to indicate that its association has been postponed. Formation of the individual view has a few subtleties when grouped themes are involved. Those subtleties are discussed in the sections entitled "Viewing Base Themes" and "Viewing Aspect Themes." |