Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

...

1Main

Ask yourself the question what the main decision is. If you think of more than one answer, split these decisions if possible.
For instance, if you main decision is "the amount and duration of a child care benefit" or "the fee for a small building permit" you are are actually modeling two decisions. Design them separately and reuse attributes that accommodate both decisions.

2Sub
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.
3CircularityAvoid 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.

...

 

Note

Note that a decision is not bound to be a Boolean. In general, there are three types of decisions:

  • 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).

...

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 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:

...

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.

There are two typical scenarios in which default value expressions are used:

  1. 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.
  2. 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 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 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.

...