How Business Rules Improve Systems Maintenance

In the previous section we described how application systems are constructed of rules about the domain. What we didn't discuss and will take up now is how those rules are implemented, and why that has such a profound impact on maintainability.

There are four main ways to construct an application:

• Procedural approach

• Declarative approach

• Model-based approach

• Rule-based approach

There are hybrids, and most systems have some combination, but fundamentally they represent four different ways to convert requirements to implementation.

Procedural Approach

This is application code as we are accustomed to it. The code in Figure 8.7 is called procedural because the computer carries out the procedure, pretty much as we have written it. Typically this is written in a third-generation language such as COBOL, C, or Java. The procedural code is expanded to its equivalent machine instructions and the program executes. You can predict what the computer will do in what sequence from the source code.

         If purchaseOrder.amount > 10000         then call exceptionAuthorizationRoutine         Else call standardAuthorizationRoutine. 

Figure 8.7: Procedural code.

Declarative Approach

A declarative language is one in which a developer describes what needs to be done but avoids many of the details about how it actually gets done at run time. Structured query language (SQL), the query language for relational databases, is probably the most common declarative language.

The SQL shown in Figure 8.8 will read the order table and the customer table and return the customer name and the order number for all orders over $100,000. Procedurally, how it does this is not known to the programmer. The SQL precompiler/optimizer will come up with an "execution plan" based on what it knows about the presence or absence of indexes, and the cardinality of the rows of the tables and histograms of the frequency of occurrence of values in each of the columns.

         SELECT C.CustomerName, O.OrderNumber         FROM Customer AS C, Order AS O         WHERE C.CustID = O.CustID AND              O.OrderAmount > 100000 AND              C.Zipcode = 90520. 

Figure 8.8: Declarative code.

Procedurally, the optimizer may rely on the fact that only one customer has placed an order greater than $100,000 and read that record first, then join it to the customer table, and from there test the zip code. If that checks out, it then gets the customer name and order number and sends the output. However, it might just as well have tested the zip code first. You can see how one declarative statement could map to many different strategies for resolution as a procedural program, and therefore you cannot predict what code will be executed at run time.

Model-Based Approach

Model based approaches have become popular. Typically, instead of building a grammar for the language, the designer builds a model for the components of the request. Often the model is populated interactively or graphically (or both). A significant advantage of this approach is that the interactive build program can ensure that only valid models are built.

The graphic user interface tool kit is a form of model-based implementation (Figure 8.9). You pull "widgets" off a pallet and add them to your form. This is the visual representation. What you have really done is built a small model of a user interface and populated it with one object per widget, which has been parameterized with location, label, color, and binding information.

Figure 8.9: Part of the model behind a user interface.

The model-based approaches typically have frameworks, or middleware, that execute the models; therefore you cannot easily predict which procedural code will execute, unless you have access to and understand the middleware.

Rule-Based Approach

Most of the rest of this chapter examines rule-based systems, specifically business rule systems. We'll discuss what types of rules there are and how they relate to semantics. First we need to distinguish them from procedural systems, which they resemble in some respects.

For example, we may have a "rule" that states that we would like to have all purchase orders over $100,000 approved by a vice president (Figure 8.10).

         If purchaseOrder.amount > 100000           then action: reviewByVicePresident 

Figure 8.10: A sample rule.

The rule in Figure 8.10 looks suspiciously like the procedural example from Figure 8.7. Therein lies the confusion. The "rule" is really a data structure that looks approximately like Figure 8.11. Sometimes it is referred to as having a head and a body, sometimes a predicate and an action (or a goal in goal-directed AI systems).

Figure 8.11: Rule as data structure.

The significance of this difference may be more apparent in Figure 8.12, where we show the difference graphically. In the procedural approach, each new rule must be added somewhere in the structure, and where in the structure it is added is important. Each time we execute a predicate, the flow of control of the program moves us to a new point in the structure of the program. From this new point, a single rule can be evaluated, which moves the flow to a new point. This is true whether the code is a single large block of code, called subroutines, or objects. It doesn't matter. What does matter is that it takes a great deal of structural knowledge to know where to introduce a new rule.

Figure 8.12: Rule-based approach versus procedural approach.

In a rule system, we just throw the rules in a database, in any order, and a "rule engine" determines the sequence of rule execution dynamically. In a rule environment, figuring out which rule executes next is more indirect than in procedural code. In procedural code the next statement is the one that executes next. In a rule environment there is an algorithm that reads the rule base and finds rules whose preconditions have been satisfied. This set of rules is then queued up and each, in turn, is executed (or "fired").

Let's make this a bit more concrete. Say you have a program that sets the price for your products. The simplest version is shown in Figure 8.13; your price is just the list price for the item.

         Price = item.listprice 

Figure 8.13: Simple price assignment, procedurally.

You then decide to offer your products at a 5% discount and your services at a 2% discount (Figure 8.14). All is well and good until you decide to offer your preferred customers a 10% across-the-board discount (off of the list price).

         Price = item.listprice         If item.type = "product" then              Price = price * .95              CheckProductAvailability         ElseIf item.type = "service" then              Price = price * .98              ScheduleServiceTime         Endif 

Figure 8.14: Slightly more complex procedural algorithm.

Now we have a problem. If we insert the new rule/statement ("If cust.type = 'VIP' then price = listprice * .9") in the front of this block of code, the discount will be taken twice. If we insert it at the end, we might have overlooked some part of the algorithm in CheckProductAvailablity or Schedule-ServiceTime that might have made use of the price. In this contrived example, we would probably put the test in twice and hope that we caught everything.

Multiply this a few thousand times and you begin to see why programs become so complex. For the sake of making a point, I'm going to leave out some of the complexity, such as how you determine when to fire a rule and how you determine which rules take precedence. The rule example looks more like Figure 8.15.

              Predicate                     Action         Item.type = product      Price = item.listprice * .95         Item.type = service      Price = item.listprice * .98         Customer.type = VIP      Price = item.listprice * .9         Item.type = product      checkItemAvailability         Item.type = service      scheduleServiceTime 

Figure 8.15: Rules for the pricing algorithm.

This isn't a rigorous example, because at this point I just want to convey the general idea, which has a profound impact on whether the automation of the business process is flexible or not.

To flesh this out, let's dive a bit deeper into the business rules approach, and then segue into the semantics of business rules.