• Created by Unknown User (v.bingley), last modified by Unknown User (a.jansen) on Apr 01, 2021

Explanation

This rule checks the default value of all attributes to verify none use a decision table. The usage of a decision table as a default value is a bad practice and support for this will be removed in a future Blueriq version. 
This functionality is a piece of Blueriq legacy, but it confuses inexperienced users who see this and think it is necessary to link the decision table to the attribute (the inference engine takes care of that).

Possible improvements

Setting up proper decision tables, ideally each attribute should only be derived in a single decision table, even if this table grows too large, in which case sub-tables are considered a best practice.

The solution is usually very easy, remove the default value from the attribute. However, depending on the model, in some cases this could lead to a change in behavior in which case the decision tables should be refactored more thoroughly. 

Example

  • No labels

1 Comment

  1. Frank van der Vaart

    I totally agree that DT's should not be used as default for an attribute for no reason other than that it is 'easy to see the logic for that attribute'. Doing so means interfering with the inference engine strategy: it removes the DT from the logic pool at the 'System set'-level and demotes the DT to the 'Default'-level. That may seem harmless, but is indeed considered a bad practice.
    However, there are situations where it is done intentionally and for a good reason: An abstract base entity can have an attribute with a default decision table, and one or more derived entities can also have a decision table for that same attribute. When that attribute is needed in the runtime, the inference engine will first try the 'specific' decision table for the derived entity, and when that fails or is not present at all, it will try the 'generic' default decision table. That is perfectly legitimate, and in my opinion the only correct way in that situation.
    I think that will remain a valid reason to allow a default decision table for attributes of an abstract entity, and support for that should not be removed in future Blueriq versions. It's okay that the BMA raises a code smell, especially if it concerns an attribute of a non-abstract entity.