- Software Development and the Object-Oriented Paradigm
- The Case for Aspects
- What Is an Aspect?
- Why Consider Aspects in Analysis and Design?
- Aspects and Other Concerns
- The Theme Approach
- Applying the Theme Approach
- Theme: Symmetric or Asymmetric?
- Fitting Theme into Your Existing Development Process
- What About Implementation?
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Applying the Theme Approach
The Theme approach is made up of two portions: Theme/Doc, which is a set of heuristics for analysis of software requirements documentation, and Theme/UML, which is a way to write themes (both aspects and base) as UML. In this section, we present a high-level overview of the activities involved in applying the Theme approach. These activities are depicted in Figure 1–7.
)
Figure 1–7 High-level view of the Theme approach activities.
Analyzing Requirements with Theme/Doc
At the requirements level, themes are "responsible" for certain functionality described in the requirements document. Themes at this point are, essentially, named subsets of requirements.6
Theme/Doc (which stands for Themes in Documentation) is the part of the Theme approach that assists in identifying themes in requirements documents. It also provides heuristics for identifying which of those themes are crosscutting, or aspects.
The Theme/Doc analysis process has two main activities: (1) identifying the main themes in your system, and (2) determining whether the responsibilities of a certain theme mean that it should be modeled as an aspect. You interleave these two activities (theme identification and aspect identification) to plan for design or accommodate changes as your system evolves.
Starting Out
The process begins with determining an initial set of themes. These might be just a set of concerns you think seem important at first glance. Or, if you’ve already applied a requirements analysis approach and have a set of features or concerns readily in mind, then using those might make sense.
The Theme/Doc tool provides graphical depictions of relationships between requirements and themes. Figure 1–8 shows a stylized Theme/Doc view. You can see in the figure that diamonds represent themes and rounded boxes show the text of a requirement. If a requirement’s text mentions a theme’s name (or any term considered its synonym), it is linked to that theme. Unless at some point later in the process you sever the link, the theme is responsible for that requirement. For instance, both requirements attached to the transfer theme in Figure 1–8 mention transfer, so they are linked to it in the view.
)
Figure 1–8 Stylized Theme/Doc relationship view.
Theme Identification
The theme identification activity involves iterating over the themes until you have a set you think makes sense. This process involves looking at the responsibilities of each theme to see whether, together, they represent a coherent set of behavior.
Aspect Identification
To identify aspects using the Theme approach, you look for tangling in the requirements. Two themes are tangled if they share a requirement. You can see an example of a shared requirement in Figure 1–8. The shared requirement mentions both transaction handling and transfers.
If two concerns are described together in a requirement, their responsibilities may be tangled. However, identifying tangling alone is not enough to identify an aspect. To locate an aspect, you ask several aspect identification questions about the shared requirement:
Can the requirement be split up to isolate themes? If it can, you could rewrite the requirement to better divide responsibilities between themes. The shared requirement in Figure 1–8 could not be split up and still remain an actual sentence.
Is one theme dominant in the requirement? If so, then the dominant theme should likely be responsible for that requirement rather than the requirement being shared between themes. Transaction handling dominates the shared requirement in Figure 1–8, since the requirement mainly talks about when transaction handling is needed.
Is behavior of the dominant theme triggered by the other themes mentioned in the requirement? If so, then you have identified a trigger relationship between two themes. Transaction handling behavior is triggered by the initiation of a transfer: When a transfer occurs, transaction handling is needed and so triggered.
Is the dominant theme triggered in multiple situations? If, across the requirements, the dominant theme is described as triggered in multiple situations, then it is crosscutting. The dominant theme becomes the aspect, and the triggering themes become the base. Transaction handling is needed in different situations (for transfers, for adding interest, etc.). Transaction handling is an aspect.
As mentioned above, theme and aspect identification activities are interleaved, as newly split requirements give way to new themes and as new themes give rise to newly shared requirements. If, as they often are, the requirements are live and changing, then new themes and responsibilities for themes will arise after you’ve moved on to design and implementation. Design and implementation may also cause you to revisit the choices you made about theme responsibilities, so you would come back and shift things around.
Designing Themes with Theme/UML
Theme/UML allows separate design models for each of the themes identified in the requirements. It is grounded in some important steps of aspect-oriented software development: modularize, relate, and compose.
Design the Themes
From a modularization perspective, the themes that were identified using Theme/Doc can be designed separately regardless of whether one theme crosscuts another or whether there are other kinds of overlaps in the themes. Examples of overlaps other than crosscutting might be when some core domain concept (perhaps associated with particular classes), such as loan account or savings account, is relevant for multiple themes. When designing the different themes, you need not be concerned with overlaps.
You can see in Figure 1–9 that each of the banking concerns described earlier is captured in its own theme.
)
Figure 1–9 Stylized Theme/UML composition.
You will use almost entirely standard UML to design each theme from its own perspective. All the classes and methods pertinent to each of those concerns would be designed within the themes, essentially as depicted in Figure 1–4. This is a considerable strength of the Theme approach. When you want to work with a single feature or concern, you have just one place to go—the theme. Within the theme, not only is every design element relevant for the concern, you can also be sure that you don’t have to go anywhere else to find other relevant design elements. Aspect themes use a little nonstandard UML to capture parameterization of the behavior that is triggered by a base theme (shown as "triggered" in Figure 1–9).
){kind=link}
Specify the Relationships
Where you will primarily notice some differences with the standard UML is in the area of specifying the relationships between the themes and in the composition capabilities that Theme/UML defines. In all aspect-oriented approaches, there must be a way to designate how the modularized concerns relate to the rest of the system. To provide this capability, Theme/UML has defined a new kind of relationship, called a composition relationship, that allows you to identify those parts of the theme designs that relate to each other and therefore should be composed. For themes that crosscut others, this means identifying when and where in those other themes the additional dynamic behavior should occur (shown as triggering in Figure 1–9). For other kinds of overlaps, this means identifying elements in the theme designs that correspond to each other and saying how they should be integrated (shown as shared concepts in Figure 1–9).
Theme/UML also provides semantics for model composition based on the composition-relationship specification. We think of this as a verification step to allow you to have a look at the overall system design, including the composition specification, to ensure that it makes sense. Of course, the composed design will have all the poor modularization that we’ve been trying to avoid! The developer can then take a step back and revisit the separate Theme/UML models with a view to implementation.