Overview of Designing with ThemeUML

Overview of Designing with Theme/UML

Having gone through the Theme/Doc process, you have a good idea of where to start with designing your system, as each individual theme-view maps to a Theme/UML theme. Most of these themes are likely to be base themes, and some will be crosscutting or aspect themes. The primary strength of the Theme approach is that it allows a designer to work with individual themes in the system separately, considering only those design elements that are relevant for the theme at hand. As illustrated in Figure 5-1, here's where you use your standard UML modeling process to come up with the Theme/UML designs. In addition, there are some extra things to think about when you design aspect themes, relating to capturing the crosscutting behavior that happens as a result of triggers that are external to the aspect theme.

Figure 5-1. General view of the design process.

Let's look at an overview of designing both kinds of themes.

Overview of Designing Base Themes

It is likely that you already inspect any existing analysis models for the system when you are embarking on your object-oriented designs. Similarly here, a good start for designing your base themes is to include a look at the Theme/Doc individual theme-view. This view illustrates the requirements for which the theme is responsible and highlights the behaviors and objects that the requirements describe. We use gray shadows to show how elements from the Theme/Doc views correspond to design elements in Theme/UML. From an object-oriented design perspective, objects generally map to structural design elements such as classes or attributes, and behaviors are likely to map to some methods on objects. Figure 5-2 illustrates a generic Theme/Doc individual theme view with behavior nodes illustrated as diamonds and object nodes illustrated as boxes. As the designer, you decide whether each object is a class or an attribute of a class in your model. For illustration, all objects in Figure 5-2 except object4, which is an attribute, map to different classes. You make the decision about object4 as an attribute the way you normally would in an object-oriented design: Probably based on a view that object4 has, in itself, no other defining characteristics or behavior in which you are interested.

Figure 5-2. Mapping individual theme view to theme design.

You may notice that Figure 5-2 also contains some structure and behavior that are not directly mapped from nodes in the Theme/Doc individual view. We included these to illustrate that you may require supporting design elements to capture low-level design of the system. Such design elements may emerge, as you'd expect, because of the particular environment you are working on or because of more technical system concerns that are not directly manifest at requirements level.

Another way to think of the design of a base theme is as a standard UML package. In it, you have structural models such as a class or object diagrams, and behavioral models such as sequence diagrams or state machines, and so on. Though we stereotype UML's package with a stereotype called ABthemeBB, there really is no conceptual difference between the two. As illustrated in Figure 5-3, each separate theme package holds all the relevant design models to capture the design of the individual theme responsibilities.

Figure 5-3. Base theme designs.

When you are designing any individual theme, you are using standard UML. You should use the same object-oriented development methodology that you are comfortable with for determining which structural and behavioral design elements best capture the set of requirements for which the theme is responsible. These requirements are clearly listed in the Theme/Doc views. Of course, for most, if not all, systems, the same domain concepts come into play for lots of different themes in the system. You would probably notice fairly quickly that in our Crystal Game, the notion of a "player" is relevant in lots of placesfor example, when the game is being set up, when crystals are found, when a duel happens, and so on. Without giving too much away, you might therefore expect a class called Player to appear in a number of different themes, and you would be rightit does. You should not concern yourself with this apparent duplication when you design the individual view. If your requirements for the individual theme talk about players, then have a Player class if it makes sense. Bear in mind that you are designing the theme from the perspective of its own requirements, with the design in other themes containing specifications for such elements as players designed from their own perspectives. How you compose themes containing such elements is addressed in the next chapter.

Overview of Designing Aspect Themes

Where you'll start to see something new in this chapter is in the design of crosscutting themes. As with base themes, crosscutting themes may also share structural and behavioral concepts with other themes, and in addition (and here lies the difference), they may define behavior that is triggered by behavior in another theme. As illustrated in Figure 5-4, the extra things you need to think about for aspect themes relate to this triggered behavior. First, you should identify where triggered behavior needs to be modeled, and capture the triggers as templates (of which, more later). You will then be able to model the crosscutting behavior relative to those templates, and indicate whether there are control flow restrictions associated with the triggers. Of course, you will use your standard UML design process again for any other structure and behavior not impacted by the triggered behavior.

Figure 5-4. General view of the aspect design process.

The individual aspect-theme views indicate where triggering occurs. Figure 5-5 illustrates a generic Theme/Doc individual aspect-theme view with some of the behavior nodes and object nodes filled in with dark-gray, indicating that they are all found in other themes. More explanation of the grayed-out nodes is provided in the "Planning for Design" section of Chapter 4.

Figure 5-5. Mapping individual aspect-theme view to aspect-theme designs.

Nongray structural nodes (e.g., the shadowed object1 and object5 from Figure 5-5) and nongray behavioral nodes with no link to a gray behavioral node (e.g., the shadowed behavior3 from Figure 5-5) are conceptually the same as for base themes, and you should design them using a similar process. As for gray-filled object nodes (e.g., object2, object3, and object4 from Figure 5-5), at this stage you should include a minimal specification of them in your design, because you will need to refer to them in the design of this aspect. Bear in mind that you expect that they are found in other themes, and so you needn't be too concerned about capturing information about them other than as much as you need to for the aspect. Indeed, this is true for all theme designyou specify only what you care about to capture the requirements for which the theme is responsible.

Gray arrows in Theme/Doc views indicate crosscutting; this is where aspect themes get interesting. These arrows extend from triggered aspect behavior to their trigger (a gray node). This brings us to the first change to the UML with Theme/UML. We need a way to talk about the triggering behavior in other themes without explicitly referring to it. While the gray-filled behavior nodes do indicate what that behavior is, we don't want to couple the design of the aspect with the base, triggering behaviors. To this end, we extend UML's notion of templates to allow you to reference those design elements that are outside the crosscutting theme. You can then refer to the template name as the trigger to initiate the crosscutting behavior to be defined within the aspect. You also need a way to express when the actual triggering base behavior should happen. As illustrated in Figure 5-5 for op1(), within a sequence diagram, you can prepend _do_ to the template name to indicate its execution relative to the crosscutting behavior.

The overall aspect-theme design is similar to the overall design of a base theme, except that some of its behavior is triggered by behavior in other themes that is referenced using templates. Figure 5-6 illustrates an aspect-theme design as a standard UML package with the usual structural and behavioral models and just one notable difference. Templates are listed in a dotted box in the top right corner of the theme package box, with a sequence diagram for each template grouping in the box.

Figure 5-6. Aspect-theme designs.

It's important to note that it is perfectly normal to have other behavioral models within the aspect theme that are not triggered by other themes. The requirements for the theme are grouped in terms of encapsulating a concern or feature of the system, not by trying to encapsulate only triggered behavior.

We now move on to the design of the Crystal Game, first with examples of concept-sharing themes designed using standard UML, then with examples of designing crosscutting themes.