Designing Base Themes
| If we consider just the themes illustrated in Figure 4-14, our base themes for the Crystal Game are display distribute-crystals distribute-items duel end-game enter-input enter-location game-setup join leave meet-player meet-sage meet-warrior meet-wizard pay setup NPCs setup players start wager We can list these from the theme diamonds, excluding those that have crosscutting relationships to other themes, since we deal with those separately later. Kicking off our design, we know that we want to have a theme package for each base theme identified, as illustrated in Figure 5-7. Figure 5-7. Base themes identified during analysis. There are a lot of themes here, and the conceptual basis of the Theme process comes strongly into play in terms of how you manage their design. One of the strengths of Theme/UML is that you can design the requirements that are the responsibility of each individual base theme entirely from the perspective of that theme. An implication of this is that different designers can design the themes at the same time. The lack of dependencies and critical paths for the overall design may be very useful for your design plan. In the "Some Comments on Process" section of Chapter 6, "Theme Composition," we talk a little more about whether and how the designers should communicate with each other along the way. For an individual designer of any of these themes, the first step is to examine the Theme/Doc individual theme view to understand the responsibilities of the theme. After that, use your favorite object-oriented design methodology to come up with the appropriate structural and behavioral models required to capture the requirements. In this section, we choose a subset of the theme designs selected on the basis of their usefulness to illustrate composition in the next chapter. The internals of the base-theme designs are not interesting from a Theme/UML perspective, as it is standard object-oriented design. Indeed, we show you only a likely structural design for each, which is enough for the purposes of this book. The base themes we've chosen for this section are start, distribute-crystals, setup-NPC, enter-location, and duel. Game ArchitectureBefore we go any further, though, let's look at the architecture of the Crystal Game, which was an important influence on many of the design decisions. In general, we view decisions on the architecture of your system to be reasonably orthogonal to the Theme process. However, some architectural concerns may influence how you group requirements into themes in the first place. We've opted for a fairly standard architecture for mobile systemssee Figure 5-8 for an overview. Figure 5-8. Game architecture.
As you'd expect, there's the usual user-interface and logic layers. In addition, we reuse a GPS component from which we can obtain a reasonable approximation of a player's location by getting the GPS coordinates from this component. Of particular note in the architecture is the means by which players communicate with each other. Given the outdoor, mobile nature of the game, we chose a peer-to-peer (P2P) solution. In P2P systems, every party has equal capabilities (in essence, each party can be considered both a client and a server), and the communications model allows any party to initiate communications. Communication between players is event-based, which leads us to an important assumption. In designing our game logic, we assume that the underlying group communication system provides total-order, atomic multicast. From a game-logic perspective, totally ordered events mean that every player who receives events receives them in the same order. Atomic multicast means that for any event, every player receives it or no player receives it. For example, when a player takes crystals from a location, that information is multicast to the other players in the group. With total-order (and atomic) communication, no other player will be in conflict for the same crystals at the same location. Those of you who are expert in group communications for distributed systems will agree that in a mobile, wireless, P2P environment, totally ordered, atomic multicast is a tall order, but in terms of illustrating Theme/UML, it's not important. In general, the themes selected for illustration in this chapter belong in the game logic and the game communication layers of the architecture. In this base-theme section, we generally omit the behavioral designs, as you may assume standard UML behavior modeling that may, of course, be included in a theme design. In "Designing Crosscutting Themes," we include the behavioral designs, because they are interesting from an aspect-oriented design perspective. Enter-Location ThemeThe enter-location theme is responsible for handling what can happen when a player moves. The top part of Figure 5-9 illustrates the Theme/Doc individual theme view for enter-location, which tells us which requirements should be handled. R38 tells us that if the player moves into a game location (i.e., where crystals and possibly NPCs are), then he or she takes any available crystals and magical items if there are no other players or characters there. R61 tells us that there should be a duel if two players meet in a game location. Figure 5-9. Enter-location theme. Looking at R38 first, the behavior node indicates an enter-location action, and the object nodes illustrate magical items, characters, crystals, location, and player objects. If we break down this requirement into logical steps, we have the following:
The UML class diagram in Figure 5-9 illustrates the structural impact of design decisions made for each step. For example, one option for checking a mobile player's location is to have a thread periodically monitoring the player's GPS coordinates. This thread sends a newLocation() event if there is a "significant" change in the player's location. In this algorithm, the designer decides how often to perform the location check and when to consider a change significant enough to send the newLocation() event. This decision results in an active Player class that requires a relationship with the GPSComponent. Also in this design, the Game class is given the responsibility of knowing about game locations, whether there are crystals or magic items in each location, and the locations of players and characters. We don't worry about how the Game class acquires this knowledge within this theme. All we decide is that it does, and that we can query that knowledge. This decision results in the Game, Vector, Location, MagicItem, and Character classes in the design. Other decisions you might make here relate to whether an object node from the Theme/Doc individual theme view should be structurally represented in the design as a class or an attribute of a class. In this example, all are classes except the crystal element. When we think about crystals, we realize that there are no interesting characteristics relating to crystals other than how many a player has or how many there are in a location. Therefore, we decide that crystal does not merit more than a primitive type, and we make it an attribute of the Player and the Location. Though not illustrated by arrows on Figure 5-9, magical item and character map to corresponding classes in the structural design. Moving on to requirement R61, we notice that the notation in the individual view highlights that a decision as to which theme should handle the dueling was postponed. On the one hand, we know that there is a different theme, duel, which handles the actual dueling. On the other hand, this enter-location theme knows a lot about when dueling should happen because, from R38, it checks where the player is in a location and whether there is already another player there. The enter-location theme has to provide a design for this event in order to know whether the player could pick up the crystals and magic items in a game location. Recall that in Chapter 4, duel was examined to see whether it was actually an aspect of enter-location. Enter-location and duel shared an un-splittable requirement that described when dueling occurred. Additionally, enter-location triggered duel. However, since duel is only triggered in one situation (upon location entry), we could not justify making duel an aspect. Here, we see that because duel failed the final aspect-test, the trigger for the behavior in the duel theme must be placed within the enter-location theme explicitly. We therefore decide that it makes sense for the enter-location theme to "mark" when dueling should happen by adding a duel() method signature that is not designed any further. As the designer of the enter-location theme, you don't have to worry about what it means to duel. In a sense, this is equivalent to considering duel() as an abstract element, where instead of it being concretized using a generalization relationship, it is concretized during composition, as specified by a composition relationship. Chapter 6 talks more about this decision from the perspective of reconciling the likely appearance of a duel() method in both themes during composition. See Figure 5-9 for the resulting structural design of the enter-location theme. Start ThemeIn the start theme, a player has chosen to start a new game. The grouped requirements for this theme are listed in Table 5-1.
As we can ascertain from the requirements, the start theme is responsible for initializing the game, and therefore, in the design, for instantiating game and location objects. There may be many active games in a game boundary at the same time, and so we decide that we should have a GameAdmin class that handles the initial newGame() request and initializes the required game and location instances. Each game must hold instances of its own location objects, since pertinent game state (such as number of crystals) is attached to location. An interesting point to note is that two requirements are boxed in gray in the table. This denotes that the decision of where the design for the requirement should reside was postponed during the Theme/Doc process. When we look at R36, we notice that there are rules and checks associated with joining a game, so we decide to leave the whole joining process to the join theme. R11 (shown boxed in gray in Table 5-1) relates to the user interface, so we decide to leave the details of that with the display theme and assume that this theme receives a newGame() request. See Figure 5-10 for a structural design of the theme. Figure 5-10. Start theme.
Though not included here, you can also expect Theme/Doc's individual theme view to highlight the behavioral and structural entities that must be accommodated, as we saw in detail for the enter-location theme. For example, classes such as Player, Location, and Game appear in the individual theme view. There are likely to be classes that emerge from decisions you make independent of the requirements textfor example, the use of a Vector (or some other kind of collection) to hold the game locations. Your behavioral models for this theme are influenced, of course, by the requirements that are grouped for it in the theme views. Distribute-Crystals ThemeThe distribute-crystals theme is responsible for the distribution of a random number of crystals (up to ten) to a random number of random locations. See Table 5-2 for the list of requirements and Figure 5-11 for a structural design of the theme.
Figure 5-11. Distribute-crystals theme.
The requirements for distribute-crystals (and an individual theme view) result in structural entities such as game, location, and crystal. Of course, as the designer, you have to decide whether these elements should be classes or attributes of classes. Game seems like a good class because it has behavior related to distributing the crystals and knows about the game locations. Location seems like a good class because it contains crystals. Crystal is an interesting entity. Should it be a class or an attribute of Location? Similar to the decision when we came across crystals in the enter-location theme, we decide to make it as attribute of Location, as there is no interesting state or behavior for it. Finally, how you handle random-number generation to satisfy the requirements is a detailed design decision. We've encapsulated the responsibility for this into a RandomNumberGenerator class. You'll notice that R35 is shown boxed in gray in the table. This indicates that the requirement is shared between drop and distribute-crystals, and was postponed in the "Postpone Some Decisions" section of Chapter 4. We will not include the design for this requirement in this theme, but instead we leave it to the drop theme. Setup-NPC ThemeThe setup-NPC theme is responsible for distributing NPCs around the game environment. See Table 5-3 for the list of requirements and Figure 5-12 for a structural design of the theme. Each location may have, at most, one NPC, and there are a random number of different kinds of NPCs. As before, the choice of design elements is influenced by a combination of the Theme/Doc theme view's grouping of requirements, its object and behavior nodes, and detailed design decisions that you make.
Figure 5-12. Setup-NPC theme.
Duel ThemeThe duel theme handles wagering prior to the duel and the duel itself. See Table 5-4 for the list of requirements and Figure 5-13 for a structural design of the theme.
Figure 5-13. Duel theme. This design is inherently event-based, and the negotiation between the players as to what will be wagered is handled with events. Each player in the duel reveals his choice of rock, paper, or scissors by sending a duelRevealRPS(String, String) event with his name and the choice as parameters. A Player object will only evaluate this event after an event declaring its own choice has been multicast. The duel loser gives the winner whatever was on wager, or if he does not have what was wagered, records this fact for future reference. Handling old debts is outside this theme, as the Theme/Doc process has identified a pay theme. See Figure 5-6 for a structural design of the duel theme. |
EAN: 2147483647
Pages: 109