This chapter discusses the use of decisions throughout Blueriq. Some best practices in designing decisions are discussed, followed by prime examples of the logic constructs in Blueriq.
Best practices in designing decisions
When creating a business model in Blueriq, one must always aim to model decisions that can be easily understood by the business. To verify whether the level of complexity of the decisions is acceptable, a DRG can be generated at any time in the design process. This DRG is then used to visualize the decision and its sub decisions and by that give insight to a business engineer and for instance an analyst on how this particular decision is made.
Some best practices when designing decisions are given below. It is not to be used as "the one and only way" but should be treated as a possible means to create understandable decisions.
| 1 | Main | Ask yourself the question what the main decision is. If you think of more than one answer, split these decisions if possible. |
| 2 | Type | Note that a decision is not bound to be a Boolean. In general, there are three types of decisions:
|
| 3 | Sub decisions | For each identified decision, determine if the decision is preferably built up out of meaningful sub decisions. These sub decisions could be reusable decisions - in fact reusable decisions will most likely be sub decisions - but not every sub decision has to be a reusable decision. Think of a complex calculation where intermediate results are never reused but are created nevertheless, for the sake of understandability. |
| 4 | Circularity | Avoid circularity. When decision A depends on the outcome of decision B and decision B needs the result of decision A as input, you're in trouble! When designing decisions top-down circular references can easily be avoided. |
Prime examples
In this paragraph prime examples of Blueriq's logic contructions are given.
Of course it is subject to discussion whether one logic construction or another is used best, but that will be discussed in chapter Design considerations.
Business rule
A prime example of a business rule is a rule that has a boolean as result. Let's say that any applicant can request a certain insurance, and all women receive a discount. In this particular case, a default constant value for Discount is set to False and a business rule can be created that overwrites this attribute to true whenever the applicant is female:
 |  |
|---|
Decision table
A decision table is used best when the possible outcome of the logic is one of many values. Let's say that when applying for a certain loan, a risk category is determined. Based upon applicant characteristics such as recurrence and a calculated risk score, the risk category is either very low, low, medium, high or decline.
|
|---|
Default value expression
A default value, combined with an expression is used most often when the outcome of the logic is determined/calculated by some sort of formula. See an example below, where the required monthly installment is determined by a formula containing - amongst others - monthly interest and monthly fee.
 |
|---|
Data rule
Whenever the source of the logic is a set of data, that is preferably maintained and managed outside of the boundaries of the Blueriq model, a data rule might be used. The reason for this might be the size of the data set or the velocity of the content. Whenever the inferencing mechanism uses a value that is modeled in a data rule, the connection to the source is triggered.
A prime example of the use of a data rule is a discount table where the percentages differ on a frequent base. This way the percentage can be altered by sales without the need for changing and testing the model.
Overview
Content Tools