◷ Reading Time: 7 minutes
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.
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|
How many possible combinations exist in this sample? The answer is: 3*2*2=12
So, in order to code the scenario, you have to cover 12 rules.
The problem of the 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 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:
- Customer type (Values: Wholesale, Retail)
- Customer paid cash (Values: Y, N)
- Number of units purchased (Values: >=50, <50)
- 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:
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 into a table like this:
(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.
To add a new Decision Table document,
Document Types --> Decision Logic --> Decision Table
Once you add a document, this will be the window.
Decision Table Properties
- Name: Name of Decision Table
- Enabled: Whether it is active to use
- Process All Rows: Single hit/ multi-hit, whether you want to process all the rows after matching a row
- Use Agenda: Does decision pushes the consequences (actions) to Agenda? If so true, otherwise false.
- Glossaries: Link Business Glossaries or Boxed Expressions to the decision table
- Resources: List of resources to reference
- Function: Expression that defines a function to be evaluated after the Decision Table execution is finished
- List Source: Source of the items (list) to iterate through
- Item Name: Name of the parameter that references items in the list
- Order: Multiple hits policies for a single output
- Aggregation: Aggregation for multiple hits policy for a single output
- Variable Definition: List of input and output parameters
- Types Definition: List of Types and Functions
The toolbox has the following items.
At the top menu, you can see the following items.
- Zooming: Zoom in or zoom out
- Export to image: Export the document to an image
- Parameters Binding Wizard: Creates an association between the Decision Table’s columns and parameters.
- Add/ Delete columns and rows: Add/ Delete columns and rows in the decision table
- Negate: Negate a value or expression
- Expression Builder: Build expressions
- Business Glossary: Link Business Glossaries and Boxed Expressions
- Properties: Properties of a node
- Variable Parameters: Define variables and parameters
- Import: Import Decision table from an Excel sheet
- Compile to execution plan: Show the XML version of the decision table
If you click on a column, its property window will appear. The properties vary depending on the column type.
Import a Decision Table from Excel
See Decision Table Importer to know how to import a Decision Table from an Excel file.
Sample Decision Table
Download the sample Decision Table (Sample-decision-table.zip) using the attachment.
- Preparing a decision table
- Modeling decision table
- Decision Model and Notation – decision table
- Check overlaps
- Decision Table final logic
- Multilingual decision table
- Decision Table 101