Site Map  Search

OOA Home OOD content UML Corrections book Code object Exercise Solutions oriented Resources tutorial Miscellany textbook

Alice's Restaurant


These are reprinted from the book.

First come the irreducible or atomic or static or classic requirements:.

Critial (must)

  • Register the details of a booking request.
  • Allocate a given booking to a given table, advising of any unsuitable or impossible characteristics it discerns such as, but not limited to, a table that is too small, too big, not free, or not non-smoking.
  • Locate a table of suitable capacity for a given booking (or a table that is minimally bigger than the party size), where the table has the required characteristics – for example, but not limited to, smoking/non-smoking or quiet – and where the table is free at the time in question.
  • Note updates regarding table availability to reflect such things as “walk-ins” (diners who have not booked).
  • Register changes to booking details advising of any consequential unsuitability or impossibility.
  • Flexibly present the details (at least including the contact name) of bookings expected within a selected time period, including now, for one or more selected tables.
  • Register the arrival of a party who have booked thus updating the table to an occupied condition.
  • Register the details of a meal order, including but not limited to department (course), quantity of servings, preferences (including for example rare/medium/well-done or no dressing).
  • Determine the allocation to kitchen departments (starters, mains, etc.) of meal order contents.
  • Notify departments of newly taken orders via the output the system is configured for (e.g. printout).
  • Register changes to the details of a meal order, alerting when items being changed appear to already have been committed to kitchen department or served.
  • Compute the current bill for an order, part of an order or group of orders*.
  • Register the details of a dish, including name, description and price; and any preferences that must be determined by the order taker (e.g. waiter/waitress) such as rare/medium/well-done.
  • Register changes to the details of dishes, drinks, etc. including the name, description, price and the likely number of servings of a dish or bottles of a wine that remain to be served.
  • Be able to locate significant entities such as bookings, orders, tables, menus, dishes, members of staff via their properties or their relationships and portray their details in summary or in detail.
  • Register updates to any standing information such as normal opening hours, nominal table capacities, table numbers (IDs) and table characteristics such as extra legroom.
  • In general, register changes to the details of any significant entities such as bookings, orders, tables, menus, dishes, members of staff.
  • Assemble (via user choices) a new menu from old menus and/or selected dishes, supporting the allocation of dishes to their appropriate place in the menu (typically starter, main or after) and their kitchen department (often but not always the same – starter, main or after).
  • Prepare selected menus for output (e.g. printing, rich text format or dynamic HTML), including the setting up title, section headings and legals (e.g. service not/is included); there should at least be the options of: same as used yesterday, choose from recently used, edit chosen or new.
  • Register the details of a bill payment, including date and under- or over-payment (tip).
  • Flexibly recall and present current and past menu details.
  • Flexibly recall and present recipe details.
  • Flexibly recall and present floating, placed and cancelled bookings' details.

    * In the book this read "Produce bills", and its tightening up was set as an exercise.

Great to have (should)

  • Understand (and use in matching bookings to tables) a set of booking characteristics that is user-configurable, and could include such things as smoking, non-smoking, quiet and good legroom.
  • When indicating and presenting to the user such things as tables, bookings and orders, use an intuitive and appropriate metaphor such as screen forms for bookings and orders, calendars for bookings, and two-dimensional approximated physical position for tables.
  • Register, update and recall the allocation of waiters to tables and changes thereto.
  • Report time to deliver a dish either by using recipe information or by using any kitchen or table preparation times registered for that dish.
  • Raise an alert when the likely number of servings remaining has been recorded for a dish, and a meal order requests servings in excess of that.

Nice to have (could)

  • Calculate approximate stock depletion from meal orders placed.

Change case (won't)

  • Notify stock items below minimum levels on request.
  • Notify stock items near expiry.
  • Register stock level corrections.
  • Register stock item information such as quantity-on-hand, normal unit, maximum level, minimum level, re-order level, typical re-order quantity.
  • Register stock acquisitions.
  • Accept the booking of a party to more than one table.
  • Support the analysis and correlation of takings, including but not limited to takings by table, time, date, season and menu.
  • Accept bookings for the entire restaurant.
  • Accept bookings for an entire floor of the restaurant.

And now the use cases, again reprinted from the book:

Use case name:
 Successfully make a system-assisted booking
Use case reference number:
Initiating event:
  Customer contacts restaurant, requesting a booking
Key outputs: None
Key state changes:
New booking added to system
A booking request is received (e.g. by phone or over the Net). A day, a start time and a party size are given. Preferences may be given also. In this scenario, it is a non-smoking, quiet table that is requested. A duration could be given, but in this scenario, as is common, no duration is given.
  In this scenario, the customer is not recognized; there is no favorite table lookup.
  The details of the requested booking will be input to the system.
  The system will locate a suitable table. That means a table that is the right capacity for the party, or a table that is minimally bigger than the party size. It means a table that has the required characteristics – non-smoking and quiet. It means a table that is free at the time in question.
  The system will display the suggested table; a table is found in this scenario. (The GUI or the dynamic web page might display the location of the table, but that is an included sub-use case, described separately.)
  The user confirms that the table is OK. In this scenario, the table is OK.
  The system allocates the booking in question to the table in question.

Use case name:
Successfully locate a booked table on party arrival Use case reference no.:
Use case reference number:
Initiating event:

   Part arrives claiming a booking was made
Key outputs: None
Key state changes:
   1) Table noted as being occupied
  2) Booking noted as honored
   The name in which the booking was made is obtained from the party. The system displays the contact names of the bookings due to arrive within 20 minutes either side of the current time. The party’s contact name is found. The system indicates which table was allocated. The system is informed that said table is now occupied and that the booking was honored.

Use case name:
   Meal order using hand-held terminal
Use case reference number:
Initiating event:
Table (party) ready to order
Key outputs:
   Dish lists per department
Key state changes:
   1) New order added to system
  2) Table noted as awaiting starters
The first diner gives his starter and main. The system is informed. The second and third diners each give their starters. The system is informed. The first diner changes his mind and requests the same starter as the second diner, but without the parmesan flakes. The second diner gives her main course. It is steak and the system prompts the user to request the preference as to rare, medium or well done. The third diner gives their choice of main.
  The user reads back the order and the diners confirm. The user confirms to the system. The system registers the order and the time taken. The different dishes are split out according to the department that prepares them. The different dish lists are output (e.g. printed) at the different departments, annotated with the time taken, the table and waiter/waitress.