17jul03 note: Consider adding a subsection on "Implementation Considerations", wherein we discuss all of the thoughts we've had on potential implementations, i.e., the one's we've run through in our heads to make sure that what we're thinking about is possible. It may not be necessary to even have such a subsection title explicitly, just include such considerations here as a matter of course. Pedagogically, we do need to mention that such considerations are part of what should go here, in general, unless the implementation is 100% straightforward (which one can scarsely ever imagine being the case). Part of these considerations can also be explicit mention of what the implementors are free to do, even if such mention is not strictly necessary given the standard rule that if the user can't see it, the implementors can implement it any way they want. E.g., a case in point in the cal tool is that the implementors are free to implement the central host calendar as a single file, or multiple files, such as one per user, since the user cannot expect to find his calendar in file form on the central host, but can only get access to it via running the calendar tool. This is not to say that an implementor is prohibited from putting it on some file that the user might be able to see, as long as visibility constraints are met.

Here is fodder from Bigger Burger era 440 final report overview handout.

The Biggie Burger system is composed of two subsystems: customer food ordering and inventory management. The customer ordering subsystem communicates with the food-ordering customers seated at the table. This subsystem handles customer requests, and sends the food order to the kitchen when ordering is completed. The inventory control subsystem handles manager updates to the restaurant databases.

The major operation of the customer ordering subsystem is OrderFood. It takes a restaurant menu and customer selections as input, and produces a customer order. The order is accumulated incrementally, by suboperations OrderBurgers, OrderSides, and OrderDrinks.

The major objects handled by OrderFood are the FoodMenu, CustomerOrder, CustomerReceipt and CookOrder. The FoodMenu and Customer order are displayed on the ordering screen. The CustomerReceipt is produced on paper when the customer indicates that the ordering is done. The CookOrder is sent electronically to the kitchen where it is displayed on the cook's screen. The cook order is also sent electronically to the inventory control system, wherein the inventory database is automatically debited to reflect the ordered items.

The principal ordering constraint is that the customer-selected food item is currently available (i.e, there is stock on hand to make up the food item). The Menu will be updated as necessary during normal business to reflect immediate changes in inventory. E.g., if all chili has been consumed, then the Chili Burger item will be deleted form the menu, where deletion is specified by marking the item as ``temporarily out of stock'' on the menu.

The inventory control subsystem has three major objects and corresponding operations: the FoodMenu, the FoodStuffsInventory, and the FoodItemBreakdownList. The FoodMenu is the top-level menu seen by the customer from which order selections are made. It is composed of sections for Burgers, Side Orders, and Drinks. Manager-level Operations are provided to add, delete, and modify menu sections.

FoodStuffsInventory is the inventory of raw food items, such as burger patties, buns etc. This inventory contains a description of all stock on hand. Operations are provided to add, delete, and modify inventory items. Inventory report generation operations are also provided. These operations can produce daily, weekly, monthly, and yearly inventory reports.

The FoodItemsBreakdownList contains the complete breakdown for each food item on the menu. Each breakdown describes exactly what raw food stuffs are need to prepare a menu item. Operations are provided to add, delete, and modify food item breakdowns.