A component is a reusable software entity that is developed and deployed independently. Component based software development has many architectural advantages. In the previous article Componentizing a Monolithic Application in Java, we learnt the need for componentizing applications for getting the benefits of reusability and modularity. In this article let us look at how multi layered application can be componentized. We take the example of a multi-layered POS (Point-Of-Sale) application and understand how the application can be componentized at various layers like presentation, business and persistence layers.

Point of Sale - An Example Application
Consider a Point-of-Sale (POS) application meant for tracking orders and payments in a restaurant. The POS is used to track the tables being occupied by the guests, orders being made from various tables, and to print bills. Apart from these operational features, the POS application can also be used for restaurant administration. Total number of tables in the restaurant, list of foods sold in the restaurant, their prices, and the associated tax rates can be managed. The use cases to be supported by the POS application are described in brief below:

• Guests Check-in - This use case is invoked by the waiters when new guests arrive at the restaurant. POS displays a list of empty tables, and the waiter chooses an empty table and seats the guests in that table.
• Place Order - When guests from a table order for food, waiter invokes this use case. POS prompts the waiter for the table number, food item, and quantity ordered. POS consolidates and maintains orders against each table.
• Modify Order - Waiter can modify the quantity of any order already placed.
• Cancel Order - Waiter can cancel any order already placed.
• Pay Bill - Waiter invokes this use case to print the bill and collect payment for all items ordered from a table.
• Guests Check-out - When guests from a table leave, waiter invokes this usecase to mark the table as empty.
• Collections Report - At any point of time, the POS user can look at all the past payments collected.

Existing Implementation of POS
The existing implementation of POS uses a typical layered architecture pattern consisting of presentation layer, business layer, and data layer. The layered architecture is supported by the MVC (Model-View-Controller) design pattern. In the MVC paradigm, Model is responsible to capture real world business information through software objects. View is responsible to present the business information captured by Model visually for human consumption. Controller is responsible to handle user inputs and mediate between View and Model.

Figure 1 - Existing POS Application Architecture

Figure 2 - Objects in POS Application Layers

In the layered architecture of POS, Views and Controllers belong to the Presentation layer. Information exchange across the layer borders is enabled by the Model objects carrying business domain data. The multiple layers of POS are shown in Figure 1. The arrow directions indicate the control flow, or in other words, direction of invocation across layers. Figure 2 expands on Figure 1 and provides the list of objects present in each layer.

Model Objects
Model objects carry the business domain relevant information. In the restaurant business domain, we have Food, Table, Order, Bill, and TableConfig model objects. In addition, there is a FoodCategory that each Food belongs to, an OrderItem, a collection of which makes up an order, and a BillLineItem, a collection of which belongs to a Bill.

Figure 3 - Model Objects

All the model objects are presented in Figure 3. Food object is responsible for carrying information such as food name, price, tax rate, and the food category. The table object is responsible for storing the table number and the status on whether the table is occupied or empty. If the table is occupied, the table stores an Order object associated with the table. The Order object captures items ordered from the table. Each OrderItem is an order for multiple quantities of a food item. The payment toward all the items ordered from a table is captured and persisted in the form of a Bill object. Each OrderItem in Order has a corresponding BillLineItem in the Bill.

Presentation Layer
The presentation is based on a console-based UI in the current POS implementation. The presentation layer consists of Views and Controllers. Each UI view is responsible for showing one screen to the user and collecting input from the user interactively. The controller objects are responsible for processing the input gathered by the UI view objects. In addition, the controllers also control the UI screen flow - they direct the next UI screen to be shown after each screen based on user input. To process the input given by the users, the controller objects depend on business objects in the Business Layer.

Business Layer
The business layer contains objects that implement the business logic rules. The controllers from the presentation layer make use of the services offered by this layer. There are  four business objects in the business layer, which are presented below:

• FoodBiz - FoodBiz is responsible for business logic associated with food creation, modification, and categorization.
• OrderBiz - It implements all the business logic associated with maintaining orders placed by guests in different tables, addition and modification of order items, and cancellation of ordered items.
• TableBiz - It is responsible for maintaining total number of tables based on configuration, blocking and releasing tables based on guests check-in and checkout.
• BillBiz - This object is responsible for printing bill, and persisting bill details for future reference.

Business objects that need to persist the model data objects depend on the persistence layer.

Persistence Layer
The persistence layer is responsible for transfering the state information stored in the model objects to a persistent storage and for retrieving it back to in-memory objects. This layer consists of Data Access Objects (DAO). DAO interfaces are defined for TableConfig, Food, and Bill objects. Concrete DAO objects implement these interfaces specific to the database used. The example code that accompanies this article uses Db4o database. Each of the generic DAO is implemented by the Db4o specific concrete DAO object.

Componentization
Having analyzed the existing application in depth, which provides all the required functionalities, why should we componentize this application? Componentization in general helps in two different endeavors: (i) improve maintainability and (ii) extract reusable parts for storage and future reuse.

Let's investigate the maintainability aspect. Assume that there is a new business rule imposed in the POS application. The POS is supposed to charge a gratuity of 15% for any guest group consisting of eight or more members. On analysis of the existing application architecture, the BillBiz is the right object that can shoulder this new responsibility, because BillBiz implements the business logic that calculates the Bill amount. The BillBiz class diagram is presented in Figure 4.

Figure 4 - BillBiz Class Diagram

