Requirements Analysis: Use Cases

Andrew Butler

There are many ways to play Freedom In The Galaxy. To start, a player of the manual game can choose to play the planetary, provencial, or galactic version of the game. Also, there are multiple gaming scenarios compatible with each version. There may not be enough time to complete each of these scenarios, but the architecture of the game could be left open to anyone writing the remaining scenarios/versions.

To keep some recognizability, the main portion of the game window should be the original map, or the portion of it that is being used. The map could be simply a .jpg image. In place of the cardboard loyalty and PDB markers, the right numbers on the planets could be highlighted by drawing over the game board numbers in a brighter color or a thicker font.

The units (characters, military units, spaceships, etc.) could be images with names under them. When clicked on, another part of the gaming window or a pop-up window could display information on that unit, such as descriptions, combat strengths, possession information, etc, similar to what is on the cards. I favor the pop-up approach. The planets and environs would also have such information-displaying functionality. The unit's image could be slightly modified under certain gaming conditions such as a character being detected.

A text box could display the status of the game, as in whose turn it is to do what, and situations that arise such as if a monster attacks or a rebellion starts. In a separate area of the window, number boxes would show the number of victory points so far and any other vital statistics.

For play, a player could simply drag desired units to other planets or areas on the board and click an OK button somewhere. In a missions phase, a player could right-click on a character and select a mission and who would be with this character in the missions group. Similarly for military combat and searches.

Here are some specific use cases and classes that are evident in each section of the game rules:
1.1--An overarching universe class would be helpful, which contains all the provinces and starsystems, which are also classes, corresponding to the version of the game being played (galactic, provencial, or star system).
1.2--A unit class, from which the character, spaceship, and military unit classes could inherit. The environ class shows up as well.
2.0...2.5--All of the things in these sections are necessary only for the manual game. In the software, the cards, for instance, will be simply attributes of their corresponding character (or other) object and do not require a class of their own.
3.0--The different use cases corresponding to a turn (which is also a use case) emerge. These include rebel move, imperial reaction, combat, imperial search, rebel mission(s) assignments, and rebel mission(s) resolution (including bonus draws). Also the same use cases with the players switched.
4.0--The phases of the turn are the same as the use cases above (for section 3.0).
5.0...5.3--These classes are mostly already discussed from section 1.1. However, the section does detail information about how these classes aggregate with each other (see class diagram below).
6.0...6.2--The character class will possess the attributes contained in the card and will be represented on the board by an image like the counter without the need for separate classes. This section does bring up the use case for detection, though.
7.0...7.3--These classes and use cases have all been discussed previously.
8.0...8.3--The planetary defense base is more likely to be an attribute of a planet than a class of its own. Detection, i.e. the act of trying to detect something, and attack are use cases corresponding to the PDB's.
9.0...9.2--Movement is a use case that has already been discussed in section 3.0. The specifics here are modifications of that use case.
9.3..9.4--This section describes details of the detection use case(s). There may be two cases, depending on whether you count being on opposite ends of the detection as two use cases.
9.5--Stacking is just a limitation on movement.
9.6--Enemy reaction has been discussed.
9.7--The detection table is an attribute of the detection use case. This table is used in the manual game, but needs not be visible in the software.
10.0...10.8--Describes military combat, which is part of the combat use case in detail, including the military combat results table, which will probably also be hidden in the software.
11.0...11.4--Describes the search use case in detail.
12.0...12.9--Describes character combat, also a part of the combat use case. There are some sub-use cases here, including wounding and capturing, that will be taken care of by either a class or, more likely, a method.
13.0...13.7--Describes missions in detail.
14.0...14.6--A possession class will be necessary since many of the things that are possessions are also units, so those things will inherit from both classes (though possibly through some way other than multiple inheritance, which would be the most obvious way.)
15.0...15.8--Planet control is simply an attribute of the planet class. Rebellion deserves a use case of its own.
16.0...16.3--The star system scenarios will affect the way the game is initially set up and the rules for play, and so deserves a set of use cases, viewed collectively.
17.0...18.0--The phases of movement are similar to those of the star system game with a few extras: interplanetary movement, which is highly related to character movement and surface military movement use cases, and they are all modifications of the movement use case in the star system scenario. Also new is orbit organization, but this is just a carboard-and-paper use case and is not necessary for the software. All the military combats can be represented using the combat use case from the star system scenario.
19.0...19.7--Describes military units and their purchase.
20.0...20.5--Describes movement and a new use case, interception.
20.6--The raking attack, as noted, is a modification of the PDB attack and probably will not need a new use case.
20.7...20.9--Describes detection and reaction as modified for the provencial version.
21.0...21.7--Describes hyperjumping, which is a sub-use case of movement, but is sufficiently complicated to warrant its own use case as well.
22.0...22.4--Describes space combat.
23.0...23.4--Describes the domino effect, which is rather independent of other use cases, as it is not present in the star system scenario.
24.0--No extra information here.
25.0...25.3--Describes sovereigns, which may inherit from unit or may be their own class or an attribute of an environment.
26.0--Describes characters' home planets and royalty status, which are simply attributes of the characters themselves.
27.0...27.3--Repairing a possession will be either an independent method or a member function of the particular possession.
28.0...28.3--Describes the gaming scenarios for the provencial game.
29.0--Vague description of the galactic game.
30.0--Describes new phases of game play, such as galactic event, taxation and imperial strategic assignment.
31.0...31.2--Describes planetary secrets, a new class.
32.0--Describes galactic events.
33.0...33.1--Describes taxation.
33.2--The imperial resource track is just a mechanism to keep track of force points, all of which can be done by the universe object in each game.
33.3...33.4--Describes the use of force points, which will be taken up by the universe object.
34.0...34.2--Describes the rebel secret base, a new class, most likely.
34.3...34.4--Describes aspects of the rebel resource track, wich will be handled by the universe object and purchasing rebel military units.
35.0...35.4--Describes imperial strategic assignment.
36.0...36.3--Describes imperial atrocities, a new use case.
37.0...37.4--Describes galactic interpretations of missions.
38.0...38.5--Describes the gaming scenario campaign for the galactic game.

