No need to complicate things. Assume that bookings are stored only for the current week. Therefore, the days of the week are adequate for keeping track of bookings – no need for dates. And in terms of what needs to be stored? A name, a phone number and the booking size. That is all.
A sample design document is provided in Week 5.
As per the assignment 2 specification spec, use the Week 6 refactoring of AddressBook as your starting point. In terms of the database, keep it simple
The number of tables in use is the number of tables committed for an evening – if its a booking for 10, then 3 tables are being used. If its a booking for 1-4, its 1 table etc.
Browsable means using previous and next to view the bookings in the input fields as per the AddressBook example.
If we join 4 tables together, we can seat 10 people. Just make the maximum booking size 10.
Try to used derby database.
As per the newsgroup posting, you are not required to implement waiting list functionality. Also, since there is only one sitting per day (beginning at a set time), you only need to record the day.
Using a single view (as in AddressBook and the Week 5 design document) is fine.
Create a Swing-based desktop application similar to AddressBook
“One sitting per day” means that all customers for a particular day must be seated by a particular time (eg 7pm). The first course is then served, followed by subsequent courses. When the last course is served, the restaurant closes. Done it this way to make the booking process as easy as possible, although there are restaurants that operate in this manner.
The bookings are only for the current week, we only need to use 7 days rather than real dates. So I’ve made a JComboBox with the days Mon-Sun, then used the index number of the selected option in all my methods. Dunno if that’s right, but it was definitely easier than real dates!
If some one make cancellation of table then from the waiting list first customer can make book table.
The post A sample design document appeared first on My Assignment Online.