Site Map  Search

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

Alice's Restaurant

[Just as the restaurant in Arlo Guthrie's song wasn't actually called Alice's Restaurant, our system is really known as ALICE but everyone tends to refer to it as Alice's Restaurant.]

Proposal

This is where the case study begins. The inception of a new system can take several forms: a proposal from marketing, or an invitation to tender from a government department, for example. Alice's Restaurant might have begun with one of the directors of our software house chatting to a restaurateur friend about the dificulty of finding suitable software systems for helping in the running of small- to medium-sized restaurants, bistros and brasseries. (In reality I'm sure there are many fine packages out there today. (Indeed if the purveyors of any such systems wish to pay for a modest, well-behaved advert here ...))

In order to help us form the statement of purpose for the system-to-be, we have asked the director to write down a proposal. Here it is (we suspect that there has been some help from the restaurateur):

We should keep the platform robust, simple and reasonably inexpensive. While more ambitious systems, for larger establishments, might sensibly use a distributed system, ALICE should be designed, initially at least, to run on a standalone PC or a Mac. We should probably support a mixture of peripherals, such as card readers so that the staff using the system can easily identify themselves -- when entering an order, for example -- touch screens, traditional display plus monitor plus mouse, printers for bills and for distributing orders to kitchen departments, and of course, readers for swipe or PIN payment cards.

The system would, at a minimum:

  • assist with placing and recording bookings, helping ensure optimal table utilization, balancing the avoidance of double bookings with the need to take one or two "floating" bookings;
  • take table orders, optionally splitting order printouts to departments (starter, main, desert, etc.; accept event information, such as "table away", in order that, for example, tables still awaiting their main courses can be intuitively depicted;
  • produce bills;
  • assist with menu production and usage history;
  • store recipes for some dishes;

The system might also:

  • maintain stock level information, especially for the more expensive items.