Case Study: Restaurant System 1. Problem statement The system system is intended to support the day-to-day operations operations of a restaurant by improving improving the processes of making reservations and allocating tables to customers. The Restaurant system provides the facilities like •
Record Booking
•
Cancel Booking
•
Record Arrival
•
Table Transfer
The new system can offer diners eat at the restaurant without making an advance booking, if a free table is available. This is known as Walk-in. The new system should display the same information as the existing booking sheet and in same format, to make it easy for restaurant staff to transfer, to the new system. When new bookings are recorded or changes made to existing bookings, the display should be immediately updated, so that restaurant staff is working with the latest information available.
2. Visio Vision nD Doc ocum umen entt The vision document describes the higher level requirements of the system, specifying the scope of the system. The vision document of restaurant system might be •
It is a support system for restaurant
•
The restaurant makes bookings, cancel bookings, record arrivals and table transfers of the customers.
•
The receptionist is the employee of the restaurant who interacts with the customer whose work is supported by the system.
•
The customer rings up to make a booking there is a suitable table free at the required day and time and the required day and time and the receptionist enters customer’s name, phone no. and records booking.
1
•
When the customer arrives, his arrival is updated in the system and waiter attends to them.
•
The customer can also cancel booking what he made or transfer the booking to another day or time.
•
The receptionist can easily record , update and cancel the information about the bookings and customers
•
The customers eat in restaurants even with out any reservations or bookings called Walk-in.
3. Glossary This document is used to define terminology specific to the problem domain, explaining terms which may be unfamiliar to the reader. This document can be used as informal data dictionary capturing data definitions, key terms. Booking: An assignment of a table to a party of dinners for a meal Covers: The number of diners that a booking is made for Reservation: An advanced booking for a table at a particular time
particular table Places: The number of diners that can be seated at a particular table Walk-In: A booking that is not made in advance. Actors: Customer: The person making a reservation Diner: A person eating at the restaurant
4. Supplementary Supplementary Specification Specification Document Document 4.1 Objective The purpose of this document is to define the requirements of the restaurant system. The supplementary specification lists the requirements those are not readily captured in the use cases of the use case model. The supplementary specification and the use case model together capture a complete set of requirements of the system.
4.2 Scope This specification defines the non-functional requirements of the system such as reliability, usability, performance, supportability and security. As well as functional requirements that are common across a no. of use cases.
4.3 References 2
None
4.4 Common Functionalities •
Multiple customers can be able to visit a restaurant.
•
Customers who have recorded booking must be notified.
4.5 Usability The desktop user interface shall be Windows NT and Windows 2000 complaint.
4.6 Reliability The system shall be available 24 hrs a day, 7 day a week to no more than 10% downtime.
4.7 Performance The system shall support up to 1000 simultaneous users against the central data base of any time.
4.8 Supportability Supportability None
4.9 Security •
The system must prevent customers from changing information like record booking, date and timings of reservations.
•
Only receptionist can modify customer’s information of record booking, updates and cancel booking.
•
Only proprietor can modify the receptionist information.
5. Use - Case Model 5.1 Actors Actor is something external and interacts with the system. Actor may be a human being or some other software system. For restaurant system 3
•
5.2 Use cases
Receptionist
Use cases represent the functional requirements: •
Record Booking
•
Cancel Booking
•
Table Transfer
•
Record Arrival
•
Record Walk-in
•
Display Bookings
5.3 Use Case Diagram
4
Record Booking Receptionist
Cancel Booking
<
>
<>
<>
Staff
Display Bookings
<> Table Transfer
<> Head Waiter Record Arrival <>
Record Record Walk-in W alk-in
5.4 Use-case Specifications Specifications 5.4.1 Use-Case Specification: Specification: Record Booking 5.4.1.1 Description This use case starts when the receptionist want to record the bookings the customer have made.
5.4.1.2 Flow of Events 5.4.1.2.1 Basic Flow
1. The bookin bookings gs are reco recorded rded into into the rest restaura aurant nt database database..
5
2. The receptio receptionist nist enters enters the date date of the requeste requested d reservation. reservation. 3. The syst system em displ displays ays the the booking bookingss for that that date. date. 4. There is a suitable suitable table availabl available; e; the receptioni receptionist st enters enters the customer customerss name and phone number the time of booking, the number of covers and the table. 5. The syst system em recor records ds and display displayss new booking. booking. 5.4.1.2.2 Alternate Flow
1. The receptio receptionist nist enters enters the date date of the requeste requested d reservation. reservation. 2. The syst system em displ displays ays the the booking bookingss for that that date. date. 3. No suitable suitable table is available available and the use-case use-case terminate terminates. s. 5.4.1.3 Precondition
The customer wants to reserve the table in restaurant on particular date. 5.4.1.4 Post condition
The customer successfully reserves the table on the required date.
5.4.2 Use-Case Specification: Specification: Record Arrival 5.4.2.1 Description This use case starts when customer arrived at restaurant.
5.4.2.2 Flow of Events 5.4.2.1.1 Basic Flow
1. The headwai headwaiter ter enters enters the the curre current nt date. date. 2. The syst system em displ displays ays the the booking booking for for the the date. date. 3. The headwa headwaite iterr confirms confirms arriva arrivall for the selec selected ted booking. booking. 4. The system system records records this this and updates updates the the display, display, marking marking the custome customerr as having having arrived.
5.4.2.1.2 Alternate Flow
1. The headwai headwaiter ter enters enters the the curre current nt date. date. 2. The syst system em displ displays ays the the booking bookingss for that that date. date. 3. There are are no bookings bookings recorded recorded on the the system system for the the customer, customer, so the the head waiter waiter creates a walk-in booking, by entering the time of booking, number of covers and the table number. 4. The syst system em record recordss and displ displays ays the the new booki bookings. ngs. 5.4.2.3 Precondition
6
The customer must reserve the table.
5.4.2.4 Post condition The arrival of the customer is updated.
5.4.3 Use-Case Specification: Display Booking 5.4.3.1 Description
This use case starts when the customer wants to see the bookings on that date. 5.4.3.2 Flow of Events 5.4.3.2.1 Basic Flow
1. The use userr ente enters rs a date date.. 2. The syst system em displ displays ays the the booking bookingss for that that date. date. 5.4.3.2.2 Alternate Flow
1. System System displa displays ys no booki bookings ngs on on that that date. date. 5.4.3.3 Pre-condition
User should be the member of restaurant and must enter the date. 5.4.3.4 Post condition
System displays the bookings on the entered date.
5.4.4 Use-Case Specification: Cancel Booking 5.4.4.1 Description
This use case starts when the customer wants to cancel the booking he has made. 5.4.4.2 Flow of Events 5.4.4.2.1 Basic Flow
1.
The rec receeptio ptioni nist st sele select ctss requ requir ireed boo booking king..
2.
The rece recept ptio ioni nist st canc cancel elss the book bookin ing. g.
3.
The The sys syste tem m ask askss the the rece recept ption ionist ist to confi confirm rm the the can cancel cella lati tion. on.
4.
The The rece recept ptio ionis nistt answ answer erss ‘yes’ ‘yes’,, so the the syst system em rec record ordss the canc cancel ella lati tion on and and updat updates es
display. 5.4.4.2.2 Alternate Flow
1. The syste system m display displayss no reserv reservatio ations ns of custom customers ers.. 5.4.4.3 Precondition
The customer must have already booked the table. 5.4.4.4 Post condition
7
The booking of the customer gets canceled.
5.4.5 Use-case Specification: Table Transfer 5.4.5.1 Description
This use case specification starts when head waiter wants to transfer the booked table. 5.4.5.2 Flow Of Events 5.4.5.2.1 Basic Flow
1. The head waiter waiter sele selects cts requi required red booki booking. ng. 2. The head head waiter waiter changes changes the the table table allocat allocation ion of the booki booking. ng. 3. The syste system m records records the alter alteratio ation n and updates updates displ display. ay. 5.4.5.2.2 Alternative Flows
1. When it is not possibl possiblee move a booking to a table table that that is already already occupied occupied 5.4.5.3 Precondition
The table is already booked by another person. 5.4.5.4 Post condition
The table gets transferred.
5.4.6 Use-case Specification: Record Walk In 5.4.6.1 Description
This use case starts when some one arrives to eat in the restaurant with out reservation. 5.4.6.2 Flow Of events 5.4.6.2.1 Basic Flow
1. The headwai headwaiter ter perfo performs rms displ display ay bookings bookings use use case. case. 2. The head waiter enters enters the the time, the the number of covers covers and table table allocated allocated to customer. customer. 3. The syst system em recor records ds and displa displays ys new new booking booking.. 5.4.6.3 Alternative Flow
No table is available as free. 5.4.6.4 Pre-conditions
The person should not reserve the table in advance. 5.4.6.5 Post conditions
The system records walk in.
5.4 Activ ctivit ity y Dia Diagr gram am 8
Enters Date [ not avalable ] free t able
reservation
Display Details on the date
RecordW RecordW alkin
[ available ]
[ available ]
Rec ord Arrival Arrival Make Reservation [ not available available ] Record booking
Display Booking
6. Design Model 6.1 Class Diagram
9
BookingSystem date : Date
Restaurant 1
cancel() display() makeReservation() recordArrival() selectBooking() updateDisplay()
getBookings() getCustomer() getTable() makeReservation()
* Booking
* current * selected
*
co vers : Integer date : Date time : Float *
1
getDate() getDetails() se tArrivalTi tArrivalTim m e() setTable()
Table n u m b e r : In In t e g e r p l a c e s : S t riri n g
{ B o o k i n g s fo fo r t h e s a m e t a b l e m u s t n o t o v e rlrl a p . } { M u s t b e o n e o f th th e current bookings.} * W a l k In In
Reservation * Makes arriv arrivalTime alTime : F loat
1
Customer n a m e : S t r in in g p h o n e N u m b e r : In In t e g e r
setA rriv rrivalTim alTim e()
6.2 Sequence and Collaboration Collaboration Diagrams Diagrams 6.2.1 Sequence Diagram for Record for Record Booking Use-case Booking Use-case
10
:Receptionist
:Booking :Booking System
:Restaurent
c:Customer
t:Table
:Reservation ion
makeReservation(details) makeReservation(details) getTable(tno) return t c:=getCustomer(name c:=getCustomer(name e,phoneno) Reservation(date,t,c) reservation ok reservation ok updateDisplay()
updateDisplay()
6.2.2 Collaboration Diagram for Record for Record Booking Use-case Booking Use-case 9: updateDisplay() updateDisplay()
2: makeReservation(details) 1: makeReservation(details) :Receptionist :Booking :Restaurent System 8: reservation ok 10: updateDisplay() updateDisplay()
4: return t
6: Reservation(date,t,c)
5: c:=getCustomer(name e,phoneno ) 7: reservation ok
3: getTable(tno) c :C us to me r
t:Ta b le
:Reservation
6.2.3 Sequence Diagram for Display for Display Booking Use-case Booking Use-case
11
:staff
:Booking System
:Restaurent
:Booking
display() getBookings(date) getDate() return bookings
return date
updateDisplay()
updateDisplay()
Booking Use-case 6.2.4 Collaboration Diagram for Display for Display Booking Use-case 6: updateDisplay() updateDisplay()
1: display() :staff
:Booking System 7: updateDisplay() 5: return bookings 2: getBookings(d getBookings(date) ate)
:Restaurent
3: getDate()
:Booking
4: return date
booking Use-case 6.2.5 Sequence Diagram for Cancel booking Use-case
12
:Staff
:BookingSys tem
Current: Booking
Selected: Booking
selectBooking(id) getDetails() returnDetails() cancel() confirm() return 'yes' destroy
updateDisplay() updateDisplay()
6.2.6 Collaboration Diagram for Cancel booking Use-case booking Use-case 8: updateDisplay()
:Staff
1: selectBooking(id) selectBooking(id) 4: cancel() 6: return return 'yes'
:BookingSystem
3: returnDetails() 5: confirm() 9: updateDisplay() 2: getDetails() 7: destroy
Selected: Booking
Current: Booking
6.2.7 Sequence Diagram for Record for Record Arrival Use-case Arrival Use-case 13
:Staff
:Booki ng System
selectBooking(id)
current:Book ing
selected: Reservation
getDetails() returnDetails()
returnDetails() recordArrival() setArrivalTime(now) updateDisplay() updateDisplay()
6.2.8 Collaboration Diagram for Record for Record Arrival Use-case Arrival Use-case 7: updateDisplay() 1: selectBooking(id) 5: recordArrival( recordA rrival()) :S ta ff
:B oo ki ng System 4: returnDetails() returnDetails() 8: updateDisplay() 3: returnDetails() returnDetails() 6: setArrivalTime(now) setArrivalTime(now) 2: getDetails()
current:Booking
selected: Reservation
6.2.9 Sequence Diagram for Table Transfer Use-case Transfer Use-case 14
:HeadWaiter
:BookingSys tem
Current: Booking
selected: Booking
select booking id getDetails() return details
makeTableTransfer(id)
update booking update display
updateDisplay()
6.2.10 Collaboration Diagram for Table Transfer Use-case Transfer Use-case 6: update display 1: select booking id 4: makeTableT make TableTransfer(id) ransfer(id) :HeadWaiter
:BookingSystem 3: return details 7: updateDisplay()
2: getDetails()
Current: Current: Booking Boo king
5: update booking
selected: Booking
6.2.11 Sequence Diagram for Record for Record Walk-in Use-case 15
:Receptionist
:Booking System
:Restaurent ent
:Reservation ion
makeReservation(details) makeReservation(details) reserve table Walk-in reservation ok
reservation reservation ok
updateDisplay() updateDisplay()
6.2.12 Collaboration Diagram for Record for Record Walk-in Use-case 6: updateDisplay()
1: makeReservation(details) :Receptioni st
:Booki ng System 7: updateDisplay()
5: reservation ok 2: makeReservation(details) 3: reserve table Walk-in :Restaurent
:Reservation 4: reservation ok
6.3 State chart Diagrams Diagrams 16
6.3.1 State chart diagram for Booking for Booking Class Class
s e l e c t B o o k i n g [ b o o k i n g fo fo u n d ]
S e l e c t B o o k i n g [ n o b o o k in in g ]
/select new booking
NotSelected
s e l e c t B o o k i ng ng [ b o o k i n g fo fo u n d ] S e l e c t e d /select new booking
6.3.1 State chart diagram for Reservation for Reservation Class
setTable
Booked
setTable
setArrivalTime
Seated
cancel
7. Deployment Model 17
7.1 Component Diagram
StaffUI.java
Booking System.java
Restaurant.java
Customer.java
Booking Observer.java
Booking.java
Table.java
18
7.2 Deployment Diagram
<> Client Customer.exe
<> Booking System Reservation.exe
<> DB Se rver rver Restaurant.db
<> Client Receptionist.exe
19