Following is a list of prominent use cases and their descriptions.

Game Scenarios: This use case will be controlled mostly from the universe object and its interaction with the turn class, telling it what to next and what is and is not allowed. The particular scenario will be picked at startup.
Turn: This use case could also be a separate class keeping track of what phase the turn is in and what can be done and needs to be done. Both players take part in this use case, which delegates use almost all of the other use cases. The exact steps depend on the version and scenario being played.
Movement: This is a very general use case that covers interplanetary and interstellar travel as well as hyperjumping. The steps depend on which type of movement.
Hyperjump: A method by which units move between star systems. If a player wants to do so when it is that player's turn to do an interplanetary move, he first determines the distance (by using navigation stars), determines the navigation rating of the unit, and determines if the hyperjump is made safely using this data (see section 21.0). In the software, all this will be taken care of without calculations by the player, although a warning might be given if there is a risk involved in the hyperjump. In the end, the player may arrive safely at the destination or may be placed in drift 1 or 2.
Combat: Military combat occurs when at least two opposing units are in the same place (environ or space region) and one player declares combat. See section 10.
Missions: A mission can be declared for each character or group of characters in an environment (if they are not captured) by a player whose turn it is to do missions. There are different kinds of missions: coup, gather information, diplomacy, subvert troops, start rebel camp, start rebellion, and assassination. Each kind of mission has its own rules. See section 13
Detection: The detection routine occurs when a spaceship enters or leaves an enemy controlled planet or moves within evirons within an enemy controlled planet with a PDB up. The detection table is used to determine whether the unit is undetected, detected, detected and damaged, or eliminated by the PDB.
Taxation: The rules are slightly different for the rebel and imperial players, but basically when it is a player's turn to tax, he gathers force points from each taxable planet he owns equal to the total number of resource values of its environs. Some of these points are deducted automatically to maintain elite units and level 2 PDB's. The rest he can spend to upgrade PDB's or purchase military units (and in so doing interacts with the purchasing use case).
Purchasing: If a player has force points accumulated from taxation, they can spend them according to the rules detailed in section 19. The rules are different for PDB upgrades and military purchases.
Rebellion: If a planet's loyalty is at unrest, the rebel player may attempt to start a rebellion using that mission in the mission phase of the rebel player's turn. The imperial player can attempt a stop rebellion mission on his mission phase.

Here is a class diagram for the galactic version of this game: