| Due date details | Overview | Step 1 | Rules, advice, guidelines | Hints, tips, and corrections Please check here occasionally! |
Turn-in forms |
Due dates: Step 1: Thursday, July 3, in quiz section. Step 2: Electronic parts on Tuesday evening, July 8; printouts and/or remaining non-electronic parts in class Wed. July 9.
Overview. You have gained fame as an accurate and fair record keeper. Officials from various types of sports and competitions are eager for your services. See if you can satisfy both the Commissioner of Baseball (high score wins, no ties possible) and the Professional Golfers Association (low score wins, scores are always at least 18). You'll write programs to help you do this. Naturally, you don't want to write two completely different systems from scratch.
Starting Code. The starting code directory contains the IRecordkeeper interface; the IContestant interface; a test class; and a little utilities class (that's where the printArray method has been moved too). The IRecordkeeper file is different from the Project 1 version. Notice that the .java files have a package statement near the beginning. Download these files and place then in a directory with the exact same name as the package name (case-sensitive). In that same directory, place all other files that will be part of this project. Try compiling. The interfaces should compile. The test case will have errors since it refers to two classes that you need to write (what are their names? Be sure to use those exact names when you implement the classes).
Step 1 (Written part) No code is involved. Do these things:
Look at the sample solution for Project 1. Draw a UML-style Class Diagram for it: one rectangle per class or interface; label each rectangle with the class name, and list method names inside the rectangle (you can skip instance variables); draw arrows to show any "implements" or "extends" relationships.
"Solve" testCase1 in the Test class. That is, write down exactly what will be "printed" (displayed on the console) when the test case runs. testCase2 doesn't have to be solved, but when you get a solution, feel free to post it on the Message Board for other to check their work against.
Draw a UML-style Class Diagram which includes all the classes you expect to use in the eventual solution. This should include the classes of the starter code; classes you write; and classes of the standard Java library that you explicitly use in your solution. "Classes" includes both classes and interfaces in this part of the instructions. (The "explicitly" means you can omit superclasses and superinterfaces of the standard Java library. For example, you should include ArrayList, but you do not need to include the many classes above it in the inheritance hierarchy.) Draw arrows to indicate "extends" or "implements" relationships; you can omit showing other kinds of relationships. For the standard library classes, you do not need to list any methods at all.
Step 2: (Code part and documentation). Write code (classes) so that the given (starter) test class will run. You may not change the Test class. Your program must compile and run with it. You can write as many classes as you need, and use whatever names you feel are appropriate -- as long as the original test class compiles and runs with your stuff. (This doesn't mean that all solutions are equally good! For example, inheritance probably will be a good design choice, and you are unlikely to get full credit if you don't use it, even if your program works perfectly). Also, write a test class of your own, with a test case of your own, and call it MyTestClass.java. It should be non-trivial, and non-trivially different from the starter test class.
For at least one of your classes, write your comments using the Sun JavaDoc format; generate JavaDoc; print the result, and turn that in with your other material. On the printout, indicate how you generated the JavaDoc. Suggestions: use the command-line javadoc command which comes with the Sun SDK; or open your project in Bluej and use its built-in tool. (DrJava doesn't currently have JavaDoc built-in, but will in the next release). [You only have to hand in one class this way, but sometimes it's just as easy to generate documentation for the whole project].
Turn in electronically all the classes to run the program, that is, needed to run the test class given and your own test cases.
Some rules: Don't change any of the starter files; you won't be able to turn in modified versions. All your classes must compile without error when we compile them (just compiling on your computer isn't enough).
As before: You get no credit if there is a single warning or error message on the compilation. We will check your program by running tricky test cases which you have never seen before. All code should be clear and commented, intended to communicate effectively with a human reader.. For now, follow the style example of the starter code and code in the textbook (not lecture or quiz code, which often is compacted to save space). To get full credit, it is not necessary to go beyond the requirements, and there is no extra credit if you do. But impressing your TA is always a good thing anyway!
This project is to be done by each student individually. Review the course and departmental guidelines for use of work not your own. In particular, any scrap of code you didn't originate yourself (or that isn't CSE143-supplied) must be acknowledged.
Some advice: Before writing a single line of code, read carefully each word of the starter code. Then reread these instructions top to bottom, word for word. Then study the starter code again. Then do Step 1. Don't dream of starting Step 2 until then. Finish Step 1 24 hours before it is due. Finish Step 2 48 hours before it is due. Don't assume the process of turning the homework in electronically will be smooth and trouble-free.
| Please read the turn-in forms carefully when they become available, including the fine print! After submitting a form, read what comes back, too. For example, if the form says "Print me", you had better print it, even if these instructions mention nothing at all about printing. | Turnin form (Now available!) |
Hints, Tips, and Corrections. Check here occasionally for major hints or corrections. Your best source of help is the Message Board, however, or office hours.
The Violet program for drawing UML class diagrams is not required; however, unless your drawing and lettering skills are very good, you should consider using it or some other type of drawing tool (such as Visio, PowerPoint, etc.). Violet was written by Cay Horstmann (Martin's favorite Java author), and is a good example of object-oriented design and programming -- the Java source is included in the download. Violet does not draw object diagrams of the type we are using in this course, however (hmm, maybe that would be a good project...)
Picking strings apart is a tedious but common programming task. Your friends who are experienced Java programmers might encourage you to use String Tokenizer classes or regular expressions. You are better off now learning the basic methods of the String class (they are more likely to be on the tests, too!). Among the dozens of methods of the String class, here are a few that are frequently useful in parsing: indexOf, lastIndexOf, charAt, substring, as well as old friends like compareTo, equals, and trim.