Page History
This chapter discusses the use of decisions throughout Blueriq. Some best practices in designing decisions are discussed, followed by prime typical examples of the logic constructs in Blueriq.
| Table of Contents |
|---|
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 th 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 is 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 |
- Boolean decision (you are eligible for benefit X),
- Classification (you will receive category 'medium' for benefit X) or
- Calculation result (you will receive € 100,- per year for benefit X).
| 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. |
| 3 | 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. |
| Info |
|---|
Note that a decision is not bound to be a Boolean. |
...
In general, there are three types of decisions:
|
Typical
...
examples
In this paragraph prime typical 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 4. Design considerations.
Business rule
A prime typical 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:
| Info | |
|---|---|
|
...
| |
|
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 recurrenc recurrence and a calculated risk score, the risk category is either verylowvery low, low, medium, high or decline.
| Info | ||
|---|---|---|
| ||
|
For more information on Decision tables and Business rules, see
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. In most cases, the result will be a number, date or constructed string. See an example below, where the required monthly installment is determined by a formula containing - amongst others - monthly interest and monthly fee.
...
| Info | ||
|---|---|---|
| ||
|
There are two typical scenarios in which default value expressions are used:
- To specify which value must be set to an attribute when no other logic element (decision table or business rule) is applicable for this attribute.
- To specify a value for an attribute in the case that this specification does not contain any condition. For instance, attribute C always equals A+B. In this case, a decision table or business rules is not necessary and not advised.
Data rule
Whenever the source of the logic is a (large) set of data, that is preferrably 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 frequency of change of the content. Whenever the source is not part of the business model but a third party, data rules are used best. A prime example is used in Dutch addresses, where a zipcode combined with a house number will result in a streetname and a city. Most likely the model will not hold all that information in business rules or decision tables, but a data rule can be constructed that will gather the correct data, based on the given zipcode and house number.See Use a Data Rule to derive attribute valuesinferencing mechanism uses a value that is modeled in a data rule, the connection to the source is triggered.
A typical 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.
See How to use a data rule to derive attribute values.
| Panel | |||||||||
|---|---|---|---|---|---|---|---|---|---|
|
Overview
Content Tools