Due date details | Overview | Step 1 | Rules, advice, guidelines | Hints, tips, and corrections Please check here occasionally! |
Turn-in forms |
Due dates: Step 1: Electronic parts: Tuesday evening, July 15 9:00 PM, printouts and/or written parts due the following day in lecture. Step 2: Electronic parts on Monday evening, July 21 9:00 PM; printouts and/or remaining non-electronic parts due the following day in quiz section.
Overview. Life is clean and simple viewed from a distance, especially from above.
Starting Code. The starting code directory contains a whole bunch of files, some of them in packages. You can either simply download the .zip file containing all the starter code and unzip it, or download each file individually and place them in a directory, preserving the original directory (package) structure (case-sensitive). As you create new files for this project, be sure to place them in the proper package. Try compiling. Most of the files compile, a few won't. The errors you get on the non-compiling files are clues as to what needs to be completed. If more than a couple of files don't compile, then the package structure has been messed up; stop and get it right. Hint: don't remove any package statements from the code, and don't let IDEs such as Bluej "helpfully" do it for you.
Step 1 (mostly written part) Only a small amount of coding is involved. Do these things:
Look at the sample solution for Project 2. Draw a UML-style Class Diagram for it. In case you weren't doing so before, indicate interfaces and abstract classes differently from other classes. Include a rectangle for each library class used, but without showing any relationships for those classes. Show method names. (Hint: modify the diagrams you drew for Project 2).
Familiarize yourself with the Sun Code Conventions for the Java Language, which are widely used among Java programmers.
Study the sample solution for Project 2. Critique it from the standpoint of style and programming practice, based on the Sun guidelines. Be careful in the body of your critique to use the Sun guidelines as the standard for judgment, and not your own preferences or those of others (such as instructors, TAs, or former teachers). If you wish, you can include a short appendix describing cases where you feel the Sun Standard is not adequate, or where your own preferences differ; this appendix is optional. You do NOT have to review every file line by line. Your answer should be word-processed and printed out.
Study the starter code for Project 3 and draw a UML-style Class Diagram for it. As best you can, include in the diagram any classes (or interfaces) which are NOT supplied, but which you think will be needed to complete the project. Indicate these classes in some way. DO include method names for any classes of the starter code.
Completing Project 3 involves, among other things, writing code to read in a text file. Most often, the java.io.BufferedReader class is used for this purpose. Study the Javadoc and figure out the complete inheritance hierarchy for BufferedReader, all the way back to Object; include interfaces as well as classes. Show your answer in the form of a UML-style Class Diagram (no, you do NOT have to include methods in this diagram!)
(This part involves code). To get the starter code to run, you have to finish implementing the WorldCreator class. Sometimes programmers write "stubs", rather than full programs, just to get the hang of how things will eventually work. Write a stub for the WorldCreator class that "processes" at least the first 4 lines of the given text file (containing the background description). The stub should NOT actually read that file (even if you know how to do that), but should produce output as if it did! To do this, you will need to study that file, and certain of the starter code files, and really figure out/deduce what should happen. WorldCreator will be the ONLY file you can turn-in on the the Step 1 turn-in form.
Run your program (i.e., DemoSim, which contains main), so that the background (from "processing" the input file) is on the screen; then take a screen snapshot, and print that snapshot to turn in. (Quick hint: on Windows, use the PrtSc button to capture a screen snapshot to the clipboard, then open a program such as Paint or Word or Powerpoint and paste in the picture from the clipboard. For more ideas, ask on the Message Board).
Special note: There will obviously be a bunch of pieces of paper to hand in. Be sure they are all stapled together, and that all parts have your name and section (in case the parts get separated). Unstapled and/or unlabeled parts will be considered in poor taste.
Step 2: (Code completion and extension).
Write a full implementation of WorldCreator. It should be able to correctly display the background described by any correct text input file; if an input file has a line which is invalid in any way, that line of the file should be ignored, and processing should continue with the next line. The starter version of WorldCreator has a helper method, getFile, that you can use.
Create at least one new Background subclass with some interesting background image. You may create more than one new background class if you wish (no extra credit, but it's always good to impress your TAs with cool designs).
Create a test (text) file for showing your new background(s). You may create more than one test file if you wish (no extra credit). Your main textfile (the one you consider shows your work to best advantage) must be named besttest.txt.
Create at least two new levels of inheritance descending from AbstractVehicle. This implies that at least two new concrete object classes are required. At least one of them should involve animation in some way (like the sample "auto" class). Some ideas are to create airplanes, ships, and animals as subclasses of AbstractVehicle and more specific types of each kind should inherit from them. The classes must be significantly different in terms of appearance and/or movement patterns.
Create a a class called ShowOff to illustrate (to your best possible advantage!) the new classes you have written, in action. Such a class must contain a main method (with the correct standard main signature) which creates a world and adds stuff to it -- see DemoSim for an example, but don't use that name for your class. You can submit more than one such class, but one of them (the one you consider the best) MUST be named ShowOff.java.
In working up your solution, DO NOT modify any of the starter code files (except WorldCreator) -- you won't be able to turn in new versions of them. You will, however, be able to turn in as many other .java files as you wish -- within reason! The turn-in form will have an option to accept JAR files, which is useful if you have a lot of files.
Some of the starter classes draw rectangles using a class called Rectangle2D.Double (yes, the .Double is part of the class name!). Look up the Javadoc for it and figure out its complete inheritance hierarchy, both classes and interfaces, all the way back to object. Draw a UML-style diagram to depict your findings (omit method names).
Please follow Javadoc conventions in commenting your code. Run Javadoc on your full, completed package. You don't need to print it all out, though. Just print out the Javadoc files for the classes you added or modified.
Turn in electronically all the files needed. Staple and label any printed material before handing it in.
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). In particular, this means that NO new packages should be created, and new/modified files should be placed in their correct package (e.g. Extended Background classes belong in the background package).
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. Take the Sun coding conventions to heart (although you don't have to follow them exactly if you have what you and your TA consider an equally good approach).
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 (e.g. you and some others brainstormed the idea) 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 for step 2 (now available!) |
Maybe, just maybe... if there are some really creative background and vehicles, we will have a "Beauty Pageant" so you can show yours off. Not for extra credit, just for glory... participation points for a few really neat ones.
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.
Thursday, July 17, 2003: The block comment before the modifyWorld in WorldCreator.java method says: "If the file has bad data, a null world is returned." This is incorrect; you should follow the online specifications given above and ignore only the invalid lines in the file, but process the rest.
Thursday, July 17, 2003: If you override the update method of the background (i.e. create fancier background animations, please download the newer World.java file. This is ONLY required if you intend to override this method.
Thursday, July 17, 2003: If you wish to load images such as .gif or .jpeg and draw them or add/change things about the animation panel (ie. change the background color), you should download the newer World.java and WinEnv.java files. This is ONLY required if you want to do some of these fancy things.
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.