- 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
The Theme Approach
In this book, we cover how to identify aspects in a set of requirements and how to model them in UML style designs. The methodology we introduce here is the Theme approach to analysis and design. The terminology we use is a hybrid of the symmetrical and asymmetrical paradigms. The terminology is described in Table 1–3. Grayed-out cells in the table indicate that the term is not used in the particular paradigm.
What Is a Theme?
The word theme should not be considered a synonym for aspect. Themes are more general than aspects and more closely encompass concerns as described above for the symmetric approach. We view each piece of functionality or aspect or concern a developer might have as a separate theme to be catered to in the system. You can see in Table 1–3 that a concern is described as "Some ‘kind’ of functionality in your system. This could be a feature or a type of processing," and a theme is described as "An encapsulation of a concern."
Table 1–3 Definition of Terms as Used in This Book
For example, the three banking-related features and the transaction-handling component in Figure 1–4 are four separate themes. Themes can encapsulate aspect behavior (behavior that is triggered in multiple situations), but can also encapsulate non-aspect concern functionality.
){kind=link}
At the requirements level, a theme is a subset of the responsibilities described in a set of requirements. At the design level, themes include the structure and behavior needed to carry out their requirements-level responsibilities.
Relationships Between Themes
Themes may be related to each other in the same way as requirements or features or aspects are related to other parts of the system. Such relationships may cause overlaps in the themes. There are two ways in which themes can relate: by sharing concepts and by crosscutting.
Concept Sharing
The first category of relationship is concept sharing,where different themes have design elements that represent the same core concepts in the domain (see Figure 1–5). Take, for example, the transfer funds, apply charges, and apply interest features in Figure 1–4. Each of these three features works with —all three work with and accounts, while two of them also work with accounts. Each theme contains specifications for those same concepts designed from the perspective of the theme. Another way of looking at concept sharing is to think of it, at some level, as "structure" sharing. Strictly speaking, though, we don’t consider that themes actually "share" structure because each theme will have its own version as appropriate to the feature under design. Encapsulation in this manner has the benefit of locality, where only and all relevant functionality for a concern is present in a theme.
)
Figure 1–5 Themes related by concept sharing.
Concept sharing is one category of crosscutting in the symmetric separation paradigm, as is shown in Table 1–3. Concept sharing is not discussed in the asymmetric separation paradigm. Encapsulation in this manner has the benefit of locality, where only and all relevant functionality for a concern is present in a theme.
Crosscutting
The second category of relationship is the asymmetrical crosscutting, where behavior in one theme is triggered by behavior in other themes. Transaction handling from Figure 1–4 is an example of such a theme. Table 1–3 shows that this definition is shared with the asymmetrical separation approach and is considered "one kind of crosscutting" in the symmetrical separation approach.
Throughout the book, we use the terms base theme, crosscutting theme, and aspect theme. Aspect and crosscutting themes are used synonymously and are always themes that have behavior triggered in tandem with behavior in other themes. Aspects in the Theme approach are the same as aspects in the asymmetric separation approach.
Base themes are the themes that trigger aspect themes. They might be themes that share concepts with other themes, and they might be aspects themselves and have their own base. We also sometimes talk about a base that is the result of a composition of other themes to which we then apply an aspect (see Figure 1–6).
)
Figure 1–6 Themes related by crosscutting: The base theme triggers the aspect theme.
As seen in Table 1–3, we don’t use the term core in relation to themes, since we consider a core, in the sense of the asymmetric separation paradigm, to be made up of multiple bases. In this we adhere to the symmetrical approach.