Dates

3 April 2001	Design due
5 April 2001	Stubs due
17 April 2001	Complete implementation
19 April 2001	Integration due (demo)
24 April 2001	Modified implementation
26 April 2001	Integration due (demo)
3 May 2001	Demo as ACE Server

Description

The Quo Vadis (QV) corporation has commissioned you and two of your classmates to construct a Path Server. This server will accept a representation of two locations and return the directions for navigating between them. Examples of this kind of service might include:

Driving directions between cities
Driving directions between locations in a city
Flight plans for air travel between cities

QV is interested in saving the consumer time. Thus, the path computed will be a shortest path, of the kind you have studied in CS 241. This project will occupy the rest of the semester, and it will consist of four parts:

Design, team formation, and stub construction (1.5 weeks)

You will each arrive at a design in the form of an API, specifing the classes and public methods for this application. Your grade consist in part of how well you conceive this design. Elegance, balance, flexibility, and attention to necessary detail are the criteria by which you will be measured. Your design must decompose this problem into three, roughly equal parts. Let's call those parts A, B, and C.
You will then form yourselves (or be formed by me) into teams of three people. You must stay with this team for the rest of the semester, so try to pick people with whom you feel comfortable collaborating.
You will then each be assigned one part (say, part A) of the problem, based on the design, and you will be responsible for implementing a stub for that part. The stub should take you no longer than a few hours to finish. It looks and smells like it works, but it is a total sham. Enjoy this while you can.

Implementation (2 weeks)

Now you will pick up a different part of the problem (say, part B). You will fully implement part B. You must declare a flight plan for your implementation, so that you can test with your parters along the way. Your implementation grade will be based on elegance of your code, documentation of the relevant choices you make, and evidence of your testing along the way. At the end of this phase, you will fully integrate your team's pieces into a working program.

Variation (1 week)

Ah, this was easy up to now! Your humble instructor and TAs will at this point announce last-minute, world-saving, must-be-done, unanticipated changes to the design for this problem.

You will pick up one of your partners' parts (say, part C), and you must change it to achieve the desired effects of the spec modification. Your grade will be based on your critique of your parner's code (be ruthless---it will help your grade and won't hurt your partner at all) as well the way you manage to adapt the code to the spec change.

Server (1 week)

Lastly, you will make a server out of your path-finding program and write a client to go with it. You will do this using the ACE middleware, which will make your client/server both easier to write as well as portable.

Notes:

Many of the details of this project will be covered in class; you are responsible for all material presented in class.
This may be the first time you have worked in a team; welcome to the real world! In most of our classes, you are required to perform on your own. Not so here. Modern software systems are too big to be built solo. Working in a team has its challenges, but if the tasks are crafted and managed properly, you can get much more done as a team.
It is still uncool to pass off somebody else's work as your own. However, you have a team to consult when you get stuck.
You'll learn of my biases concerning Java and C++. Programs written in Java are generally more portable, and Java offers nice abstractions for network programming. However, we will use ACE to create the Client/Server parts for your project, which can make your resulting code quite portable.
Throughout this project, the emphasis will be on identifying problems (conceptual design problems, storage-ownership problems, performance problems, etc). You are required to document your problems and their solutions, identifying the patterns you have applied and how they have helped.
The correct, thoughtful use of design patterns is a major basis for the grading of this project.
The code you write will be subject to a graded code review by the instructor and/or the TAs. The judicious use of comments for documentation is strongly encouraged. Do not document the obvious, but do document sufficiently so that your teammates can tell what you are up to. Use them as readers of your code and comments to help improve your style.

Design (due 3 April 2001)

Form your team, and work on a design together. Turn in one design per team, but have each student sign the submitted design. The design should be in the form of well-commented .h files. Your grade will be based on completeness, elegance, and independence of specification for the pieces described in class.

Stubs (due 5 April 2001)

Turn in stubs for your .cc files. Each stub should be very easy to write, and should exhibit minimum functionality for its method. For example, if a method took in a list of numbers and was supposed to sort the list, have the stub for that method return the list (1 2 3 4 5) no mattter what its input was.