You will be completing various parts of a restaurant locator/reservation/seating system. This system will have two main parts:
These parts in principle would work concurrently, but since concurrency and networking is beyond the scope of this course, they are not expected to work concurrently, but rather sequentially. If a reservation is made in the system, then going to the restaurant view after that time would allow the restaurant to see the reservation. More information about the types of interactions required for each part of the system are indicated in the sections that follow.
Each paragraph below gives one piece of the functionality of the restaurant finder and reservation maker view.
There should be a way for the system to give you a restaurant recommendation based on the type of cuisine it serves (Mexican, Italian, French, etc). This will only include the name of the restaurant. You don't have to worry about storing other information about the restaurant for the customers.
There should be a way for the system to give you a restaurant recommendation based on an ingredient in a meal it serves (chicken, oregano, green pepper, etc). The results of this should also give you a % of the restaurants meals that contain that ingredient, so the higher the percentage, the higher the recommendation should be to the customer.
Upon given a recommendation, the user should be able to make a reservation at that restaurant. The reservation should take information about time, and the number in the party. Adults and children would be recorded separately. Assume that children are 12 and under and children under 5 need a booster seat at the restaurant and those under 2 need a high chair. The user should also be able to make a reservation at a restaurant simply by selecting its name from a list. The reservation mechanism is the same at this point, but how the user got the name of the restaurant is different. Note that reservations can only be made for the current day. This limits the systems use, but relaxes the requirements for your implementation.
The system should also give the user a "fast pass" ability. That is, given the time of day and the number of people in the user's party, the system can give a set of recommendations about the restaurants that would be able to seat them the fastest.
Each paragraph below gives one piece of the functionality of the restaurant view.
A way for the restaurant greeter to record "walk ups" to the restaurant so that they can be queued up for the next available table that is not already reserved. The system should also tell the greeter the approximate time to an available table so that the restaurant patrons would know about how long they will need to wait.
A way for the restaurant greeter to "check in" parties with reservations that have arrived at the restaurant. This will let the system know that the parties can be seated when their table is ready.
A way for the greeter to select the next party that should be seated. The seating of a party should be based on a priority of the time of the reservation and the number of guests in the party. You are free to design your priority however you'd like. Many restaurants prefer to seat larger parties before smaller ones. Some prefer to seat all-adult parties before parties with children. Some prefer to seat smaller parties before larger ones so that it seems like people are being seating faster. Perhaps people with reservations have priority over walk-ups. Perhaps those that arrive for their reservation time early have priority over those that were on time or late. Take any or all of these suggestions into account when making your priority, but whatever you decide, there needs to be a way to determine which group is seated next.
A way for the greeter to indicate that a party from the table has left so that it frees up the table in the system to be used for seating. Feel free to speed up time in your simulation of the program so that you can move people in and out of your restaurant quicker. For example, 2 seconds = 1 minute of dining, or whatever scale you would like.
You need to design the data for your system. No data will be provided to you, but the data you provide will be part of your grade for the project. So, make sure to design a number of restaurants, their menus and their seating plans. You can use real restaurants as a guide for your data design (as far as menus and types of cuisine).
You will place all your files for this project in a directory named project. Zip up this directory submit one zip file per team. The file should be named project.zip.
You need to submit your files using the Web-CAT system. For more information about using Web-CAT, please see: http://www.cse.buffalo.edu/faculty/adrienne/SP2009/cse250/Lectures/SubmissionUsingWeb-CAT.ppt
All three data structures assignments are due to be turned in by 11:59:59pm on Sunday, April 19th. Friday, April 24th
Page maintained by Adrienne Decker
Contact: adrienne@cse.buffalo.edu | 130 Bell Hall | (716)645-3180 x 161