Knowing When You re Done


Knowing When You're Done

Of course, it's likely that you'll never really know when you're done with all these decisions. There are some general rules to follow though. Ultimately, you're trying to get to a point where each theme is isolated, except for either crosscutting or postponement relationships. So, if you've associated or postponed all the shared requirements and read every requirement to make sure it's associated with the appropriate theme, then you are probably done.

A good idea, though, is to look at the relationships between the final set of themes and assess whether they make sense. If they don't, then you might have some rework to do. Sometimes an absence of a relationship is as interesting as an erroneous one, such as between the start theme and the main user-interface theme, display. A look at the start theme reveals a mixing of user-interface and game-start behavior. Its requirements are as follows:

  • R10: One player is chosen to create a new game.

  • R11: To create a new game, a player chooses Begin New from the Options menu.

  • R14: Multiple games may be created in the same location at the same time and not interfere with one another.

  • R16: The host player's location at the time the game is created becomes the throne room.

  • R36: If a player's game device fails, as may happen in a power failure, the player can rejoin the game with the same number of crystals and the same game state as long as he or she restarts before the end of the game (shared with join, and postponed).

  • R94: Players can start a new game.

All of the requirements except for R11 involve game setup. R11 is a user-interface requirement. There are, in fact, several requirements that mention the user-interface element, menu:

  • R11: To create a new game, a player chooses Begin New from the Options menu (start theme).

  • R26: The new player should choose Join Existing from the Options menu (join theme).

  • R34: When players leave the game-play area or selects "leave game" from the Options menu, they automatically lose the game and drop all the crystals they carry (drop theme).

It makes sense that we would want all the menu-related behavior to be in the user-interface theme, display. So, we make a new theme, menu, and group it under display. Because of this new grouping, these three requirements become shared between display and their original themes. So, you need to check whether they motivate the promotion of display to "aspecthood." In this case, they don't. None of these requirements are clearly dominated by display, and neither do they describe a trigger for display behavior. Rather than leaving them shared, however, we postpone them to be handled at design. Drop was an aspect before, because it dominated and was triggered in R34. It remains an aspect now, and as a result of this new attachment, crosscuts display.

It's also likely that you'll reach design and realize some of the decisions that you made weren't completely appropriate. That's fine too. Moving forward is often a way to test out whether or not your choices were wise. You can continue to modify themes as long as your system is undergoing change.

For instance, you can always disassociate requirements from particular themes if you are unhappy with your decisions later on, you can unsplit requirements or themes as you see fit, and you can also group themes late in the process. The sent theme, for example, has been ignored in our process up to now. This might be because it shared no requirements with other themes, so we never really considered it. When we come to design it, however, we realize that it doesn't make much sense as a theme. Its requirements are as follows:

  • R19: Each other player is sent to a randomly chosen location.

  • R20: Players have a set amount of time to reach the location to which they are sent.

  • R23: Not more than one NPC is sent to any one location.

  • R24: NPCs are randomly sent to locations.

These actually refer to two different kinds of behavior: Setting up players with locations and initializing NPCs. These changes are easy to make: Just attach R19 and R20 to a new setup player theme and attach R23 and R24 to a new setup NPCs theme, then move forward to design with the adjusted theme responsibilities.

Though in this chapter we describe this process as a very step-by-step application, in fact, there is no particular order in which these activities should occur. Chapter 9 includes an example of how rethinking and backtracking is done during design.

Regardless of when you make your decisions about themes and their responsibilities, it's a good idea to reflect on your choice at the Theme/Doc level so that your Theme/Doc views will align with your Theme/UML designs.

A cautionary note, however: Trying to design themes that still have shared requirements is a headache. You may end up with unwanted duplication of functionality in your design. If you want to move forward with designing a particular theme, it is best if all its shared requirements have been associated one way or the other or explicitly postponed.

Figure 4-14 shows the following changes:

  • R19 and R20 are now attached to the setup players theme (left-center of figure).

  • R23 and R24 are now attached to the setup NPCs theme (left-center of figure).

  • R11, R26, and R34 are all included in the display theme (display is shown in the center of the figure; its requirements are not shown).

  • Drop now crosscuts display, since R34, is associated with the drop theme (visible as a gray line extending from the lower-center of the figure to the center of the figure).

  • The orphaned requirements and the requirements attached to display are excluded for the sake of the graph size.

Figure 4-14. Themes as used in Chapter 5, "Theme Design."


Viewless Theme/Doc

The Theme/Doc approach can be also be applied without making extensive use of Theme/Doc views. We find the graphical approach easier, but it's not the only way.

For instance, if you have a general sense of which features you will include in your system, you can read each of your requirements to see whether any describe features in a tangled way. If one does (as is probably the case) the aspect identification rules can be applied in the same way as they would if you were using the Theme/Doc views. The difference is that you'll have to manually keep track of which requirements are going to be implemented under which themes.

Theme-identification and design-planning stages can be carried out without views when necessary. A simple textual search will reveal which requirements describe which themes. The tables of requirements provided throughout the book were formed in just this way. Unfortunately, this approach doesn't handle synonyms, and doesn't help you visualize overlap between themes. But if your requirements set is small, or if you have bookkeeping mechanisms of your own, then this viewless approach might work well for you.




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