From the last few days i have been thinking to share my idea about how to design software system from scratch with the help of object oriented principles. The way the OOPS is taught to the students may enable them to write small programming assignments, but when it comes to design a whole system, many of them may falter. I would like to address that part with the basic principle of OOAD and tell you how to traverse from the problem domain to the solution domain with the help of OOAD.
So, lets start. I have thought of an example to design a Restaurant system from scratch. I have used Java as the language, but one can use any OO language to achieve it.
To start designing of a software system using OOAD, one has to first identify the main entities participating in that system. So, in a Restaurant system who are the main participants? You guessed it right. A restaurant itself. Then the next entity is of course a customer. I think these are the main two entities. Now what does a restaurant consist of. It consists of some tables, a menu card, and food items. Another thing i have forgotten to mention. A restaurant should have a FIFO queue for its customers… right?
Now what kind of operation a Restaurant has to do? It should have some functionality to know if all tables are occupied, and if not which one is vacant; it should be able to book a vacant table when a new customer arrives. And when the customer leaves, it should be able to release that table and if anybody is waiting in its FIFO queue, it should be able to allocate that vacant table to that customer. It should also keep a track about who is the current customer it is serving and which customer has been allocated which table. Then it should also be able to generate a bill.
Now what does a Menu consist of? It has a list of some food items… right? So from Menu’s angle, it needs an entity called Item. Now what are the attributes of a food item vis-a-vis a restaurant? Each item should have an ID, a Name and its Price… right?
Now think that a restaurant will have a list of tables scattered systematically. So what kind of attributes a Table in a Restaurant may have? It should have an ID and it should know whether it is occupied or not. What kind of operation does a Table need? When a customer leaves the table, it should be able to tell the outside that it is occupied… right? On the other hand when a customer leaves the table it should let the outside world know that it is vacant and ready to accept new customer.
With these things in mind lets design the Restaurant, Table, Menu and Item classes.
Now lets talk about the other main entity called the Customer. What are the attributes of a customer should have when he enters a restaurant. he must have an ID. i am not talking about his passport or SSN or Aadhar card ID. This ID is with respect to the restaurant by which the customer can be identified within the Restaurant premise. We will also add Name as another attribute to a customer. Although there is no absolute need for this from the OOAD designer’s perspective, this is needed only for decoration as you will see later. And what kind of operation a customer usually does. He looks at the menu, decides what he wants to have and how many plates… right? So the customer entity should have an operation called giveOrder. Now think about this. In order to give order customer needs an entity which will hold the customer’s choice, i.e., which item and how many plates for that item. Lets call this entity as ItemOrder, each ItemOrder object representing a specific Item and its number of plates ordered by the customer. So in the actual order by a customer, there will be a collection for all these ItemOrders objects created by the customer. Lets create a class as Order which will hold a list of such ItemOrder objects. This Order class can be used by the Resaturant entity for calculating the total amount to be billed to the customer… right? So in essence, we have got three major classes to design the customer and his flow of orders, namely Customer, ItemOrder, Order. Lets see how these classes will look like.
Remember, all setters and getters functions have been removed from these diagrams (except ItemOrder) to make it simple.
Okay, another helper class we need. That is the bill class. It should have the functionality to calculate the total amount to be billed for a particular customer.
With all these classes ready, lets design the complete class diagram of the Restaurant System.
As you have probably guessed that a Restaurant HAS Tables and Restaurant HAS Menu. Menu HAS Item (rather items, a list of item). Restaurant has an ASSOCIATION with the Customer. The Bill stores a reference to a Customer for future use. Hence Bill has an AGGREGATION relationship with Customer. Each Customer creates an Order. Hence Customer HAS Order. And an Order holds a list of ItemOrders each representing and amount ordered for a particular Item. Hence Order HAS ItemOrder. Each ItemOrder keeps a reference of Item. Hence ItemOrder has an AGGREGATION relationship with Item. The Restaurant USEs Bill to calculate the total bill.
And with this explanation, the complete class diagram will look as the following.
Please note that the complete signatures of the operations are not given in the UML diagrams to make it simple. You can refer the respective class from the source code attached to have an idea of each operation.
Let me explain the UML in more detail. As you can see that Restaurant has a one-to-one HAS relationship with Menu and an one-to-many HAS relationship with the TABLE. This is quite obvious… right? Because a single Restaurant will have only one Menu list and it may have one to many number of TABLEs. The relationship of the Restaurant with the Customer is Association. Because a customer is an Independent entity. The Restaurant simply adds the new customer to its FIFO queue. As i have already mentioned, that a Customer HAS a Order (one-to-one relationship). Because whenever a customer plans to order, he needs to create an Order which he will populate with different ItemOrders(remember ItemOrder keeps a reference to an Item and how many plates the customer needs). As the ItemOrder keeps a reference to the Items, it obviously has an Aggregation relationship with the Item. A bill also has to keep a reference of the customer because it needs to identify for which customer the Bill has been generated. Hence the Bill also has an Aggregation relationship with Customer. The Restaurant has a USE relationship with the Bill because it creates the Bill object as a local variable in the generateBill function. Now probably you have acquired some sorts of idea about how this whole system has been designed using UML and OOAD.
The code for this whole Restaurant System is here. It is, of course in accordance to this class diagram given earlier.
Hope this helps the OOAD learners....