Exercises

1. ‚	Describe how you would apply the Ammo TFD in Figure 11.13 to an archer in an online role-playing game. Include any modifications you would make to the TFD structure as well as individual states, events, or actions.
2. ‚	Update the diagram in Figure 11.13 to account for what happens when the player picks up ammo that doesn't match the type of gun he has.
3. ‚	Create a set of baseline and minimum paths for the updated TFD you created in Exercise 2. Create data dictionary entries and write out the test case for your minimum path . Reuse the data dictionary entries already provided in this chapter and create any new data dictionary entries you need.
4. ‚	Construct a TFD for a mobile game that is suspended when the user receives a call or closes the phone's flip cover. Try to keep the number of states low. The game should be resumed once the call ends or the cover is lifted. Hint: Only one criterion must be satisfied to suspend the game, but both criteria to resume the game must be met before it actually resumes.

Answers

1. ‚	Your answer should at least describe the following kinds of changes: Change "Ammo" to "Arrows" and "Gun" to "Bow". "DropSound" would be different for the arrows (rattling wood sound) than for the bow (light "thud" on grass, "clank" on cobblestone), so need two distinct events for "DropArrowsSound" and "DropBowSound." If you have both the bow and some arrows, dropping the bow will not cause you to lose your arrows, so flow 8 should connect to the "HaveAmmo" state. It's not really possible to pick up a loaded bow, so eliminate the "GetLoadedGun" flow (9). "ShootGun" (now "ShootBow") may make more of a "twang" or "whoosh" sound if there is no arrow, so change "ClickSound" to "NoArrowSound" or something similarly descriptive. Firing a bow requires more steps than shooting a gun. You could add some or all of the states and flows for the steps of taking an arrow from the quiver, loading the arrow onto the bowstring, pulling the string, aiming, and releasing the arrow. Your reason for doing this should remain consistent with the purpose of the TFD. For example, with a bow and arrows, you could load the arrow to go to an ArrowLoaded state, but then unload the arrow to go back to HaveBowHaveArrows to make sure the arrow you didn't fire was not deducted from your arrow count.
2. ‚	Your updated TFD should at least have a GetWrongAmmo flow going from HaveGun to a new HaveGunWrongAmmo state. From that state you would have a DropWrongAmmo flow going back to HaveGun and a ShootGun flow with a ClickSound action looping back to HaveGunWrongAmmo the same way flow 3 does with the HaveGun state.
3. ‚	Using the added event and actions names from answer 2, you need new Data Dictionary entries for GetWrongAmmo , HaveGunWrongAmmo , and DropWrongAmmo . Your Minimum path must include all of the new flows, passing through the HaveGunWrongAmmo state. For Baseline path generation, you may choose the same baseline that applies to Figure 11.13 or define a different one. At some point, you need to have a derived path that get to the HaveGunWrongAmmo state and passes through the ShootGun loop. Swap your test case with a friend and check each other's results step by step. It may help to read out loud as you go along and trace the flows that are covered with a highlighter.
4. ‚	You need to represent the phone prior to playing, when the game is active, when a game is suspended while in a call and when the game is suspended with the flip closed. Be sure to have a flow that closes the flip when you are in a call. Depending on the phone, this can also end the call. Make sure you include return flows for "reversible" actions such as getting a call and ending the call, or closing and opening the flip. Also check that the game is not playable or adversely affected if you try to use it during the call. Your TFD should include states and flows similar to those shown in Figure A.5. Figure A.5: Mobile game suspension TFD.