A decision table is a tabular form of business logic modeling that represents all the possible combinations of conditions. Especially, in a complex system when multiple business rules share the same set of attributes, a decision table can be used to easily map all the scenarios.
A decision table has columns and rows to map conditions and their actions. Therefore, different conditions and actions can be used to build each business rule without missing all the possible combinations.
To explain all the combinations further, let us consider a scenario of determining the scholarship percentage according to a student’s score, age, and the state/ territory.
These are the set of attributes and the possible number of values for each attribute.
| Attribute name | Possible values | Possible numbers of values |
|---|---|---|
| score | score >= 80, 80 > score >= 60, 60 > score >= 40, score < 40 | 4 |
| age | age >= 18, 18 > age >= 12, age < 12 | 3 |
| states and territories | VIC, NSW, QLD, TAS, WA, SA, ACT, NT | 8 |
One of the combinations is,
if score >= 80 and
age >= 18 and
states and territories is VIC
then
scholarship percentage is 80
In this example, altogether there are 96 possible combinations of business rules.
4 x 3 x 8 = 96
We can model these combinations in the traditional way as well as in a decision table.
Modeling a Logic in a Decision Table
Let us model the scenario, using the same attributes and possible values from the above table.
The following snippet shows the traditional approach of writing business rules using a programming language. Out of 96 possible combinations, we have only shown 6 combinations here.
We can map the same combinations in a decision table in FlexRule Advanced Decision Management Suite. The tabular form is clear and easy to understand.
The following snippet shows a decision table with 33 combinations out of 96.
If we enter data of a student from VIC, who is 18 years old with a score of 66, the scholarship percentage is 78%.
As you can see, using the traditional approach of hard coding all the possible combinations can cause many issues in an application.
Traditional Approach vs Decision Tables
A software developer writing the logic into the application using a programming language is the traditional approach. This can cause multiple problems in large-scale projects as well as expanding the project.
| Traditional Approach | Decision Tables |
|---|---|
| Requires the knowledge of a specific programming language | Does not require a programming language |
| It is a part of the codebase making it harder to make changes without affecting the codebase | Separated from the application codebase making it easier to make changes without affecting the codebase |
| Hard to understand complex scenarios | Complex scenarios can be mapped easily in a tabular form making it easier to undertested |
| Hard to map all the combinations of a scenario and test them | All the combinations can be mapped in a tabular form and test them one-by-one |
| Domain experts and business analysts cannot update the code according to the changes in business rules | Domain experts and business analysts can update the code according to the changes in business rules as there is no need for coding |
| Can be easily missed all the possible combinations as they are written in the form of sentences | All of the possible combinations can be modeled easily as there is a visual representation in tabular form |
Is Decision Table for simple business rules?
The answer to this question is a firm no! Dispite the simplicity of decision table and how they easily allow you to model business rules, this does not mean it is only for simple business rules.
Decision tables allow modeling very complex business rules while they look and simple and understood easily. Decision table supports complex condition and rules entry. This will allow different types of value entry in the cells e.g. range, constant and literal values as well as formula and expressions.
On the other hand, you can combine complex boolean operators in condition columns. And also, building and reusing complex expressions with boxed expression as part of either condition or action columns will allow you to simply put any complex logic in any decision table's structured model.
And on top of all of these, decision tables allow semantic and structural validation at design time, which will enable you to understand if you have a correct and complete decision table.
And when dealing with complex data i.e. relations and collections of data as part of the condition columns, monadic operators will allow you to deal with any complex data related logic. For instance, in this decision table using monadic operator we identify duplicates in the dataset.
And for complex scenarios that there is a need for collaboration between multiple decision tables, any types of orchestration models e.g. decision requirement diagram or in short DRD can help you.
Book a Custom Demo
Conclusion
The traditional approach is to integrate the business rules defined by the business analysts and domain experts, into an application using a programming language by software developers. When the new changes are required and the solution needs to be scaled, updating the business rules in the created solution can be hard to understand, consuming the time of all the stakeholders. That is why using decision tables to model business rules is a better option as it creates a common ground for all the teams in a project by making it easier to understand, enhancing the accuracy, and taking lesser time to make changes without using any programming language. A Decision table can simplify modeling business rules.
Published October 8th, 2020 at 08:28 am
Product Engineer at FlexRule – She focuses on analyzing and understanding customer requirements and identifying process. She also works in the emerging areas of technology such as Decision Robotics, testing and ensuring that the product functionalities align with the customer requirements.
Leave A Comment
You must be logged in to post a comment.