Explanation
This rule compares all conditions in a decision table for gaps between conditions. If there is a gap between two conditions an issue will be created. An issue can consist out of multiple warnings since multiple gaps may exist in a decision table.
The BMA checks the decision tables for
- missing values
- missing unknowns ('?')
- values that will never be reached
- the use of a DON’T CARE ('*') in combination with values
- multiple decision tables that source the same attribute (warning)
We estimate that resolving this issue will on average take 10 minutes.
Possible improvements
What are characteristics of a good decision table? In Designing decision tables, two important ones are mentioned: Exclusivity and Completeness. Try to be complete and exclusive in your decision tables to make sure that all possible situations are covered and lead to exactly one conclusion.
Parameters
| Parameter name as seen Sonarqube report | Explanation | Message in Sonarqube report |
|---|---|---|
| MultipleUnrelatedSources | Check for attributes that are sourced by multiple unrelated decision tables | Found issue with Decision Table [...] : Warning: attribute %s is sourced using decision tables %s that do not have the same first condition |
| DuplicateUnknownAlternative | Checks for duplicate coverage of '?' | Found issue with Decision Table [...] : alternative in row %d at column %d tests for ? which has already been covered in alternative in row %d at column %d |
| RedundantBracketsAlternative | Check for unnecessary coverage of '[]' | Found issue with Decision Table [...] : alternative in row %d at column %d with [] is present when the full domain was already covered |
| OverlappingDomain | Check for overlapping ranges | Found issue with Decision Table [...] : $DOMAIN overlaps alternative in row %d at column %d |
| DuplicateStarAlternative | Checks for duplicate coverage of '*' | Found issue with Decision Table [...] : alternative in row %d at column %d tests for * which has already been covered in alternative in row %d at column %d |
| DuplicateBracketsAlternative | Checks for duplicate coverage of '[]' | Found issue with Decision Table [...] : alternative in row %d at column %d tests for [] which has already been covered in alternative in row %d at column %d |
| MissingUnknown | Check for missing '?' | Found issue with Decision Table [...] : alternatives in row [...] from column {X} to {Y} do not test for ? |
| IncompleteDomainAlternative | Check for incomplete domain coverage | Found issue with Decision Table [...] : alternative(s) in row %d at column %d does / do not cover $DOMAIN |
| RedundantAlternative | Checks for unnecessary coverage of a value | Found issue with Decision Table [...] : alternative in row %d at column %d tests only values that have already been tested and will therefore never be true |
| ImpossibleUnknownAlternative | Check for unnecessary coverage of '?' | Found issue with Decision Table [...] : alternative in row %d at column %d tests for ?, however the condition can never be unknown |
| ContradictingAlternative | Check for alternatives that can never be | Found issue with Decision Table [...] : alternative in row %d at column %d is never true |
| IndeterminateAlternatives | Check for overlap and gaps | Found issue with Decision Table [...] : alternative(s) in row %d at column %d contain(s) logic based on $COMPARISONS, this may result in overlap (and gaps) |
| InvalidStarAlternative | Check for wrong usage of '*' | Found issue with Decision Table [...] : alternative(s) in row %d at column %d specify * in combination with other logic, which violates the basic principle of exclusivity. $SUGGESTION |
| OutsideAllowedDomain | Check for values that are outside the allowed domain | Found issue with Decision Table [...] : alternative in row %d at column %d tests only for values that are outside of the condition's domain and will therefore never be true |
Example 1
Each business engineer will (and should) immediately see that this decision table is BAD. It is a simple example to illustrate how the rules work, also for (much) bigger tables that are difficult for humans to oversee.
It will result in these code smells:
...because the age 18 is missing,
...because the decision table won't come to a conclusion if the age is unknown, and
...because the decision table is not exclusive when a person is below 18 and married.
Example 2
Another example, just as obvious:
These decision tables will result in this warning:
Example 3
A new example, to illustrate some nice new checks that were introduced with BMA 2.5:
Each cell with a blue border represents a situation that is outside the range of possible values, and will therefore never be reached. The BMA is now aware of functions with a limited value domain and gives a code smell on each of them, e.g.
The BMA also detects expressions that can never be unknown:
As you can see, the code smell now also gives the exact 'coordinates' of the corresponding cells in the decision table, so you don't have to search through all the alternatives yourself.
The first two rows of this decision table contain expressions that can (in this case obviously) be simplified, and the BMA suggests how.
Combined analysis of Decision Tables
When decision tables grow large, a common practice is to split the decision table into multiple decision tables, each sourcing the same attributes and using the same condition expression in the top row. The alternatives in the top-row can then be distributed over these multiple tables. This setup achieves the same behavior as the single large decision table but may be easier to maintain. For the BMA to properly detect gaps and overlap in this case, it will merge all decision tables that source the same attributes. It is expected that all these tables have the same condition expression in the first row; if this is not the case then a warning will be reported (this warning can be disabled using the "isMultipleUnrelatedSourcesActive" configuration parameter).
If there are any rule violations detected in the merged alternatives of the top-row, the reported messages will include all decision table names that are involved. For example, consider the two tables below which will be analyzed together as if they represent a single table:
A warning is reported for the "< 40" alternative in "DecisionTable2":
- DecisionTable2 (analyzed together with DecisionTable1): alternative in row 1 at column 1 overlaps < 25
The row/column numbers correspond with "DecisionTable2" in the above message, and the parenthesized note mentions the other table "DecisionTable1" that was part of the combined decision table. This is done to make it apparent which other decision tables have been used during the analysis, as without this information the warning would seem incorrect.
For messages that are reported on the complete first row (for example when the first row has gaps, as in the example above), the table names are all mentioned, with the column numbers corresponding with the total number of alternatives:
- DecisionTable1 and DecisionTable2: combined alternatives in row 1 from column 1 to 3 do not cover >= 40
Overview
Content Tools