This chapter discusses the use of logic throughout Blueriq. The role of decision requirements graphs when designing and running is discussed, followed by prime examples of 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 th 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 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 | For each identified decision, determine if the decision is preferably built up in 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. |
| 5 | ... |
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 4. 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 recurrenc and a calculated risk score, the risk category is either verylow, 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. 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.
Data rule
Whenever the source of the logic is a (large) set of data, that is preferrably maintained and managed outside of the boundaries of the Blueriq model, a data rule might be used. 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.
Overview
Content Tools