Case Study

The case study deals with a Point Of Sale application for small stores. The application keeps an inventory, receives deliveries, supports sales of items to customers, and supports cashiers and cash registers. It is implemented in Java through several incremental changes.

Initial Development

The initial development implemented a greatly simplified version of the Point Of Sale application, in which all payments are in cash, prices are constant, taxes are uniform, and there are one register and one cashier in the store. The initial development introduced five classes: register, store, item, sale, and saleLineItem.

Support for Payment

Support for various forms of payment, including credit cards and checks, was implemented in the next iteration. Following the methodology, we first located the latent concept "payment" in the class sale, where it was implemented as a local variable of type integer. The member functions setPayment() and payForSale() deal with this variable and support cash payments. We reified the concept "payment" in a new class hierarchy consisting of the base class payment and its subclasses for cash and authorized payments, with further subclasses for checks and credit cards. This class hierarchy was integrated into the original program by replacing the old variable with an instance of the class payment. Other changes in the class sale involved changes in the member functions setPayment() and payForSale(). A secondary change propagated to the class register.

Price Fluctuations

This incremental change introduced price fluctuations. Products can have different prices at different times. In the old program, price was implemented as a single variable in the class item. We implemented the new classes price and promoPrice and replaced the variable in the old class item with an instance of the class price. After additional changes to the class item, the change propagated through the old classes store, saleLineItem, and sale. Figure 19.1 shows a Uniform Modeling Language (UML) diagram [Booch+1998] of the program at this stage.

Figure 19.1. UML diagram of the Point Of Sale application

Sales Taxes

This incremental change introduced the complexities of sales taxes. We describe this change in more detail with the help of the UML-like class diagrams shown in Figures 19.2 through 19.6. The boxes stand for classes, and the lines represent all associations. The arrows indicate the inconsistencies in the program and point to the classes that have to be changed. See [Rajlich2000] for further details.

Figure 19.2. Point Of Sale application after implementing the class taxCategory

Figure 19.6. Examining classes that interact with the class sale

Different products may have a different sales tax, depending on state law. The old program contained a single tax rate as an integer within the class item. We implemented a new class, taxCategory, and then replaced the integer in the class item with an instance of taxCategory. The current state of the program is represented in Figure 19.2. In it, the arrow points to the class item, where several additional changes must be made.

To remove the inconsistency, we examined the class item and made all necessary changes. The class item interacts with the classes store, saleLineItem, and price. Thus, they have to be checked and changed if necessary, as shown in Figure 19.3. The check of the class price revealed that it does not need any changes and that it does not propagate the change further. We then examined the class store and modified it. The next class, register, was checked but did not need any modification, and the change did not propagate in that direction. The resulting diagram is shown in Figure 19.4.

Figure 19.3. Examining classes that interact with the class item

Figure 19.4. Examining the class saleLineItem

The next class we checked was saleLineItem. After the changes were performed, the neighboring class sale could be influenced by the changes. Thus, the class sale is marked, as shown in Figure 19.5.

Figure 19.5. Marking the class sale for examination

The class sale required only one small change. Still, it interacts with two other neighboring classes, as shown in Figure 19.6, and they may also need a change.

The class payment did not have to be changed, and the change did not propagate further. The class register did not use the tax information contained in the class sale and relied on prices supplied by the class sale. Therefore, no change was needed, so we unmarked it, without propagating the change further. That completed this incremental change.

Several Cashiers

Stores often have several cashiers who take shifts at registers. This incremental change introduces multiple registers, cashiers, and their sales. The old version of the application assumes one cashier and one register, and this assumption is implicit in the implementation of the classes store, register, and sale.

New classes cashier and session reify information about the start and the end of the cashier's sessions, about sales realized within each session, and about the specific register used by the cashier during the session. They are interconnected with the old program by using the classes sale, register, and store, as shown in Figure 19.7

Figure 19.7. Interconnecting the new classes to the old program

Then we examined and modified the old class register, adding support for several sessions on the register and the cashiers' PIN numbers. After the changes, the class register no longer directly references the class sale but references the class session instead. A check of the class sale and its neighbors showed that the change does not propagate any further, as shown in Figure 19.8.

Figure 19.8. Examining the class store

The last remaining class to examine is store. During the check, we propagated changes from both the class cashier and the class register. The changes include adding new data members for a list of cashiers and a new method, registerCashier, as well as modifying the methods openStore and closeStore to allow the store to open only when some cashiers are available. The check of the neighboring class item showed that there is no need to propagate the change further.