Chapter 13. Simplification by Separation

“Life is like an onion: You peel it off one layer at a time, and sometimes you weep.”

Carl Sandburg

The triad discusses a new story from their sponsor, Sam, to let people reserve CDs online. The story illustrates how separation of issues allows the creation of simpler tests.

Complex Business Rules

Cathy starts off, “Sam has an idea for a website. The website connects back to the charter, because we want to give our customers the ability to reserve a CD. Sam has come up with two ideas. He wants to allow customers to reserve CDs on the web, and he wants them to be able to search CDs. We haven’t worked out the details on the second story. But Sam has already decided on the first.”

“He has worked out a pretty elaborate business rule for whether a customer should be allowed to reserve a CD. He created a table, because he’s been following along with our discussions. The table looks like the one that follows.”

Debbie interrupts, “That table looks complicated, but I’ve seen some business rules that look like it.”

Cathy replies, “I think Sam can be a little complex sometimes. He wants the decision for allowing someone to reserve to be based on a number of criteria. The criteria includes the number of times the customer rented in the past month and the cumulative number of rentals since becoming a customer and the number of late returns for the past month and beginning rentals. Sam also has a few people who are his favorites; he wants them to be allowed to reserve unless they have a really bad rental history.”

Simplify by Separating

Cathy asks, “So what do we do with this?”

Tom replies, “With all these comparisons and complex conditions, this is a hard table to understand. We can break it into smaller tables, if Sam lets us or you let us, in lieu of Sam being here. As David Parnas states [Parnas01], tables can clarify the requirements. And smaller tables can add more clarification.”

Cathy responds, “It’s as clear as mud to me. So let’s break it up.”

Tom says, “Let’s start with the Monthly Rentals column. We can separate the values into separate fields and put the comparisons in single cells. I like to make up names for the result of each comparison. My suggestion is to call the results Monthly Rental Levels, or MRLevels to keep it short. If there were meaningful names we could assign to each result, we might name them MRExcellent, MRGood, and so forth. But in this case, let’s just label them with letters. The table for Monthly Rental Levels looks like this.”

Cathy says, “I know we’ll need some tests for these Monthly Rental Levels.” The triad works together and creates the following.

Cathy says, “I’m not sure what the results should be for those two rows with the ??.”

Tom replies, “By breaking the original table into smaller tables, we can see whether we have left out anything. Creating some tests for just the Monthly Rental rule shows that some possibilities have not been covered. Perhaps these possibilities may never occur during production. But at least we’ve identified them and Debbie can be sure to make allowance for them in the implementation. She could at least record that they occurred, put up a dialog box, or do whatever is appropriate.”

Debbie interjects, “It seems like there should be a MRLevelD as the default level if none of the conditions are met. That would make it easier to keep track of those possibilities when they occur.”

Tom resumes, “We can do the same thing for the Cumulative Rentals. To save time, here’s a quick outline.”¹

The Simplified Rule

Tom continues, “With these individual tables taking care of the details for Monthly Rentals and Cumulative Rentals, our revised table now looks like this.”

Cathy asks, “Have we covered all the cases? It seems like there are some missing ones.”

Tom replies, “You’re right. It’s clearer now what all the cases are. There are several combinations of MRLevels, CRLevels, and Sam’s Favorite Customer that do not appear in the table. Here are a few.”

“We need to ask Sam whether the answer is yes or no in these cases. He could simply say that the answer is no in all other cases. That would make Debbie’s life easier, as well as mine. In any event, you and he need to approve these new tables as being the way to represent the business rule. As you can see, separating rentals into separate tables decreases the amount of information that needs to be absorbed for each table and makes the tests cleaner.”

Rental History

To allow reservations based on Sam’s business rule, the system needs to keep track of the rentals for each customer. The system could keep separate information on each rental. At this point, Cathy does not need the history. All she needs is a count of rentals for the month and the total number of rentals. So for each customer, there might be the following.”

When Tom tests the overall system including the user interface, he’ll look up both 007 and 86 and see whether the reservation is allowed.² There also should be a test ensuring that the system calculates rental history correctly, such as this.

The test does not imply whether a rental history is kept. If it is, the history could be used for other features that are scheduled to be developed soon. All that is needed now is to change the numbers whenever a check-in occurs. When the check-in happens, the number of rentals is incremented by one. If the rental is late, the number of late rentals is incremented by one. Once a month, the system clears out the rental count for the past month.³

It might be easier to keep a history. The check-in process would add the data for a rental to the history. The Rental Summary calculation would find all the rentals for a customer and calculate the counts. In either case, the test is independent of the way the calculation is performed.

Summary

• Simplify business rules by separating them in component parts.

• Create tests for the component parts.

• Use the simpler components to determine missing logic.