Design Exercise: Testing your Objects with Use Cases

This exercise is intended for you to update your Object-Oriented design based on feedback from your mentor TA and based on "testing" how well it handles situations that occur in the game. It will not be explicitly graded but, instead, serve as practice for future exercises in the course. Thus, you will get the most out of this assignment by putting in a good faith effort.

Submission

Submit a Markdown formatted plain text file, named design02_fluxx_usecases.md, to the individual portfolio_NETID repository provided for you in the course's Gitlab group.

All submissions for this course will be based on only the version of your files in the provided Gitlab repository by 3:07am ET in the morning on the day after that given on the course Calendar (so it is effectively a few extra hours grace time past midnight).

Specification

Describe pseudocode for playing the game using your new design:

• Fluxx's basic game play, where you choose a few example cards to show how they are handled
• the Use Cases given below which describes more specific scenarios

Also include updated versions of the objects and their behaviors in your design based on feedback, further thinking, or issues uncovered implementing the Use Cases.

The basic algorithm for Fluxx's "game loop" is given in the manual. After setting up the game, turns proceed like this:

1. Draw the number of cards currently required (start with Draw 1)
2. Play the number of cards currently required (start with Play 1)
3. Discard to comply with any Limit rules in play (start with no limit)
4. The game ends when a player meets the conditions of a current Goal card.

The way the different cards are played is also given in the manual.

• New Rule cards are played by laying the card face up in the center of the table. Any rule card in play that contradicts it is discarded.
• Keeper cards are played by laying the card face up in front of you.
• Goal cards are played by laying the card face up in the center of the table. Discard any previous goal card, if any.
• Action cards are played by doing whatever the card says to do and then discarding it.

There may be free actions that can be performed at any time on one’s turn, such as “Once during your turn you may take the top card from the draw pile and play it immediately.”

Start exploring your design by writing pseudocode for Fluxx's game loop algorithm using your design's objects and methods. It may be that doing this will show that you need more behaviors than you thought. It may also show you the presence of Code Smells, or indications that a better design is possible.

Use Cases

Use Cases are a proven strategy for testing the completeness of a design by describing different examples of a programs functionality that is so "easy" anyone associated with a project can do it, from programmers to users to managers. By writing the steps needed to complete each case below you will be able to see how effectively your design handles these scenarios and others will be able to better understand how deeply you have considered the basic issues. It should be clear from your pseudocode which objects are responsible for completing each part of the task, but you do not have to implement the called methods.

Test your design further by writing pseudocode for the following scenarios:

• A player plays a Goal card, changing the current goal, and wins the game.
• A player plays a Rule card, adding to the current rules to set a hand-size limit, requiring all players to immediately drop cards from their hands if necessary.
• A player plays a Rule card, changing the current rule from Play 1 to Play All, requiring the player to play more cards this turn.
• A player plays an Action card, allowing him to choose cards from the discard pile and play them.
• A player plays an Action card, allowing him to choose cards from another player's hand and play them.

Here are example "implementations" of Use Cases. However, these examples show the steps in simple English, not as a sequence of Java method calls (showing objects and data moving between methods). Write your version as a sequence of Java method calls to provide more details about the flow of information.

Some have even chosen to role play or draw diagrams of how objects collaborate to better understand a design's implications.