There is an earlier post related to Restaurant here. I wanted to attempt this design challenge again now with some more complexity.
I will describe the challenge here first followed by the assumptions.
We are going to discuss about a restaurant with
Assumptions being made are all payments are made electronically.
Let us try to model this restaurant using Object oriented techniques
The different players are
Our next milestone is to design classes to support the above use cases. Without much difficulty we can arrive the need for classes Customer, Cashier, Chef and Waiter and their operations(Actors in the use cases have their classes).
In the use case model we are talking about adding order to queue, adding cheque request to queue. These queue classes are also part of the class diagram accordingly. I did not mention the operations and attributes of *Queue classes as they are obvious.
Restaurant's operations typically are table centric(what i mean is they typically talk in terms like a barbecued chicken for table no 1, prepare the cheque for table no 5 etc). In this system we just need to store the details like customer name (this also is not mandatory at least would be helpful to address him in the bill/custom feedback form).
But any point of time we should have information of what orders are coming from which table, which customer is seated at which table. (Putting the table id into the customer object is not the right thing to track the customer table association as table id does not naturally look to be an attribute of a customer object).
Similarly we need to know which orders are coming from which table( it is actually customers seated at that table). Here also storing table id in order to track the association does not seem correct.
We use two maps to track the association between customers and tables, tables and orders.
Below is how the class diagram looks for the Restaurant system now
Cartoon courtesy: here
I will describe the challenge here first followed by the assumptions.
 |
We are going to discuss about a restaurant with
- some limited(m>0) tables
- one chef
- one waiter
- one cashier
- some chairs for customers to wait when the tables are busy.
Assumptions being made are all payments are made electronically.
- The restaurant does not allow table reservation policy. You come and if there is a table sit and dine else wait for a table to free.
- All orders are going to be accepted i.e. there is no way the chef would say ingredients for menu item 29 are over and hence cant accept the order for that item. Poor chef :(
- Any new items ordered by the customer are treated as a different coming from same customer.
- The waiter gets the name of the customer as part of welcoming him and will use it along with table number to identify the customer
Let us try to model this restaurant using Object oriented techniques
The different players are
- Customer
- Waiter
- Chef
- Cashier
Our next milestone is to design classes to support the above use cases. Without much difficulty we can arrive the need for classes Customer, Cashier, Chef and Waiter and their operations(Actors in the use cases have their classes).
In the use case model we are talking about adding order to queue, adding cheque request to queue. These queue classes are also part of the class diagram accordingly. I did not mention the operations and attributes of *Queue classes as they are obvious.
Restaurant's operations typically are table centric(what i mean is they typically talk in terms like a barbecued chicken for table no 1, prepare the cheque for table no 5 etc). In this system we just need to store the details like customer name (this also is not mandatory at least would be helpful to address him in the bill/custom feedback form).
But any point of time we should have information of what orders are coming from which table, which customer is seated at which table. (Putting the table id into the customer object is not the right thing to track the customer table association as table id does not naturally look to be an attribute of a customer object).
Similarly we need to know which orders are coming from which table( it is actually customers seated at that table). Here also storing table id in order to track the association does not seem correct.
We use two maps to track the association between customers and tables, tables and orders.
Below is how the class diagram looks for the Restaurant system now
Cartoon courtesy: here
