COMP 303 Software Development - Fall 2011: Milestone 1

Requirements

1. Import the project stub, reformat it in your agreed upon group programming style, and check it into your group svn directory.
2. Now, design and implement code to provide a working game. You should include the following basic features:
   • Invocation should be as implied by the command line parameters described in the stub code. You may add new options, but not remove options.
   • Board configurations can be specified and read in from a given (or default) Layout/* file. Your code should work for any provided layout of tiles (you can assume the layout file itself is well-formed). Note that your code will will be tested with layouts other than the ones provided in the project stub.
   • You can graphically present the initial board state, and update the presentation as the game is played. Your GUI design and use should result in a responsive and intuitive interface.
   • The player can quit or start a new game at any point. You do not need to implement the hint button for this milestone.
   • You can (using appropriate API calls) distinguish tiles which are on the board from ones eliminated, and within the former you can distinguish between exposed tiles and unexposed tiles.
   • The player can play the game. A tile can be selected by clicking anywhere on the exposed surface of the tile, and a matching pair of selected tiles is removed as soon as the second tile is selected. The state of being selected is visible to the player. Note that you must ensure rational behaviour if the user does not act as expected (clicks on an unexposed tile, etc.).
   • An empty board must be detected, and result in the game declaring a win state.
   • A deadlocked board (no matches left but board not empty) must be detected, and result in the game declaring a lose state.
   • Reaching win or lose must be visually apparent to the player. No user action should be possible after winning or losing other than to quit or start a new game.
3. All code must be well documented with javadoc.
4. You must incorporate (extensive) unit testing into your project. All important game behaviour and all significant methods should have associated unit tests. All tests must be linked from a class named Milestone1Test.java to make it easy to run all of them as a single suite.

What to hand in

1. An exported project in a zip or tar.gz file. This must include all files necessary to build and run your project, as well as all javadoc output.
2. A 1--2 page document describing your design. This should include components:
   1. a Class diagram showing the major classes and their relationships.
   2. a sequence diagram illustrating control flow when a user selects a pair of matching, exposed tiles and these tiles are removed from game-play without terminating the game.
   3. a brief description of the specific contributions of each group member.

Evaluation

1. Code is well documented, clear and uniformly structured.
2. Code provides the functionality listed above.
3. Code is correct and does not exhibit bugs or other failures. Note we may apply tests of our devising (ie outside of your unit tests).
4. Code is well-designed following the principles discussed in class.
5. Unit tests provide extensive and relevant coverage of potential bugs and problems.
6. The document supplied includes all components, correctly and cleanly expressed.