Due: Wednesday, February 26, 5:30 PM (in class).

Use the new version of the game package $CS680/games3.

1. Read ... about use cases and object models in Jia, pages 41-51 in preparation for Monday's class. You might also browse some of the links at http://www.cs.umb.edu/~eb/681/useCases.html.

2. The game package needs a graphical user interface. Some parts of the GUI are generic. For example, the PlayGame or Tournament driver should have a screen or set of screens that allow the user to select the game to be played and the two players.

   Some parts are specific to particular games. When the user has chosen a game, that game's window should be displayed. It should provide

   • a view of the current position
   • a way to show which move the other player has just made
   • a way to indicate (interactively) which move to make next (typing, clicking, dragging, ...)
   • a way for the user to get help
   • (other things you can think of)

   Create sketches showing what you think such a user interface might look like. You can use a software drawing tool if you like, but neat pencil and paper work is just fine (maybe better). Get yourself some colored pencils. Work on a few driver screens, a few screens for the Easy game and a few screens for the game you ported from C to Java. (The last part can be with the porting team.)

   You probably want to submit a little narrative along with your screens, telling what the user did to get from one to the next.

   Don't even think about how you might implement your design in Java. That's several weeks away and a waste of time now.

3. The PlayOneGame object is passed a Game when it's constructed. But there's no guarantee that the Game is in the right state - it might be a Game that was partially played already elsewhere. Design and then implement and test a way to prevent this from happening, either by reinitializing the Game when go is called or by throwing a suitably parameterized GameException. (Which of these is better, and why? Could you do both?)

   You should have learned by now that a good solution to this problem may require changes to other classes, or the creation of new classes or methods. Don't be shy when that's called for.

   Make sure your memo discusses your design and testing.

• screen shots (fake, of course)
• a memo discussing the PlayOneGame modifications
• the Refactoring essay