ThemeDoc Views and Tool Support


Theme/Doc Views and Tool Support

Before 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.

Kinds of Requirements

Requirements can be written in various ways, from various points of view, and can describe differing units, such as features or services.

In terms of applicability to the Theme approach, this variability makes no difference. As long as requirements are written in text, the Theme approach can be applied to them.

If they are expressed diagrammatically, as use cases sometimes are, their associated text can be used in the Theme approach or might be described textually, and those descriptions can then be used when applying the Theme approach.

Some requirements are written more formally, using systems of logic. The Theme approach can be applied to requirements in this form, since each requirement will have lexically identifiable elements and behaviors.

The granularity of a requirement can be arbitrarily chosen. Typically, in natural language texts, a single sentence is treated as a requirement. But paragraphs might also be a natural choice. Really, any block of text (regardless of its grammar) can be set as a requirement. The Theme approach allows for certain flexibility in this because it supports requirement refinement: If a requirement can be split into smaller units to achieve better separation of concerns, then this becomes obvious in the early phases of analysis.


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 View

The 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 View

Shared 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 View

The 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."



Aspect-Oriented Analysis and Design(c) The Theme Approach
Aspect-Oriented Analysis and Design: The Theme Approach
ISBN: 0321246748
EAN: 2147483647
Year: 2006
Pages: 109

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net