CSE331 Autumn 2011
Software Design and Implementation


 Assignment 3 (15%): Due Sunday October 30, 2011 at 11:59PM

This program focuses on coming up with, and implementing, a design that is effective. Although we give you the name and general responsibilities of the classes, we do not provide the methods, specifications, etc. for each class. That is a major part of the assignment, in addition to the implementation, and the design is something you've generally never been assigned to do. Because it should help to talk about the design, the assignment is to be done in pairs, as already assigned. (Except in unusual situations, students in pairs will each receive the same grade.)

Program Description

You will write a set of supporting classes for a restaurant management system. This kind of application would be used by the hosts and servers at a restaurant to manage their set of tables, customers, meal orders, employees, and so on. We provide a text-based interface as the "front end" (which will require some modification on your part).

You will need to download support files into your project to run the UI:

Run RestaurantMain to launch the program. Input files like menu.txt should be placed in your Eclipse project's root folder, the parent of its src/ or bin/ subdirectories. You must use svn to manage your project, or else any pair work will be extremely error-prone.

Classes to Design and Implement

There are several functions that must be handled by the system—they can be defined in classes, distributed across classes, etc., as you see fit:

A major part of your grade will come from how effectively you design the contents of each class to solve this problem elegantly.

Text User Interface

The RestaurantTextUI class performs all user input/output. No other class should perform I/O to/from the console. (Similarly, this class should do no core computation or storage that is central to the restaurant management system.) The text UI given to you is mostly complete, but it is missing a few "hooks" into your code where we can't know in advance exactly how you will design your classes. So you must edit the provided mostly-complete text UI class, looking for places that are unfinished and adding small bits of code there to attach the text UI properly to your objects and their methods. These parts of the code have been marked with // TODO comments to make them easier to find.

Your classes are to exactly reproduce the format and overall behavior found in our sample inputs and sample outputs. In several places the text UI displays amounts of money.

You will have to run the text UI and test individual inputs on your own to verify that your classes are working correctly. But you will need to create additional tests internally (see below) and additional UI-level tests.

If you want to try to exactly match the provided sample solution, put the provided Scanner.java in your project. This Scanner is a re-implementation of Java's Scanner but with "input echoing" so you can see the user input even if you redirect I/O to/from a file. If you use Java's Scanner and redirect input in from a file, it won't actually show you what the user typed, so your output looks screwy when you capture it to a file. But this Scanner does echo if you tell it to, fixing this issue. To use this, add this Scanner.java to your Eclipse project. Make sure that your RestaurantTextUI imports java.util.*; rather than manually importing java.util.Scanner individually; if you do the latter, your code will use Java's Scanner and not this one. Then recompile your project and go to the terminal. To make the input echo, you have to pass a debug flag to the Java VM named scanner.echo and set it to 1. So you do something like this: 

java -Dscanner.echo=1 RestaurantMain < input1.txt > myoutput1.txt

Then you can compare the outputs more easily with something like:

diff output1.txt myoutput1.txt

Exception Checking and Error Handling

Your classes should forbid invalid parameters. If any method or constructor is passed a parameter whose value is invalid as per this specification, you should throw an IllegalArgumentException. The main client program should not throw any exceptions to the console. If any errors occur, it is considered a bug in your code. It is encouraged for you to incorporate exception throwing into the design of your core classes, but you should make sure to catch and handle those exceptions. The text UI performs its own checking for the validity of various user input values, such as making sure that numbers are non-negative. But this is completely unrelated to your own tests and exception checks. Remember that valid arguments are preconditions and could be checked by the client. Your core classes' should not assume that clients are careful (although the clients won't be malicious)

Development Strategy and Testing

It is hubris to try to write all of these classes at once and then compile/run the overall program. Therefore it is important to write and test your code incrementally. Think about which order of implementing classes willl be most effective for your team. Remember that you can insert a "stub" version of a particular method or entire class that simply has a pair of empty {} braces for the method's body (or simply returns a dummy value like null or -1). This may allow you to test unfinished classes together. Every class you turn in must have an associated JUnit test class. The degree of testing should be commensurate with the complexity of the class and its methods.

Sharing testing code you write for this assignment is both inapproporiate and also largely useless. It's inappropriate because it would reveal details about the implementation and design you have used; it would be largely useless because your design likely has different methods, etc. from the designs others produce. You may, however, share text input files or input/output logs that you have created from your runs of the main text UI, to help show illustrative usage of the client that helps to find flaws and bugs.

Grading

The basic grading structure is: 40% for the overall quality of the design; 30% for the overall quality of the implementation; and 30% for the overall quality of tests.

For the design, it is important to demonstrate (through comments, as well as the design structures themselves) effective use of module specifications, effective use of cohesion, effective reduction of coupling, effective use of subtyping and subclassing, etc. For the implementation, the correctness is the major objective, with style the secondary objective. Correctness includes handling the error conditions as well as the common cases. For the testing, appropriate levels of testing are the key objective.

Style and Design Guidelines

We will cover some basic style and design guidelines in lecture (in addition to the modular design already covered), and you will be responsible for using those guidelines. The design issues such as clear specifications, good cohesion, weak coupling, effective use of subtyping and subclassing, aoviding representation exposure (consider carefully the use of immutability, for example), etc are the most important. Lower-level issues are also important, but cannot overcome a poor design. Some of these issues include (many but not all of which we will have discussed):

For reference, our solution contains roughly 210 "substantive lines" (which excludes things like blank lines, comments, and {} brace lines), excluding our Utility.java shared code. But this number is just provided as a sanity check; you do not need to match it or be close to it to get full credit.