◷ Reading Time: 6 minutes
In this sample project we are going to assess the drivers’ risk levels. There are different types of drivers, each with its unique set of risks. For example, young drivers are more likely to be involved in accidents than older drivers.
The challenge is to clearly understand each level of assessment and prepare an approach that is easily modifiable.
Let’s have a look at how we can determine the drivers’ risk level and also refactor a decision table and how we can use them to improve overall performance and transparency.
In this scenario, the driver risk level is determined based on multiple criteria such as the driver’s age, car type, and whether the car has modifications or not.
The decision table should be written carefully to prevent the repetition of logic to their respective driver risk profiles.
The following Decision Table (DriverRiskLevelRepetitive.xml) shows all combinations that can be possible.
Refactoring the Decision Table
Since certain types of cars have a higher level of driver risk, we can group them together and then perform refactoring for each group separately. This will allow us to minimize inconsistency when editing the rules.
Even though this decision table is more compact than the previous decision table, it still contains logic repetitions. As you can see here, both the “Car Type” and “Has Modification” columns have repetitive logic.
This current decision table still can easily lead to inconsistent rules and is very hard to maintain. Because of that, we can further refactor this decision table into two decision tables by considering the car type risk level and driver risk level.
- Determine the risk of a vehicle type
- Determine the driver risk level
This decision table splitting can also test against previous decision table.
Driver Risk Level Refactor.xml
Table to determine car type risk level
Based on the car type and whether the car has modifications or not, car type risk level will be determined. This Car Type Risk Level will be used in the following decision table as an input.
Table to determine the driver risk level:
Based on the car type risk level which is derived from the previous decision table, and the driver’s age, the driver risk level will be determined.
These Smaller decision tables are easier to read and can be more easily maintained and updated. Decision tables can be smaller and more consistent when refactoring, and it leads to an overall improvement in performance.
Running the Sample
- Open the file Driver Risk Level Refactor.xml
- Click on the Logic Run template.
- Click on any given template.
- Debug the sample by clicking on the debug button in the Logic Run Template window.
- You can click the ‘Next Step’ button to go step by step to follow the flow.
- Now you can see the output values in the ‘Parameters’ window.
The Flow Design
The following facts are define in order to handle input and output data.
- Business Glossary (BusinessTerms.xml)
Terms are a fundamental part of business language – they have a Domain (type) and an Expression associated with them. Once the terms are defined within the business glossary we can use throughout the Decision Tables. In every Decision Table, you need to link your business glossary with decision table. Once you
Test cases are created based on the following input data.
Test cases can be run against the initial business logic as well as in the refactored decision table outputs.
These test cases were created by importing the above excel file.
After importing test cases run tests by clicking on “Run Tests” icon.
Download the project
Use the attachment at the end of the page to download the sample project.