Lab Design Exercise: Rock, Paper, Scissors

This exercise is intended for you to start designing a program without worrying about how it will be implemented. Thus, without implementing any functionality, determine a set of objects that you think represent elements in the problem and can work together to implement a solution.

Submission

There will not be an official submission for this exercise, instead show your progress to a UTA during lab when you think you are finished to get feedback.

In pairs, complete the following activities:

1. Discuss high level design ideas for the RPS problem, without worrying about how your classes will get their input (either from the user or from configuration file formats)
2. Use CRC cards to find a set of classes to represent your design, focusing on the behavior and interactions between classes than their implementation
3. Use Use Cases to verify the completeness classes, by writing "code" using your candidate classes that solve some example scenarios

Note, while the examples given below are typical of experienced designers using CRC cards and Use Cases, write yours as a close to Java as possible to make sure you include enough details for us to verify your design makes sense.

Specification

Consider designing a software version of the eternal game of Rock, Paper, Scissors, RPS, that can support any number of choices and their relationships as well as allow users to create new variations. Since there are RPS Championship Tournaments, it appears that there is a strategy (beyond simply cheating), if time permits you can consider how to represent "RPS intelligence" as well.

You can assume some kind of user interface will be provided for you that allows the user to choose a file containing data about the "weapons" available for a game and displays the results of each round of the game. Assume that the chosen data file will be used populating some kind of data structure but, as much as possible, try not to think about either the file's format or a specific data structure while coming up with candidate classes and their behaviors. If that is too difficult, try envisioning two different implementations (of data structures and file formats) and then design your methods so they do not reveal the specifics of either one.

Start by writing a high-level description of how you think this problem could be solved, what kind of smart objects with useful methods could make it as easy as possible for you to write the basic game play algorithm.

Object Oriented Design

One of the strengths of object-oriented design is creating program objects that model corresponding objects from the real world when designing classes. The best way to design an effective class is to "anthropomorphize" the real world object, i.e., give it human characteristics and responsibilities, because it gives the class agency through active behaviors and thus a more defined role in the design. This distinguishes a good object-oriented design (a group of collaborating objects) from a bad one (a group of passive objects coordinated by a "manager" object).

Thus, when creating a design, focus first on each class's behavior (the methods a class implements) rather than its state (instance variables). Then for each behavior that fits with a class, give it a clear purpose by thinking about how much easier it would make the project if such a method already existed (even if you are not currently sure how to implement it). But balance that with making the behavior as general as possible to give a coder room to change their mind about the implementation when they have to write it.

Class-Responsibility-Collaborator Cards

After thinking about a problem generally, many people find CRC cards useful to describe a Object-Oriented design because they help make the objects more concrete, the logical relationship between objects explicit, it is easier to understand, evaluate, and modify a design. A CRC card is an index card (which nicely limits how much a class can do and are easy to change and move around to see their relationship visually) that helps you focus on making active objects by answering the following questions for each class:

• What active behaviors is this class responsible for (rather than get/set methods)?
  These are the public methods other objects can call on this one without knowing how it implements that behavior.
• What other classes are required to help this class fulfill those responsibilities?
  These other classes will either be passed to this object's constructor or methods, returned from a method, or created by this object itself.
  

Here is an example of developing complete CRC cards. However, in this examples, the responsibilities are given in simple English, not as a Java method signature (name, parameters, and return type). Your version must be written as a Java method signature to help provide more details about the flow of the program.

Use Cases

The following scenarios are provided to help test the completeness of your design. 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 may help to role play or draw a diagram of how your classes collaborate to complete each case. For this exercise each step, try to include both the class used and the method used to accomplish the step. To make things more interesting, pair up with another team and try to do this part using their CRC cards.

• A new game is started with five players, their scores are reset to 0.
• A player chooses his RPS "weapon" with which he wants to play for this round.
• Given three players' choices, one player wins the round, and their scores are updated.
• A new choice is added to an existing game and its relationship to all the other choices is updated.
• A new game is added to the system, with its own relationships for its all its "weapons".

Here are some examples of completed Use Cases. In these examples, the steps are given in English, not as a Java method calls. Your version should be written as a sequence of calls to only those Java methods on your CRC cards to provide more details about the flow of the program.