Deciding on Theme Responsibilities


A goal for the theme approach is to arrive at multiple themes, each responsible for implementing a cohesive set of system requirements. This more or less means that while themes can implement many requirements, requirements should be implemented by only one theme. There are, of course, exceptions, and we discuss ways to deal with those exceptions both in this chapter and Chapter 6. However, in general, it is helpful to think of the theme-to-requirement relationship as one-to-many.

At the beginning of this chapter, we said that an aspect is functionality whose description within a requirement is tangled with the description of other functionality. We push this into Theme parlance and say that an aspect is a theme whose description within a requirement is tangled with the description of another theme. Requirements that are linked to more than one theme (shared requirements) are where this intertwining occurs.

It is not, however, safe to say that all shared requirements mean that one of the sharing themes is an aspect and the rest are base. There are essentially four rules to guide how to handle shared requirements. The first is, Split the requirement if possible. Some requirements are written in such a way that they can be split up so that the descriptions of the themes are disentangled.

The second is, Dominance means association. If a requirement cannot be split, and you can ascertain that it is mainly about one of the themes, then it should be associated with its dominant theme. Associating a theme with a requirement denotes that the dominant theme is an aspect, and the others referred to by the requirement are base. This rule holds only if the third rule also passes, however.

The third rule is, Base triggers aspect. If two themes are mentioned in a requirement, then the triggered theme is the aspect theme, and the triggering theme is the base. Once again, if you locate the triggered theme, then you associate the requirement with that theme. All three of the aspect-identification rules should apply for you to have located an aspect theme. There is also one final aspect-identification rule to apply once you're done sifting through your shared requirements. This is described in the section "Is the Aspect Crosscutting Enough?"