The BillBiz object has a payBill(Table table):Bill method. This method implements the business logic for billing. This method can be modified to accommodate the gratuity-related business change. In addition to this change, the calculated gratuity for each bill needs to be captured in some model object and persisted. The PayBillUI class in the presentation layer also needs to be changed to display the gratuity amount.

If we make these changes in the existing application as is, we need to recompile and redeploy the whole application, even though the application has a layered architecture. This is because these layers are logical and not physical. Moreover, to isolate the impact of the new business requirement, we need to isolate the Billing functionality from other functionality such as Order Management and Food Management functionality. Let's see how componentization can address this maintenance issue.

Componentized POS Application
Let's split the business layer of the POS into four different components as shown in Figure 5. By splitting the application into different components, the Billing responsibility is isolated into the Bill component.

Figure 5 - Functional Componentization of POS

In the componentized structure in Figure 5, when a new business rule for Billing is required, the Bill component can be replaced with a new Bill component without affecting rest of the application. In order to achieve the component structure proposed in Figure 6, we package the objects from the original implementation into different component packages as per Table 1.

Table 1 - Mapping of New Components to Old Objects and Layers

As a general pattern, it can be observed that each UI component consists of necessary view and controller objects. Each business component consists of necessary business objects and DAO objects for persistence. Apart from these components, the objects from the Model are packaged together as an object library, which is referred by each of these components. The objects inside the Model library are listed in Table 2. These are the same model objects that were presented in Figure 3.

Table 2 - Objects inside the Model Object library

Once we repackage the objects from the existing implementation into components as discussed above, we get component architecture for the POS application as shown in Figure 7. In the diagram the connector with a lollipop and a receptacle represents a component assembly between two components. In a component assembly, one component exposes a service and another component consumes that service. For example, the Table component exposes TableBiz service which is consumed by all the other components.

Figure 6 - Functional Componentization of POS

Figure 8 provides an expanded view of Figure 7, providing inside details of each component.

Figure 7 - Inside individual component

Replacing a Bill Component
As discussed earlier, we have a business rule change request that requires an additional gratuity amount to be charged to those guest groups whose size is eight or larger. We had reasoned in the earlier analysis that the business logic change can be implemented in the BillBiz class in the Bill component, in the payBill() method. Part of the code from this method is presented in Figure 8.

Figure 8 - Code Snippet from payBill(Table table):Bill method of BillBiz

As can be seen from the code snippet in Figure 8, the payBill() method obtains the Order object associated with the Table for which the Bill has to be generated. For each OrderItem in the Order, a BillLineItem is generated. For each BillLineItem, the base price, tax, and total price are calculated. All BillLineItems are kept in a collection that becomes part of the generated Bill object. The Bill object also has a total base price, total tax, and total payable amount. These values are calculated as sums of corresponding price components of the constituent bill line items. In the business logic change request, the total price of the bill should have an additional component called gratuity, if the number of guests is equal to or more than 8.

The current total price of the bill is given by:

Total Price = Base Price + Tax

With the introduction of gratutity, this would have to be changed to

Total Price = Base Price + Tax + Gratuity

Gratuity = 0.15 * Base Price (if number of guests >=8)

= 0 (otherwise)

The payBill() method code snippet shown in Figure 8 can be modified to accommodate the above change. However, we need to capture the new gratuity element in the model objects. In order to give least interference to other components, we introduce a new model object called as Gratuity. This object is responsible for storing the gratuityAmount and the Bill object to which the gratuityAmount is applicable. The class diagram of Gratuity is presented below.

Figure 9 - Gratuity Object in the Model

We shall call the modified Bill component as Bill2, and the modified BillUI component as BillUI2. The modified payBill method that implements the addition of a gratuity component to the bill is shown in Figure 10.

Figure 10 - Modified Code Snippet from payBill(Table table):Bill method of BillBiz

As can be seen in Figure 8 and Figure 10, the new code has created a Gratuity object if the number of guests is equal to or more than eight. It has also added a necessary amount to the total amount in the Bill object. The BillUI2 component would retrieve the Gratuity object associated with the bill and display the gratuity amount if it is non-zero. To facilitate this retrieval, a new method called getGratuityForBill() is added to BillBiz class in the Bill2 component. The modified BillBiz class is shown in Figure 11.

Figure 11 - Modified BillBiz Class in Bill2 Component

We reassemble the POS application by substituting Bill and BillUI components with the Bill2 and BillUI2 components. Of course, the new Model object library is to be used. With these changes, the component architecture of the application is presented in Figure 12.

Figure 12 - Modified Component Architecture of POS Application

At any point, the Bill2 and BillUI2 components can be replaced with the old Bill and BillUI components to change the behavior of the application back to the old. Thus evolution of the application with the insertion and removal of new functionalities can be done by changing components in the application assembly without changing the application code.

Conclusion
Componentization provides many benefits. In this article we demonstrated how a multi-layered POS application can be componentized. One of the important properties of a component is its pluggable nature. In the POS example, we saw how componentization facilitates modularity and easy maintenance through asimple replacement of pluggable components.

Acknowledgments
The authors would like to sincerely thank Anupama Nithyanand for her support and Nitin KL  for his valuable suggestions and reviewing this article. Authors are indebted to Soumya Bardhan, Shikhar Johari and Vishal Verma for helping in the development and testing efforts of the sample application.