The customer is a pizza delivery company that wants to improve efficiency and customer satisfaction by streamlining the operations of making and delivering pizzas. As a first step, they want to create an Advanced Pizza Delivery Tracking System (APDTS). The APTDS will provide real-time information on the state of the pizzas as well as recording the data for later analysis by a separate system.
A pizza's lifecycle begins when a customer orders a pizza, usually over the phone, though they may use a web site in the future. An employee usually enters the order information, which gets printed out onto a slip of paper. The pizza is then prepared, which involves rolling the dough, adding the appropriate ingredients, and finally baking for 8-12 minutes depending on ingredients and size. Next, the pizza is queued for delivery, probably along with other pizzas heading in the same general direction. Finally, a driver delivers the pizza to its destination address.
Every pizza has a size (8, 12, or 16"), a list of toppings, a price, a customer name, phone number, and address, an order timestamp, and a delivery time. The delivery time is defined as the elapsed time between the order timestamp and the time the pizza is delivered to its address. A pizza is created by an employee and delivered by a driver (who is also an employee). A driver attempts to deliver as many pizzas as possible in a given delivery run, subject to a soft constraint that no pizza's delivery time may exceed 30 minutes. If this happens, the pizza is late and the customer receives a discount.
The system has a display which allows a manager to see the current queue of pizzas. The display also shows the running total of pizzas successfully delivered on time and late that day. At the end of the day, the system writes out summary information on an hour by hour basis in comma separated variable (CSV) format. The output for each hour includes the hour# (0,1,2...23), the number of orders taken that hour, and the number of on-time and late deliveries that hour.
There are typically between a few dozen to a few hundred pizzas delivered in a given day. Sometimes pizzas don't end up being delivered (due to mistakes, cancellations, prank calls, bad addresses, etc.) In the future the customer would like to add more capabilities to the system, including prediction (how many drivers will be needed in the next hour), alarms if the queue is growing large, integration with a GPS or cell location service to track drivers, and tracking of pizzas via bar code readers (like UPS). At some point they'd like to have a web site where customers can check on their pizza status.
The customer already has an accounting system which records customer payments and reconciles them with the order amounts. So this system won't be extended to do that. It also doesn't need to keep track of employee information, timesheets, etc. as there is yet another system that takes care of that. This means that you should not model the employees and customers in any more detail than needed for tracking pizzas and orders.
The customer is thinking about expanding to two locations, and if that happens they would like to be able to consolidate this information in some ways. They're not too clear on exactly what they'd like to do, though they have talked about redirecting orders (or drivers) between locations if one is overloaded.
Write up 2-3 of the primary scenarios for this system, including taking
an order and delivering a pizza to the customer. From these scenarios
and the description above, create a set of candidate classes with responsibilities
for different parts of the scenarios. Document the main responsibilities
of each class in a sentence orr two. Finally, create a class diagram showing
your classes, any attributes, responsibilities in the form of methods,
and the relationships between the classes. Turn in the scenarios and the
class diagram either through e-mail or on paper (pencil and paper is fine
for this assignment). (I can probably most easily view jpeg or gif images
if you send the diagrams through email.)
Each class should be cohesive and should be coupled to as few other classes
as possible. Note that a class is coupled to another class if it uses
objects of the other class or inherits from the other class. One-way
coupling is weaker (better) than two way coupling.
When you have questions about the problem domain or the requirements, send email to the customer (jpanzer@acm.org). I will provide typical customer responses. :)