Knowing When You're DoneOf 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:
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:
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:
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:
Figure 4-14. Themes as used in Chapter 5, "Theme Design."
|