1. Implementation:
   • Implement your design from HW5. We will go over a sample solution on 12/5. Here is a (sample solution to HW 5) .

2. Maintenance:
   • The customer requests a change: instead of having all games between user and computer, now the user decides for each player: whether that player is a human or computer. So the games can be played as: computer vs. computer, computer vs. human, human vs. computer, or human vs. human. These selections (human/computer) for each player will remain for all games of a particular run of the program. If you used method decomposition in your design, this update will be a lot easier.

     Try to do this update without redundant code. Much of your code will remain the same, e.g. the method that determines a winner, the method that updates stats for a particular player (wins, losses, ties), etc.

• Use method decomposition, as we discussed. Each method should perform only one task.
• The only code that should perform input/output is your Driver code. Blueprint classes should not print. For example, see Driver class TestGraph1.java which uses Blueprint class Graph1.java.
• Test your program thoroughly, so that you are convinced that it will work even in special/unusual cases. For the purpose of systematically testing the method that determines the winner, have an additional driver class that specifies values rather than reading them in from the user. For example, for the determineWinner method of the Rock-Paper-Scissor game, testing would include specifying that player 1 chose rock and player 2 chose rock, and that the result was a tie, etc.
• It is recommended that you write documentation before you write code. For each class and for each method, provide documentation, preferably Javadoc style (you may refer to the example documentation in Graph1 and Employee ). The documentation for each method represents a contract between the user and creator of that method; it describes what the method does in terms of its parameters; specify preconditions and postconditions; specify parameters (if any) and what is returned (if anything).
• Choose appropriate names for your identifiers.
• Indent appropriately.
• Hand in a printout of your source code (documented, of course) along with the output of your test cases. For the output, you may take screen shots, or copy the output to a file and print the file.

Method decomposition counts for 25%. Correctness counts for 25%. Test cases count for 25% of the grade. Readability counts for 25%. Follow the programming conventions/guidelines we discussed.

Hand in a printout of your source code and outputs, as described above. The assignment may be done individually or in groups of TWO according to the rules of pair programming (as we discussed) but not more than two per group (in order to receive credit for your work, do not share code between groups). If you work in a group, hand in one copy with both your names on it.