Decision Table

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

A Decision Table is an approach to modelling logic and rules in a systematic way that will represent all of the combinations of possible conditions for a decision in a tabular form. In a complex system there are scenarios that by using a Decision Table make it easier to model the rules directly from system requirements.

A Decision Table simply maps all the conditions and actions into the columns of a table. Then different rules can use a combination of the available conditions and actions. In an approach where conditions and actions are located in the columns of the table, the Decision Table is called a vertical Decision Table.

All Combinations

In an algorithmic approach, you may code the decision into your application. But the challenge with this approach is implementing all of the possible scenarios in the code in a way that all combinations 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 the intention is of that piece of code
  • Only the developer understands that piece of code
  • It is not easy to implement all of the possible combinations and even harder to write tests that cover all of the possible scenarios
  • Domain experts and business analysts have no control over the implemented logic. They neither understand the code nor can change it
  • Domain experts and business analysts cannot actively contribute in the project by altering or adding new conditions, rules or actions

Decision table benefits

This sort of logic can be easily modeled outside of the application codebase. Using a Decision Table allows the:

  • Separation of the business logic from the codebase and code implementation
  • Giving control of the business logic to domain experts and business analysts
  • Covering all of the possible combinations 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 this story we can construe 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 code to cover all the possible scenarios, you would end up with something like the following, more or less:

DiscountC.png

As you can see, this is still 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 can be understood in a code.

Instead, this logic can be translated to a table like this:

DecisionTableDiscount.png

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

You can ask your application to consider this exact table as a rule model and execute it instead of writing a method to cover the all of the scenarios, as well as multiple different tests to make sure all of the scenarios are covered.

You might ask what is the benefit of this approach?

  • It is simpler to model, understand and implement
  • Easier to test and cover all of the scenarios
  • Less code to write - therefore less prone to error
  • Can be understood by most team members, including Developers, Testers, BAs and business owners
  • Can be altered outside of your codebase by a domain expert or BA who needs to apply a new policy without relying on the 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.

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