Exercise 1

Deadline 18. September 2009 4:00pm, delivered on paper in a box marked "IT2103" on the other side of the hall outside F1.

UML Design:

You shall design a restaurant system from the specifications.

Informal Requirements

The system to be developed is intended to support the day-to-day operations of a restaurant by improving the process of making reservations and allocating tables to customers. The restaurant currently operates a manual booking system using hand-written forms stored in a large folder.

As example of current manual booking form is given in Figure 1. Each row on this form corresponds to a particular table in the restaurant. Bookings are entered for a particular table, and the number «covers», or diners expected, is recorded for each booking, so that a suitable table can be allocated. The restaurant runs three sittings in an evening, known as «pre-theatre», the «dinner» and the «supper» slots, but as the form illustrates, these slots are not strictly adhered to and bookings can be made for time periods that span more than one slot. Finally, a contact name and phone number are recorded for each booking.

Figure 1 A manual booking sheet.

Diners can of course eat at the restaurant without making an advance booking, if a free table is available. This is known as «walk-in» and is shown on the sheet as a booking to record table occupancy, but no record of the customers name and telephone number is made.

The need for computerized system

The restaurant management has identified a number of problems with the manual system. The system is slow, and the booking forms quickly become difficult to read. This can lead to operational problems, such as customers being prevented from making a booking because it is not obvious from the form that there is in fact a table free. There is no backup system: if a sheet gets destroyed, the restaurant has no record of what bookings have been made for that evening. Finally, it is very time-consuming to get even simple management data, such as the rate of table occupancy, from the existing booking sheets.

For these reasons, among others, the restaurant would like to develop an automated version of the existing booking sheet. The new system should display the same information as the existing sheet, and in roughly the same format, to make it easy for restaurant staff to transfer to the new system. When new bookings are recorded, or changes made to the to existing bookings, the display should be immediately updated, so that restaurant staff are always working with the latest information available.

The system must make it easy to record significant events that take place when the restaurant is open, such as the arrival of a customer. Operation of the system will be as fr as possible by direct manipulation to the data presented on the screen. For example, it should be possible to change the time of a booking, or the table it is allocated to, simply by dragging the booking to an appropriate place on the screen.

Assumptions:

You can assume that you don't need a safe storage, meaning that all data objects can reside in main memory. (All data objects are saved to disk or database independent from your system).

Problems:

Problem 1:

Create a use case diagram for the system.

Problem 2:

Create a textual use case for booking a table.

Problem 3:

Create a domain model for the system.

Problem 4:

Create a sequence diagram where the system shows booking on a given date.

Problem 5:

Create a sequence diagram for a successful booking.

Problem 6:

Create a design class diagram for the system.