Decision Table

From FlexRule Wiki
(Redirected from Decision table)
Jump to: navigation, search

A decision table is an approach to model logic and rules in a systematic way that represents all the combination of possible conditions for a decision in a tabular form. In a complex system there are scenarios that using a decision table makes it easier to model the rules directly from system requirements.

A decision table simply maps all the conditions and actions into columns of a table. And then different rules can use a combination of the available conditions and actions. In this approach that conditions and actions are located in the columns of the table, the decision table is called vertical decision table.

All Combinations

In an algorithmic approach, you may code the decision into your application. But the challenge in this approach is implementing all the possible scenario in the code the way that all combination of the conditions with different values are covered. Let's say in a scenario you have the following conditions:

Name Possible numbers of values
C1 3
C2 2
C3 2

How many possible combination exist in this sample? The answer is: 3*2*2=12

So in order to code the scenario, you have to cover 12 rules.

Problem of algorithmic approach

The trouble is when the logic is hard-coded into your application:

  • It is very hard to understand what is the intention of that piece of code
  • Developer only understands the piece of code
  • It is not easy to implement all the combination and even harder to write tests to covers all the possible scenarios
  • Domain experts and business analysts have no control over the implemented logic. They neither understand the code not can change it
  • Domain experts and business analysts cannot actively contribute in the project by altering or adding new condition, rule or action

Decision table benefits

Those sort of logic can be easily modeled outside of the application codebase. Using a decision table that allows:

  • Separation of the business logic from the codebase and code implementation
  • Giving the control of the business logic to domain experts and business analysts
  • Covering all the possible combination by modeling a simple table
  • Building a common ground for all team members: Developers, testers, business analysts, domain experts and business owners all understand a simple table
  • Almost no code is required for testing

A Sample - Discount

Let's consider the following story and create a Decision Table for it.

"A company sells merchandise to wholesale and retail outlets. Wholesale customers receive a two percent discount on all orders. The company also encourages both wholesale and retail customers to pay cash on delivery by offering an additional two percent discount for this method of payment. Another two percent discount is given on orders of 50 or more units."

By analyzing the story we can come up with the following conditions and actions:

Conditions:

  • Customer type (Values: Wholesale, Retail)
  • Customer paid cash (Values: Y, N)
  • Number of units purchased (Values: >=50, <50)

Actions:

  • No discount
  • 2% discount
  • additional 2% discount (4%)
  • additional 2% discount (6%)

Number of rules: 2 values * 2 values * 2 values = 8 rules.

If you are going to write a code to cover all the possible scenarios you would end up something like the following code, more or less.

DiscountC.png

As you can see still this is a fairly simple logic for discount. If you consider the logic that involves more ranging values and more types of customer it becomes more complex than to be understood in a code.

This logic can be translated to a table like this:

DecisionTableDiscount.png

(referenced from: http://www-acad.sheridanc.on.ca)

And you can ask your application to take this exact table as a rule model and executes it. Instead of writing a method to cover the all the scenarios and write multiple different tests to make sure all the scenarios are covered.

You would ask what is the benefit?

  • It is simpler to model, understand and implement
  • Easier to test and cover all the scenarios
  • Less code to write therefore less error-prone
  • Can be understood with almost all team members: Developers, Testers, BAs and business owner...
  • Can be altered out-side of your codebase by a domain expert or BA that needs to apply new policy without relying on software development team
  • Maintaining it can be delegated to other teams that are deriving business
  • Maintenance of application codebase is easier, simply because there is less code to maintain
  • ...and more...

What's next?

  1. Introduction to decision table
  2. Preparing decision table
  3. Modeling decision table
  4. Decision Model and Notation - decision table
  5. Check overlaps
  6. Decision Table final logic
  7. Multilingual decision table
  8. Decision Table 101

Tutorials

  1. Decision Table Hello World