Restaurant Application Clarifications Actors and Use Cases z

Actors and Use Cases z. Supervisor ÕGenerate EOD reports, Monitor table status, Take reservations,

Table Assignment z. Done upon restaurant opening z. Assume all waiters who will work

Orders z. Most common sequence: order, serve, bill, pay z. Food/drinks may be served

Inventory, Payment z. No need to worry about item inventory— assume an unlimited supply,

Take-out Orders z. Carry-out (to-go) orders should be supported, z. Just assign to a

Tables and Customers z. Should not assign a party to a table whose capacity

Service Times z. Need to keep track of: ÕTime between: table was occupied and

Order versus Order Item z Think carefully about the notion of an “order” z

Reservations z. Assume that a table is held once a reservation is made z.

Slides: 10

Download presentation

Restaurant Application Clarifications

Actors and Use Cases z. Supervisor ÕGenerate EOD reports, Monitor table status, Take reservations, Assign group to table, Assign table to waiter, … z. Waiter ÕTake order, serve, bill, …

Table Assignment z. Done upon restaurant opening z. Assume all waiters who will work that day will show up when the restaurant opens and will stay for the whole day z. Supervisor browses through all tables and selects a waiter for each table z. No assignments/changes will be done in the middle of the day

Orders z. Most common sequence: order, serve, bill, pay z. Food/drinks may be served at different times z. Additional orders can be carried before bill is issued z. Order portions may be cancelled as long as they have not been served

Inventory, Payment z. No need to worry about item inventory— assume an unlimited supply, although you need to keep track of quantity of items sold z. Unpaid bills can occur and need to be reported (some impact on total sales and counts); assume a bill is paid entirely or not paid at all

Take-out Orders z. Carry-out (to-go) orders should be supported, z. Just assign to a single special table, so we can monitor carry outs Õ“Parallel” carry-out orders is optional

Tables and Customers z. Should not assign a party to a table whose capacity is insufficient z. Need a way to assign capacities to table; assume initialization is done before the system is operational, but allow updates z. Tables cannot be combined, for now

Service Times z. Need to keep track of: ÕTime between: table was occupied and customer leaves table ÕTime between: customer first ordered and last item was served on table z. Need to know average and maximum service times on the table at the end of the day

Order versus Order Item z Think carefully about the notion of an “order” z For a given customer/party, there is a set of orders (several order comprise an order-set), or you can view “order” as the set and have orderitems under it z Do you need to have a class for the set? ÕMaybe not, but I recommend that you have one anyway

Reservations z. Assume that a table is held once a reservation is made z. The table could be released at a future time, particularly if the customer does not show up on time