One of the common questions regarding any UML[1]-based project is, where do I put the business rules? When we think of a UML-based project, we often think of use case driven process that utilizes class, sequence, and state diagrams. The most common of these processes is the Unified Process. However, as we will see, the approach that we take will work with other processes such as Feature Driven Development.

Business rules are the specialized form of logic that expresses a constraint about the way that a system or the people using it behave. These rules are guided by a variety of elements including regulatory agencies, industry standards, business acumen, or plain old common sense. They often vary from country to country, industry to industry, and even business to business. An example of a business rule in banking might be that any cash transaction greater than $10,000 in cash must be reported to the government. So, if you are writing a banking deposit/withdrawal system, you must take this business rule into consideration.

Business rules happen at a variety of levels. Some impact the entire system and, in fact, whole systems are written to enforce business rules. The impact of business rules can also be very localized. But all business rules have one thing in common; they govern some element of the business. For a business rule is, by definition, a constraint on person, business, element of the business, or action performed. The Unified Modeling Languages has some definite things to say about these things.

The Business Requirements

Many business rules are discovered in the course of gathering requirements. The natural desire is to add a section to your use case descriptions and add the business rules there. However, unless a business rule is inherently related to the function described by the use case, they commonly span multiple use cases. So, the $10,000 cash business rule would span the Make a Cash Deposit and the Make a Cash Withdrawal use cases.

Each of these use cases has an opportunity to fire the rule or to cause the rule to be invoked. As a result, you may be tempted to add this rule to each of these use cases. In fact, many use case templates have a section for business rules. But what if the government changes the rule from $10,000 to $15,000? You would need to be sure to change this in both use cases.

Some business rules truly belong with a use case. These rules result in exception conditions that must be addressed for the use case to proceed. For example, the large deposit in question might require some information from the bank customer such as the source of this cash. This information potentially would have to be supplied as part of the use case. It would certainly have to be part if it influenced whether the goal of depositing the cash were to be achieved or not.

However, many business rules are simple validation elements such as ensuring that the state and the zip code match. We often overlook these business rules while writing the use case since it is a detail of validating the address. However, there is another place that we can put these constraints. They logically belong on the Address class in the class diagram. By placing these business rules on the class in the class diagram, we are ensuring that they are reused across use cases in the same way that the class is reused across the use case model.

Rule Types

There are generally three types of rules. The first is the derivation rule [Francis 2003]. The derivation rule transforms information received into values returned. For example, discounts may be computed using a certain algorithm depending on the size of an order, special promotion, or to a valued customer. This type of rule is subject to change and thus must be isolated so it can be manipulated.

The second type of rule is the constraint rule [Francis 2003]. The constraint rule is used to determine if the values of a transaction or operation are consistent. For example, the state and zip code must match for the customer to be able to proceed. They can also be used to examine object relationships such as every customer must have an address object in an internet video store. Constraint rules can be applied with Boolean results. If they are not true, we cannot continue or finish the operation.

Finally, there are the invariant rules [Francis 2003]. Invariant rules look at multiple changes and ensure that the composite results are consistent. For example, the balance of savings account must equal the previous balance plus the credit or minus the debit. If you achieve something different, your system is leaking money and its time to raise an exception to the highest levels.

Figure 1: Employed as a collaboration

These rules can be applied to properties and collaborations [Nicola 2002]. Often, the properties of one system are the collaborations of another. For example, one system may model the concept of being employed through a collaboration (see figure 1). Another system may use a property instead (see figure 2). The implementation is independent of the type of rule.

Expressing Rules

We can express business rules in the use case diagrams when they apply to a state or role at a macro level. These rules may appear as preconditions, postconditions, or in the flow of events or alternative flows and exceptions. Business rules that apply to these areas generally serve the goal established by the use case (such as Rent Video). A lot of invariant business rules are actual post conditions of a use case.

However, there are a huge number of business rules that apply to a single class, attribute, or operation. These business rules can appear as constraints on the class diagram (such as the one shown in figure 1). Constraints appear in brackets and appear as part of a method, association, or as notes applied to the class. Constraints are usually specified in Object Constraint Language (OCL) although there is no need to be so rigorous in most cases.

Figure 2: Employed as an attribute

Implementation

Many Model Driven Architecture (MDA) products utilize this OCL to generate program logic. The translation of business rules in constraints on the class diagram is critical to building applications in a MDA environment. This logic is translated from the OCL in the platform independent model (PIM) to a high-level langauge in the platform specific model (PSM). The platform specific model could be a programming language such as Java, C#, C++, or Delphi.

In the Java world, Business Rules are increasingly being captured in beans that can be managed and changed to meet changing business climates. These beans have interfaces that allow the business logic to be manipulated to achieve the desired business effect. Strategies exist for determining how these beans will be fired, filtered, and combined.

However you choose to implement your business rules, capturing them as part of your requirements and models is bound to be the hard part. Business rules require a huge amount of domain knowledge. Domain experts of all sorts are likely to be contributors to this part of any system. New or changing business rules are often the reason that new systems are brought in to replace old ones.

Conclusion

The agile business requires extensible systems which reflect a changing business climate instantly. For example, todays discount may be tomorrows premium. Modeling and isolating business rules is a necessary part of building this environment. Modeling allows the business rules to be validated before the system is built. The UML supports the modeling of business rules as part of use cases and class diagrams.

Bibliography

[Francis 2003]Francis, Tim, et al. Professional IBM WebSphere 5.0 Application Server, Wrox, 2003

[Nicola 2002] Nicola, Jill, Mark Mayfield, and Mike Abney, Streamling Object Models, Prentice Hall, 2002
Excerpt in The Coad Letter 89