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.
The system will implement one scenario:
The following scenario should not be implemented (yet), but the
design and code should easily accomodate it:
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).
(errata: The APDT class should be named APTDS, and OrderEntryUI should be named OrderUI.)
TrackingDisplayUI.java, Order.java, OrderPrinter.java,
See also the User Authentication System for more UI examples (http://www.johnpanzer.com/ucscx-oop-java-examples/securitysystem/index.html)
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 firstname.lastname@example.org; you can also copy email@example.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.