If any of these rules cannot be applied (you can't split the requirement up, and it seems to mention all themes equally, where none are explicitly triggered), you should postpone its association (postpone when all else fails). More information may arise about the system that can help decide which theme should actually be responsible for that requirement. Or, you may be able to handle postponed associations straightforwardly at design. This section talks in detail about how to assess shared requirements and how to capture the decisions that you make.

Identifying Aspects in Requirements

Aspects are revealed by requirements that describe two themes in a tangled way. These requirements are called shared requirements. Test to see if a shared requirement reveals an aspect by seeing if these rules hold true:

  • The requirement cannot be split to untangle the themes.

  • One theme dominates the requirement.

  • The dominant theme is triggered by the other themes mentioned in the requirement (externally triggered).

  • The triggered and dominant theme is externally triggered in multiple situations (perhaps as described in other requirements).

If all these rules pass, then the shared requirement has revealed the triggered theme to be an aspect. The triggering themes are crosscut by the aspect theme.


Split Shared Requirements If Possible

Looking at Figure 4-11, you can see that many requirements refer to more than one theme. These requirements essentially serve to link themes together. We call these shared requirements because they refer to two or more themes.

However, our goal for this process is to associate requirements with just one theme. We do not want functionality repeated in different themes. So, we go through each shared requirement to see if it is possible to rewrite it in order to disconnect the themes. Splitting a requirement adds new requirements to the end of the requirements list, attached where appropriate, and displays the split requirements as dashed and shaded gray.

Take, for instance, R69 from Figure 4-11: However, if a player meets a character of his or her same type, the character grants the player any crystals that it carries. Because we split the concept of meeting a character, we see that R69 is now associated with meet-sage, meet-wizard, and meet-warrior. These requirements can be split into three distinct requirements:

  • R90: If a wizard type player meets a wizard character, the wizard gives them any crystals the wizard carries.

  • R91: If a sage type player meets a sage character, the sage gives them any crystals the sage carries.

  • R92: If a warrior type player meets a warrior character, the warrior gives them any crystals the warrior carries.

Splitting up R69 would result in R90 being linked to meet-wizard, R91 being linked to meet-sage, and R92 being linked to meet-warrior.

R8, which links the join and start themes, can also be split up. It reads, Players can either initiate a new game or join an existing game. This could be made into two explicit requirements: R93: Players can join an existing game. and R94: Players can start a new game

As you can see in Figure 4-12, the split of R8 has resulted in the join theme the split of R8 has reduced overlap for the join theme to just R36, and the R69 split has greatly decoupled the various meet-character themes.

Figure 4-12 shows the following change:

  • split R8 into R93 and R94, and R69 into R90, R91, and R92 (shown in expansions). R8 and R69 are still shown in the view, but their outlines are now dashed, and their nodes shaded gray.

Identify Aspect Themes

After ensuring that a shared requirement cannot be split to untangle multiple themes, there are three rules to apply to see if the requirement reveals an aspect. The first rule, dominance means association, means that the theme that a requirement is most "about" (or is dominated by) is the one that may be the aspect. The second is the base-triggers-aspect rule, which means that if two themes are mentioned in a requirement, the one that is being triggered is the aspect, and the one responsible for the triggering is the base. The third is the crosscutting-enough test, which states that only behavior triggered in multiple situations is an aspect. After all those rules pass, you can associate the requirement with the aspect theme.

Dominance Means Association

As discussed above, the first line of defense for shared requirements is applying the rule, Split up if possible. However, you may be faced with a requirement that looks like R42: Energy is gained by two units when they find a crystal upon entering a location. This requirement refers to two themes: enter-location and track-energy. In trying to split this requirement, we could identify the enter-locationrelated information and add a new requirement to the end of our list that reads Players may find crystals upon entering a location. But this doesn't really help us split up R42. We would still be left with describing when energy-gain occurs, which leads us back to our original text: Energy is gained by two units when a player finds a crystal upon entering a location. No matter what rewriting is done, these enter-location and track-energy themes must be described with relation to one another.

This leads us to the next rule: Dominance means association. If one of the themes dominates a shared requirement, then the dominant theme may be an aspect.

You can try various techniques to assess whether a theme dominates a requirement. One is looking at the requirement in terms of which theme should "know about" its behavior. If you think about logging a set of method calls, you'll notice that you don't really want the logged methods to know that they're being logged. You want them to behave as normal, regardless of extra behavior attached to them. However, you do want a logging module to know what it's logging and to be able to tailor its behavior accordingly. In a requirement that stated "Log all method calls" in which there was a log theme and a method calls theme, the log theme would need to know about the behavior described, and hence would dominate the requirement. In the case of R42, think about which theme should know that energy is gained when a player enters a game location. Should the concept of entering the location know about energy gain? Or should the track-energy theme know that energy change happens in certain situations?

Another way to decide which theme is dominant is to look at the other requirements associated with each theme in order to get more of a sense of the identity of the theme. The track-energy theme contains ten requirements, six of which are shared with other themes. The requirements are shown in Table 4-2; the shared requirements are boxed in gray. Underneath each of the shared requirements is the list of themes that share the requirement. The theme considered to dominate the shared requirement is shown in bold.

Table 4-2. Track Energy Theme Requirements

R No.

Requirement Text

R21

If players do not reach their initial location within the specified time, they lose 1 energy point.

R37

Players lose energy faster while in a location: they lose energy two units per fiveminute period.

R40

Players gain 10 units of energy when the game begins.

(track-energy triggered by start)

R41

As they proceed throughout the game, their energy dissipates by one unit for each five-minute period.

R42

Energy is gained by two units when they find a crystal upon entering a location

(track-energy triggered by enter-location)

R77

Completing an errand successfully provides four units of energy to the player.

(track-energy triggered by challenge)

R80

When a player completes a physical test challenge successfully, they gain three units of energy and win a crystal.

(track-energy triggered by challenge)


All of the shared requirements in this set (R40, R42, R77, and R80) refer to gain or loss of energy in certain situations. Additionally, R21, which is not shared, refers to loss of energy. Just like our hypothetical logging theme would want to know which behaviors are being logged, it makes sense that the track-energy theme would want to know when energy is changed.

Thinking again about R42, the enter-location theme (Table 4-3) should only be concerned with location-entering behavior (as described in R38): seeing if there are other players in the location and dueling with them, or looking for crystals in the location and picking them up.

Table 4-3. Enter-Location Theme Requirements

R No.

Requirement Text

R38

If a player enters a location that has no players or characters in it, the player may pick up any crystals or magical items they see.

R42

Energy is gained by two units when they find a crystal upon entering a location.

(track-energy triggered by enter-location)

R57

Once a player enters a location, a local map is displayed on his or her handheld device.

(display triggered by enter-location)

R61

When two players meet upon entering a location, they perform a duel of rock, paper, scissors.

(duel triggered by enter-location)


From this, we decide that R42 is dominated by track-energy.

Base Triggers Aspect

The next test to see whether you've picked the right theme as the aspect is to apply the base-triggers-aspect rule. Aspect behavior is triggered by some behavior in the base. Aspect orientation allows triggering of aspect behavior to happen implicitly at trigger locations. If there were no aspect/base relationship, then the behavior would have to be triggered explicitly from the location in the base. In this case, four of the track-energy requirements (Table 4-2) mention some situation in which the track-energy behavior is triggered: reaching a location, starting a game, time passing, picking up a crystal, and so on. Since base behavior triggers aspect behavior, all themes that are representative of triggering behaviors are base, and track-energy is the aspect. In this case, we're looking at R42, in which the enter-location theme triggers the track-energy (gain) behavior.

Both the dominance and trigger rules need to pass to confidently identify an aspect theme. In R40, R42, R77, and R80, the dominant theme is track-energy, and the triggering theme is the other theme that shares the requirement. Track-energy has been determined to be an aspect of start, enter-location, and challenge.

Is the Aspect Crosscutting Enough?

Of course, every rule has exceptions, and the split/dominance/trigger rules do too. Before moving forward to design, we have to make one final check of all the themes we found to be aspects and consider whether they are crosscutting enough to warrant being designed as aspects.

Lots of behavior is triggered by other behaviorunless that triggering is crosscutting, it would be absurd to split it out. If you were to separate out every triggered behavior, you would simply have replaced all your method calls with aspect-invocation. Even the term crosscutting implies that you only want to separate out behavior that spans across the system.

It is a matter of experience to know how widely crosscutting a theme should be before you make it an aspect. To say that a theme must crosscut at least x number of themes is meaningless because the granularity of a theme is not fixed: one theme may crosscut another theme but be triggered from that theme in many places. It's also meaningless to say that if a theme is an aspect in x number of requirements, then it is crosscutting enough: one unsplit requirement might describe several situations in which a theme is triggered.

Instead, perhaps it's better to think of whether the theme is triggered in several situations. If a theme's behavior is triggered in only one place, then it doesn't make sense to make it into an aspect. The theme can still be a separate theme, but the call to the triggered behavior can be placed in the correct location in what would have been the base theme. Beyond that, it's a judgment call.

In a way, it's similar to thinking about when to refactor duplicated functionality into its own methodhow many repetitions are too many? Perhaps if the exact set of statements is used more than once, then capturing that behavior in its own method is a good idea. Maybe it's a matter of system maintenance: At what point would it be difficult to go back and refactor?

For this system, we've decided that one trigger is too few to make a theme an aspect, but two is enough. If we later find that a theme crosscuts more broadly, then dealing with one hardcoded trigger is manageable.

Let's consider an example. R61, which is shared between enter-location and duel, reads, When two players meet upon entering a location, they perform a duel of rock, paper, scissors. R61 cannot be split to isolate the themes fully. This requirement is dominated by duel and triggers duel behavior. The triggering behavior is described in the situation description of the requirement: Two players meeting (meet-player) upon entering a location (enter-location). Looking at this, duel should be an aspect of meet-player and enter-location. By the split/dominance/trigger rules, duel is definitely an aspect.

But is duel crosscutting enough? Table 4-4 shows the requirements for the duel theme. Notice that duel is only triggered in one situation (when two players meet), as described in R61. In its other shared requirements, it is either the base (of wager and pay) or there is no dominant theme present (as in R71).

Table 4-4. Duel Theme Requirements

R No.

Requirement Text

R31

Crystals can be collected by discovering them in a location in the world, interacting with characters, or dueling other players for them.

R61

When two players meet upon entering a location, they perform a duel of rock, paper, scissors.

(duel triggered by meet-player and enter-location)

R62

Each player wagers a crystal on the outcome of the duel.

(wager triggered by duel)

R63

If one player has no crystals they will wager the promise of the first crystal they find on the duel outcome, or they may wager two magical items in their possession.

(wager triggered by duel)

R70

Players may be involved in only one duel at a time.

R71

If there are both another player and an NPC in a location when a player arrives, the other player takes precedence over the NPC, and a duel occurs, followed by the challenge from the NPC.

(no dominant theme)

R72

Duel losers pay their debts immediately, or, if they cannot, their debts are automatically repaid when they become able.

(pay is triggered by duel)

R87

If more than one player has the same number of crystals and energy, then they must duel to decide which wins.

(end-game not triggered by duel)


Duel fails the final crosscutting-enough test and so is not carried through as an aspect to design. To capture this, we remove the association from R61 to duel (if we had made one) and instead postpone R61. As you will see, R61 then becomes visible, but appears dashed, in all relevant views, reminding us at design time that we need to place calls to dueling into their behavior.

Track-energy (shown in Table 4-2), however, passes the test (it is triggered in several situations, including when crystals are obtained and when challenges occur). It makes it past the final test to become an aspect.

Make the Association

We have decided that track-energy dominates R42 and that the other theme involved in R42 (enter-location) triggers track-energy, and so we associate R42 with the track-energy theme. We do the same for R40, R77, and R80.

When you associate a requirement with a particular theme, this is reflected in the relationship view by a gray arrow extending from the aspect (crosscutting) theme to the other themes referred to in the requirement (the triggering base themes). None of the links from the requirement to the crosscut themes are depicted. You can see by looking at Figure 4-13 that R42 is no longer linked to enter-location. Instead, it is linked only to track-energy. Gray arrows have also been inserted between track-energy and start, and track-energy and challenge, since those themes were mentioned in the R42.

Figure 4-13. Crosscutting and postponement relationships for the Crystal Game (display's requirements not shown).


Using the split/dominance/trigger rules, we can go through the rest of the shared track-energy requirements and see that all of these requirements are dominated by and trigger track-energy. Finally, we arrive at a track-energy theme that crosscuts the challenge, start, and enter-location themes, and that shares no requirements with other themes.

Figure 4-13 shows the following changes:

  • R40, R42, R77, and R80 are now associated with, and linked only to track-energy (shown in Table 4-2). Track-energy appears in the lower-center of the figure.

  • track-energy now crosscuts enter-location, challenge, and start (shown with gray arrows from track-energy to the other three themes).

  • R34 (when players leave game-play ot select leave-game from the options menu, they automatically lose the game and drop all the crystals they carry) associated with, and linked only to, drop, (leave-game and end-game trigger drop), visible in the top-center of the figure.

  • drop now crosscuts leave and end-game, visible in the top-center of the figure.

Chains of Crosscutting

Just because you have identified a theme as crosscutting another theme (as track-energy crosscuts enter-location), it does not mean that the crosscutting theme you chose will always crosscut others or that the base theme you chose will always be the base theme. It's fine for a theme to be crosscut and crosscutting at the same time.

For instance, examine R67 (in Figure 4-12), the requirement sitting between the challenge theme and the three meet-character themes. Although you have decided that challenge is the base theme in R77 and R80 (crosscut by track-energy), it does not mean that it will be the base theme when considering R67 (When a player meets a character, the character poses a challenge to that player). In fact, by applying the aspect identification criteria, we will associate R67 with challenge: Challenging needs to know when it happens (when two players meet), but the meet-character themes don't need to know about all the functionality to do with carrying out a challenge. So R67 is dominated by challenge; the three meet-character themes trigger challenge; challenging happens in three situations: meeting with wizards, warriors, and sages.

Associating R67 with challenge means that challenge crosscuts the meet-character themes. Now, challenge is both a base for track-energy (energy is gained or lost due to a challenge) and an aspect for the three meet-character themes. Track-energy is now an aspect of an aspect, since it crosscuts challenge (which is also an aspect). You can see this chain depicted in Figure 4-13, in which a gray arrow extends from track-energy to challenge, and three gray arrows extend from challenge to the three meet-character themes.

Looking ahead to implementation, you may wonder whether it's okay to have aspects of aspects, and whether they can be implemented that way. Later in the book, you will see that there's no problem implementing aspects of aspects. For an example of this, refer to Chapter 9, "Case Study 2: Usage Licensing." In Chapter 6, you will see the order in which chains of themes should be composed.

Figure 4-13 shows the following changes:

  • R67 is associated with challenge.

  • challenge now crosscuts meet-character, meet-sage, and meet-wizard.

Postpone Some Decisions

Some requirements are difficult to either split or associate. Take R71, for example. It reads, If there is both another player and an NPC in a location when a player arrives, the other player takes precedence over the NCP, and a duel occurs, followed by the challenge from the NPC. This describes ordering and precedence between themes rather than which theme operates on another theme or needs to know about another theme. This requirement has no dominant behavior, though there is triggered behavior. Because R71 fails one of the split/dominancy/trigger rules, we postpone it and decide how to handle its sharing at design.

When you read Chapter 6, "Theme Composition," you'll see that there are various ways of relating themes. One relationship is crosscutting, which corresponds to the aspectbase relationships we talked about in the previous section. Another is merging, in which behaviors residing in different themes are merged, sometimes including ordering specifications. The ordering considerations described in R71 might be best handled with such a construct. If so, rather than making an association decision at this point, we can postpone the decision until we create the composition specifications later in the design process. As you can see in Figure 4-13, dashed lines show requirements to be decided upon later.

Figure 4-13 shows the following changes:

  • R71 (Table 4-4) (linking duel and challenge) is postponed due to no dominant theme. This is shown with a dashed-line in the center of the figure.

  • R62 and R63 (Table 4-4) (linking duel and wager) are postponed because wager crosscuts in only one situation. This is shown with dashed lines in the center of the figure.

  • R36 (if a player's game device fails they may rejoin the game...) (linking start and join) is postponed because join crosscuts in only one situation. This is shown with a dashed line in the lower-right corner of the figure.

  • R57 (Table 4-3) (linking display and enter-location) is postponed because display crosscuts in only one situation. This is shown with a dashed line in the center of the figure.

  • R61 (Table 4-4) (linking duel, enter-location, and meet-player) is postponed because duel crosscuts in only one situation. This is shown with dashed lines in the center-right of the figure.

  • R72 (Table 4-4) (linking pay and duel) is postponed because pay crosscuts in only one situation. This is shown with a dashed line in the left-center of the figure.

  • R87 (Table 4-4) (linking duel and end-game) is postponed because the dominant theme (end-game) is not triggered by the base (duel). This is shown by a dashed line in the upper-middle of the picture.

  • R35 (dropped crystals will be rescattered throughout the game area)(linking distribute-crystals and drop) is postponed because distribute-crystals crosscuts in only one situation. This is shown by a dashed-line in the top-left of the figure.



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