Due: 2:00 P.M., Monday, 11/08/10.
Our final three programming assignments will culminate in a GUI for playing chess. It does not have to know the rules for legal chess moves, other than the same rules we have been using in our checkers playing programs: you can't move a piece from an empty square or to an occupied square and so on. The only things you need to know about chess are the kinds of pieces and how they are arranged at the start of a game. If you don't know that, I can show you, or you can find out online, for example at Chess game setup
For these three assignments, you don't need to follow the design requirements of our earlier assignments. You can choose your own packaging and organization of your classes, and your handling of user errors. Of course, your program should follow the basic principles of good design and readability that are summarized here, and your program should handle user errors in an appropriate way. The only design restrictions are:
The
program should interact with the user entirely through GUI components such as
windows, menus, buttons, text boxes and so forth. The details are up to you;
the main criterion is that the commands and responses should be easy to
understand and use. The only time the command window is used is to initiate
execution of the program.
When the program starts, the user should be presented with a window that displays the commands. These will be the same as the commands in Programs 6 and 7, modified to work with a graphics interface. This will be done in Programs 9 and 10. For this program, all you need to do is create and display the graphics objects. Quite possibly, you will want to use different objects or change their appearance in the later programs, and that's fine.
For this program, the window should display the following components:
Notice
that there is no Display command. This is because the next component will
always display the board.
Your grade will be based on how well you design and implement the code, how thorough your error handling is, on good programming practices, and on thorough testing. Coding guidelines for Java programs are posted here.
Add comment documentation to your program (all classes) 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).
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.
What
to submit:
Do not give me a copy of the javadoc.html files.
/afs/cu/class/cs242/fa10
Within this individual directory, create a subdirectory named p8. Copy only the source files and an executable JAR file into this directory, not class files or javadoc files. So, for example, if your login name was smithjd then the files TestChess.java, TestChess.jar, and any other .java files your program uses should be copied to /afs/cu/class/cs242/fa10/smithjd/p8. 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).
I should be able to run your program by downloading TestChess.jar into any folder and entering the command line
java -jar TestChess.jar
Your
grade on the program will be based on: