Assignment 3: Advanced Pizza Delivery Tracking System

Description

This is a continuation of Assignment 1. In this assignment, you will implement a portion of the APDTS. The system you implement should not implement additional functionality, but should be extensible and flexible in order to support future changes. In particular, it should implement the internal core classes needed to support all the important scenarios described in the solution to Assignment 1.

Requirements

The system will implement one scenario:

Scenario 1: Taking an Order

  1. Customer calls in and tells order to Employee
  2. Employee enters order into the system:
  3. Employee enters pizza details (repeat if multiple pizzas)
  4. Employee enters customer name, phone number, and address
  5. System prints out the order include a barcode onto a label printer for each pizza
  6. System puts order into queue and it shows up on the tracking display UI

The following scenario should not be implemented (yet), but the design and code should easily accomodate it:

Scenario 2: Delivering an Order (future)

  1. Driver arrives at customer location with pizza
  2. Driver scans pizza label's barcode with hand held scanner
  3. Device sends message to APDTS saying the order has been delivered
  4. The APDTS removes the order from the order queue
  5. The APDTS sends back the price (with any applicable discount) to the hand held scanner
  6. The hand held device displays the price and whether the order is late.
  7. The driver takes money from the customer.

The design team has created a mock-up UI using Swing classes, and this is available for you to use as a starting point for your GUI.  In other words, you can take this code and modify it; or, if you wish, you can write your own UI code that replaces it.  However, you should be sure to keep as much of your code as possible separate from the UI code, to make it easy to change UIs later on (the UI isn't very good yet, they may want to change the details).  The UI designers have come up with a Swing UI that has two separate windows, one for entering orders and another for the tracking display UI.  (We're pretending for the moment that these will be displayed on separate monitors.)

For this version, implement a stub class PizzaLabelPrinter for printing the label for each pizza. The class should just print out a debugging message to System.out in order to verify that the proper data is being passed..

For the tracking display UI, implement the partial UI shown on the attached piece of paper. This is a simplified version of the final UI. For this version, having both windows on the same screen is fine (in the final system, there will be multiple screens, but all will be driven by the same back end system -- don't worry about the details for now.)

This version does not require that a Customer be remembered by the system from order to order. The common case is the ordering of one or perhaps two pizzas at a time (assume 80% of orders are for one pizza).

Class Diagram

Class diagram for Assignment 3
(errata:  The APDT class should be named APTDS, and OrderEntryUI should be named OrderUI.)

Sample UI Code

APDTS.java, OrderUI.java, TrackingDisplayUI.java, Order.java, OrderPrinter.java, OrderQueue.java.

Client Documentation.

See also the User Authentication System for more UI examples (http://www.johnpanzer.com/ucscx-oop-java-examples/securitysystem/index.html)

Deliverables

An accurate class diagram providing a roadmap for the system (if different from the one above), well-commented source code, and text output. The class diagram should include all important classes and critical methods, but need not be very detailed -- use javadoc for detailed interface specifications.

If you want to provide additional design documents -- for example, scenario diagrams for class interactions, or a state chart -- feel free to do so.

Comments: Be sure to comment your code appropriately, describing the general responsibilities of a class in a class header, and documenting the public methods. Comments within method bodies chould describe why the code is doing something, not what it's doing.  Use javadoc comment styles and make sure you can generate the javadoc.

I would prefer an email submission to jpanzer@acm.org; you can also copy jpanzer@netscape.com to ensure that it goes through. For diagrams, gif images are the best format. A paper submission is fine too, but you won't get as much feedback.