| Due date details | Overview |
|
Due dates: Electronic parts: Step 0: due in class before the midterm on Friday, August 1. Step 1: Wednesday evening, August 6, 9:00 PM. Printouts and/or written parts due in class following the electronic deadline.
Overview. Everyone loved your GameKeeper program. They
loved even more your colorful graph editor.
Just imagine how popular you and your partner would be if you could
somehow combine the
two...
Starting Code. See Project
4 for information about where to find graphed2. You can feel free to
use your Project 4 solution classes, too. Please acknowledge this
in the code ("Based on the solution by X and Y for Project 4...").
For the Gamekeeper classes, use the sample solution for Project 2 as
a starting point, or your own solution to Project 2. Please
acknowledge this in the code ("Based on the sample solution..." or
"Based on the solution by X for Project 2").
Step 0. Step 0 is due first. For reasons that will become obvious, it is described after Step 1!
Step 1. Write code which reads in a
text file, builds internal structures representing
the contestants, etc. as before -- and then draws a graph displaying
the information. There should be one (and only one) GameKeeper
node, which lists all of the contestants in alphabetical order, showing
the contestant name and win-loss record. There should be exactly
one node for each contestant, labeled with the constestant
name. There should be an edge between each pair of
contestants who have played a game (if a pair of contestants has played
more than one game, it is up to you whether there is a separate edge
for each game.) Once the graph has been drawn, any nodes or edges
that are added may be left blank or may be completely ignored -- their
proper treatment can wait until a later project, if ever.
The graph as originally drawn should be neat and legible (nodes should
not overlap, etc. However, graph layout is a difficult task --
there is a limit to what you can reasonably do in a project of of this
length.) The Gamekeeper should be of the baseball type
-- high score wins, no ties, etc (just as for Project 2).
Text file format: each line represents the results of one game, in
exactly the same format as for the text strings processed by Project 2
(yes, even including the comment). The same rules as before apply
as to what is a valid string.
Is there a catch? Yes! Internally to the Gamekeeper,
you may not use the ArrayList or
LinkedList classes. Keep the information in the form of a
linked list, implemented as
private methods in the Gamekeeper. For those methods, it would be
good practice to follow the List
interface, but you only need to implement the List methods you actually
need for this project.
Don't modify any of the graphed2 starter code files; you won't be
able to turn-in
modified versions, and the classes you do turn-in must run our our
system, which
will have the original unmodified starter files available. You
can modify the Project 2 files, and in fact you must turn in all of
them needed to run your program, including the interfaces. You
may modify the interfaces but are strongly encouraged not to do so,
except when absolutely necessary. Your
files can
have any (appropriate) names, with one exception: there must be a class
with main
named exactly BaseballRecordkeeperController.java. We will test
your
project by running
that class. Put all files that you create in the original,
default
(unnamed) package (i.e., don't include a package statement!).
Once the program is working, run it to get screen snaphots and print
them to turn in. One should be a test file which we will supply
(will be linked from the top of this page); the
other should be a test file you create to turn in. Please note
that the test file we give you will not be a very challenging one; as
always, it is important for you to test a wide variety of inputs, since
the files used for grading will cover a variety of normal and abnormal
situations.
Draw a UML class diagram which shows only the classes and interfaces
which you modify, and the classes they extend, and the interfaces they
implement. Show only extends and implements relationships.
You can omit inner classes. Turn this in with any other paper
work.
Prepare a readme.txt file which explains: briefly,
Step 0:
Before you think about code, figure out what the project is supposed to
do. A good way to test your understanding of the overall goal is
to make a fake screen snapshot. That is, just draw on a piece of
paper what you think the screen should look like after a small sample
text file has been read in and the graph displayed. Turn in such
a drawing -- that's all there is to Step 0! The drawing can be by
hand and can be very crude, as long as it gives the idea. [Note:
don't write your student IDs on this, just names and quiz section.]
Step 2: There is no Step 2; but see the "hints" below for a possible preview.
Please continue to follow Sun's coding conventions, more or less.
This project is to be done by pairs of students. Partners will be assigned by TAs, and will be different from the previous project. Working alone or changing partners is not permitted. Review the course and departmental guidelines for use of work not your own. In particular, any scrap of code which your team didn't originate or that isn't CSE143-supplied (e.g. you and some others brainstormed the idea) must be acknowledged.
Please turn in everything once per team. One UML diagram, one electronic turn-in, one this, one that, etc. -- but put both partners' name on everything. It does not matter which person does the electronic turn-in.
| Please read the turn-in forms carefully when they become available, including the fine print! After submitting a form, read what comes back, too. | 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.
You might find some of the Project 3 sample solution useful, for
example, code to read in and parse a textfile. If your parsing
code was complex or fragile, think about some approach other than the
one you took. Some people found the StringTokenizer a useful tool.
|
For a future project, we are considering something along the
following lines. There's no guarantee it will happen, but it
might give you ideas about how to shape your program.
|