Page History
This chapter discusses typical design considerations when designing and implementing decisions using Blueriq.
| Table of Contents |
|---|
Setting a boolean value?
When modeling a decision that is limited to a small number of values (for instance Boolean), there are multiple possibilities to achieve this:
- Using a constant value and a business rule
- Using two business rules
- Using a decision table
Using a constant value and a business rule
 |  |
|---|
Using two business rules
|  |
|---|
Using a decision table
 |
|---|
| Info |
|---|
It is tempting to skip the column for male, but it is strongly advised to model a complete table. |
| Info |
|---|
It is perhaps even more tempting to skip the [ ]-column for ELSE, but it is also strongly advised to model an ELSE-column whenever the values are not restricted by a value list. If Applicant.Gender was in fact limited by a value list consisting of the values Male and Female and it is obvious the set will never expend, the ELSE-column would have been otiose. |
What to use?
The choice of method is often based on the preference of the business engineer. General recommendations are listed below:
- Whenever the result depends on multiple input values, it is best to use a decision table.
- Whenever the result is a calculation, it is best to use a form with a business rule.
- It is recommended to formally decide which method to use and capture that in an architecture document. A consistent use of a style throughout a project will help the maintainability of a project. There are many roads that lead to Rome, but within one project it is best if all business engineers follow the same road.
Size of decision table
With multiple inputs or value categories decision table can get very large in size. Decision tables that are too large in size are not easy to oversee and by that to understand. In general you can state that a table should have a maximum of 12 columns. When the number of columns exceeds this number it is advised to split up the table.
Splitting up a decision table can be done by using sub decisions and sub decisions can be created by adding an extra attribute.
Order in a decision table
When designing a decision table, it is often worth considering in which order the different conditions (rows) should be declared. To illustrate this, see the two semantically equivalent decision tables below.
 |
|---|
 |
One might argue that - because of the fact that the decision tables are semantically equivalent - it does not matter if you model the first or second table. However, there are two differences that are worth addressing and should be taken into account when designing decision tables:
- If the party that uses this decision views its customers mostly by their gender, the first table is preferred. If they view their customers in age categories, the second is preferred.
- In general the legibility of a decision table improves when the conditions are declared with the number of condition alternatives increasing from top to bottom. So even if the first argument of gender and age categories does not apply, there is a theoretical preference for the first table. This is illustrated below.
Decision table or data rule?
text
Attributes and (reusable) expressions
text
Decisions in a process?
...
| Children Display |
|---|
| Panel | |||||||||
|---|---|---|---|---|---|---|---|---|---|
|
Overview
Content Tools