The initial use cases for Phish are:
The problem with an exercise like this, is that for a problem to be small enough to explore in every detail, and to code in depth, it must be so simple that there isn't much to analyze.
Nonetheless, an interesting thing has happened even with these few use cases. The visionary seems to be implying that there can be more animals than just fish. This is a subtle hidden feature which wasn't clear from the original vision statement, and which makes the project significantly more complex.
It is time to explore the difference between a new animal and a mutation of an existing animal. Furthermore, are we going to allow the user to create an arbitrary number of animals at the beginning of the game?
As we talk this through, it becomes obvious this is a powerful mechanism. We agree that each animal will have a name (e.g. blowfish, tuna or shark). Every animal will have certain characteristics and values for those characteristics. For example, there might be a characteristic "eats other fish", which can be true or false. We will need to have a strength characteristic, measured as a number. Stronger fish can kill and eat weaker ones. We may even want more complicated rules, so we can take into account strength changing over time, depending on how recently the animal has eaten, reproduced or fought.
The initial use case of setting up the animals and establishing their rules now becomes more interesting, more complicated and more challenging. In essence, we're deciding that the user can create an arbitrary set of fish to start with, and then the system will generate mutations as it goes.
The player initializes the animals. Initializing the animals may involve setting various characteristics and behavioral patterns for the various species. Whatever is involved, initializing the animal is an extension of starting the game. You can start the game without initializing the animals. When you start the game, you also set it up, deciding how many of each animal type you want to place on the board. You always set up the game when you start the game. Thus, initializing the animals sets their characteristics; setting up the game determines how many of each species to use, and starting the game launches play.
All of this is part of the Playing The Game package of use cases. Thinking about this package immediately makes us realize that there is a second package, Comparing Games. If Phish will let us keep a record of how different fish do and which combinations are strongest and most likely to survive, then each game can influence the next. Comparing games might include:
This third use case generates the next:
This clarifies what happens in setup. At setup time the game asks you to designate how many of your existing set of animals you want, and where you want to put them. Let's assemble the use cases and begin to break out their details while we name them and establish their priority:
The first and most noticeable thing is that the only actor continues to be the user. This is pretty rare, but not unheard of, especially in such a simple example.
The user can establish the rules for the set of animals at the start of the game. For each animal he can specify:
Preconditions: The game is not yet running.
Postconditions: The set of available animals is complete.
The user can save animals they create to a file.
Preconditions for saving: The user has created at least one type of animal.
Postconditions for saving: A file is created with the necessary information about the animal.
The user can import animals from previous games.
Preconditions for importing: There is a file in the correct format with information about the fish that you wish to import. You are in game initialization.
Postconditions for importing: The current set of fish has grown to include the imported fish.
The user can start a new game, choosing among the animals already recorded, and establish the starting numbers of each, as well as their starting positions on the board.
Preconditions: The game is not currently running.
Postconditions: The game is ready to run.
The user can watch the progress of the game.
Preconditions: Starting the game has completed
Postconditions: The game is running
While the game is running, the user can introduce events. In the first game, these include solar flares (increase mutations) and lightening strikes (kills some animals at random). Other events will be added to future versions.
Preconditions: The game is running.
Postconditions: The number of fish and/or the number of types of fish has changed.
The user can tell the game to stop running.
Preconditions: The game is running.
Postconditions: The game is not running.
The user can save a report of the game, so that they can compare the performance of various animals. These reports can be printed and the information exported in comma delimited form for import into other packages, such as spreadsheets. We break out Report the Game from Stop the Game, because we may well want to develop the game with the ability to start and stop before we bother implementing the ability to report on the results.
Preconditions: The game is not running
Postconditions: A report is generated
Note that some of the use cases were consolidated as we broke out the detail, and one or two were split apart. This is a natural outcome of better understanding of the use cases and their relationship to one another.
Even these few use cases fit cleanly into a couple of packages, which helps us think about their organization. Our first organization is functional, set up, run, post-game:
An alternative organization is to group together the most important use cases, and hold the less important use cases in a second folder. Whether or not we organize the folders, we do need to prioritize the use cases so that we know what to build first.
The most important use cases are Game Initialization, Start A Game, Run the Game and Stop the Game. Of secondary importance are the ability to Interact With The Game, Report On the Game and Import Animals. This tells us, right away, that we'll probably want our first iteration to provide the four primary use cases, and only subsequent iterations will take on the latter use cases.
The use case Run the Game is where all the action is, but we've said very little about it. What happens when the game is running? The different fish are moving, reproducing, eating and dying, but this raises several questions, for example:
Clearly, each fish must be responding both to internal and external stimuli. There may be an optimization, which implements all or some of these stimuli by using a timer or a central activity manager (poking each object into action in turn), but that would be an artifact of the implementation. The domain perspective says that each animal is alive and responding to the stimulation of its environment (for example, run away, you're being chased) and its own internal stimulation (eat, you're hungry).
When we get to the design phase, we'll need to return to these very important questions about the state of each of the fish. For now, let's take a step back and put this game into a business perspective.