Due: 10:00 AM, Monday, 9/15/08

This is a continuation of Program 2.

(a) Following the examples in class, the reading assignments, and the Java Tutorials, create a "Board" class which models a standard checker or chess board. This should be in a source file named Board.java, and your class must satisfy the interface given below; that is, you are not free to change the name, type, or behavior of the given methods. In addition, create a "TestBoard" class in a file named TestBoard.java which contains a main method that will test your Board class. For now your classes should be in the default package.

The gameboard is still the same as the one in Program 2. That is, it has the same dimensions, and only keeps track of which squares are empty or occupied.

Your grade will be based on how well you design and implement the code, on good programming practices, and on thorough testing. Coding guidelines for Java programs are posted here.

• Write a constructor with no arguments which initializes the instance of the new object with all squares empty.
• Write a constructor with one argument String[] occupied, which is a list of those squares in the board that are occupied, using the same format as in Program 2.
• The remove(int row, int col) method will remove the checker from the square (row,col).
• The place(int row, int col) method will place a checker on the square (row,col).
• The show(int row, int col) method will return a value indicating whether or not there is a game piece on the square (row,col).
• The display() method will output a picture of the board. You can use the same output as in Program 2.

You should decide how your program handles bad moves, like trying to remove a piece from a square that is empty. For this kind of error, the program should not change the board, and it could give a warning and then continue.

(b) Add comment documentation to your program (both class Board and class TestBoard) and use javadoc to extract the documentation into an HTML file. Include a javadoc comment for each class and each method. The class comment should include your name and the date (use the @author tag). Method comments should briefly describe the purpose of the method, its arguments, and what, if anything, it returns (using @param and @return as appropriate). Although these are small classes now, and this may seem like a lot of commenting, we will expand on this assignment at a later date.

The physical location of the javadoc comments is critical. A class comment must immediately precede the line containing the keyword class, and method comments must immediately precede the method.

When you have commented your source files, run javadoc to create the .html files and view them in a browser of your choice.

• Turn in a hardcopy printout of your java source files Board.java and TestBoard.java, and a printout of your test runs. Do not give me a copy of the javadoc.html files.
• All Java programs will be submitted by copying (or ftping) them to a specially designated directory in AFS. Each person in the class has a subdirectory which has the same name as your login in /afs/cu/class/cs242/fa08

  Within this individual directory, create a subdirectory named p3. Copy only the source files into this directory, not class files or javadoc files. So, for example, if your login name was smithjd then the two files Board.java and TestBoard.java should be copied to /afs/cu/class/cs242/fa08/smithjd/p3. These directories have permissions set so that no one other than yourself and Prof. Lynch can read the files. You may, of course, use whatever operating system and compiler you wish to develop your code, but the version you turn in, both hardcopy and the files submitted to AFS, must compile and run under JDK installed in the Clarkson ITL (our lab room).

• Correct execution. The program must follow all the specifications above. The hardcopy of your program's execution should clearly demonstrate that it does. You may want to turn in hardcopy of more than one execution.
• Correct implementation. The program must follow all the design requirements above, in particular the interface of the Board class.
• Error checking. You have to figure out what kinds of errors your program should check for, and how it should handle them. The hardcopy of your execution should include examples of these error handling capabilities.
• Readability of the code: commented and well-structured, so that it is clear what the code is doing. Use an accepted programming style. The style of the text is fine, or you can follow the Code Conventions. Whatever you do, be consistent.
• Appearance of the output. At this point, we haven't covered any of the ways to generate really nice looking output, but the display method should produce a picture of the board with all the rows and columns lined up nicely, and any error messages should be well-formatted and easy to read.
• Timely submission of your program. All hardcopy must be turned in by the deadline. Late programs will not be accepted. Printouts submitted electronically will be ignored.
• Plagiarism (copying all or part of anyone else's code) is a serious infraction of Clarkson regulations; the penalty is a grade of 0 for the first infraction, a final grade of F for further infractions.