Image Removed This chapter discusses typical design considerations when designing and implementing a decision with a limited number of possible outcomes using Blueriq.
...
- Using a default value expression
- Using a constant value and a business rule
- Using two business rules
- Using a decision table
Default value expression
...
Info |
---|
|
Image Added |
Constant value combined with business rule
...
Info |
---|
|
Image Added | Image Added |
|
Two business rules
...
Info |
---|
|
Image Added | Image Added |
|
Decision table
Image Removed |
---|
|
Image Added |
Info |
---|
UI Text Box |
---|
type | note |
---|
It is tempting to skip the column for Male , but it is advised to model a comprehensible table. In most cases, comprehensibility implies completeness (the mere fact that Male is missing from a gender-table might cause suspicion). |
UI Text Box |
---|
type | note
Info |
---|
It is perhaps even more tempting to skip the [ ]-column for ELSE, but it is also 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 redundant. |
...
- Whenever the result depends on multiple input values, it is best to use a decision table.
- Whenever the result is a calculation, it is probably best to use an attribute displayed on a form with a business rule or default expression.
- When using justifications (and you will most likely use them, since they are a best practice), the default value expression has limits; only one justification can be used, regardless of the outcome.
- 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.
...