This document describes three projects. Your last assignment is to do one of them. The program comprises 8% of the points on which your final grade will be based.
Relevant due dates for the project are as follows. In lab on April 20 or 21, you must explain to your t.a. which project you are choosing to work on along with the following information: who, if anyone, you're working on it with; how you plan to split the project between members of your partnership if you're working with a partner; and which parts of the project you plan to have ready for the next progress check.
In lab on April 27 or 28, you must display significant progress on the project: some procedures coded and tested, with a fairly detailed plan for proceeding on the rest. (The individual project writeups have suggestions for what to provide.) In lab on May 4 or 5, you must show your t.a. an essentially complete program.
You get a day of leeway on these checkoffs as you did with homeworks and quizzes through the semester.
Your completed project program is due at 5pm on Monday, May 10. There is no leeway here; you will be penalized for a late submission. Put all relevant files into your submissions directory.
The project is worth 32 points (scaled to 16 course points). Up to 16 points will be awarded for project correctness and adherence to specified requirements; up to 16 points will be awarded for displayed correctness (test cases), readability, and the general case you make that your program works correctly.
The project checkoffs mentioned above will also provide points, contributing toward a factor by which your project grade will be multiplied: the points your project earns will be multiplied by the fraction of the checkoff points you earned before being counted toward your course grade. (For example, if you earn 8 out of the 10 points for the three checkoffs, your project grade will be multiplied by 8/10 before being included in the course grade computation.) The first checkoff is worth 2 points, while the other two are each worth 4 points.
Readability includes comments, indenting, sequence of procedures in your file, appropriate use of Scheme (e.g. by avoiding the use of sentence/word procedures with lists), and choice of names for procedures and their placeholders. Some readability guidelines: Procedures that deal with the same kind of structures should be together in your file, so that they are easy to find. Rather than using a cond with a zillion conditions, you should probably use assoc with a table or list-ref with a list. Use procedures for side effects only where necessary (e.g. to do output).
You may be unable to use the Java Listener to run the "Blocks World" project (because of the graphics and file access), or the data base project (because of access to files). You can test individual bits of code with the Java Scheme interpreter, but your runs of the complete program must be done with STk.
Your comments at the start of the program should include an overview of how all your procedures fit together. Each nontrivial procedure should be accompanied by a description of the procedure's purpose, a sample call, and the types and expected values for its inputs.
Appropriate test cases are described in each project writeup. Also test your component procedures in isolation, to provide more evidence that they will work together correctly. Students in the past have attempted to fake their tests. This is not all that difficult to catch, since you are submitting your program solutions; the penalty will be a 0 on the project.
You are encouraged though not required to do the project in a partnership of two. Partners must be in the same lab section. A partnership should turn in only one solution (with both your names and logins in it). A partnership should also supply a file named partners.readme that describes the following:
Turning in unacknowledged code not written by members of your partnership or supplied by us constitutes cheating. It will be penalized by a grade of F in CS 3 and referral to the Office of Student Conduct.