Summary

Dialogues can be strongly dependent on business rules. These business rules are intended for the realization of intelligent forms of an application. Some business rules needed for intelligent forms are from the domain layers, as they concern the core logic of the business. Other rules are created just to make the page more dynamic and give the end user a better experience. The latter are located in the user application layer.

In this example we regard a problem diagnosis for house repairs. When something breaks in your house you want to indicate the problem to the landlord so that a propert repair can be scheduled. What is exactly broken can not be known by the inhabitant, but is important to know so that the appropriate equipment is brought for the reparation.

Problem

When there is a problem in the household, the landlord can be called with a desciption of the problem. The landlord asks clarification questions in order to dispatch the correct repairman. In case that the user comes to a Blueriq application with the problem, the same clarification questions need to be asked. The difference to a standard input form is that the next question to be asked to the end user is highly dependent on the answers give so far. The end user should only get relevant questions and as few as possible to come to a conclusion about the problem.

A great example is the case of the pilot light in the water boiler. If this small fire is distinguished, no warm water is produced and so components as the radiator or the shower may not work. The inhabitant however has no idea what a pilot light is, and goes to the Blueriq application with a problem in mind: my house is cold. What questions should we ask the end user in order to deduce that there is a pilot light problem?

Examples could be:

• Do you hear water running when you turn the radioator on?
• Is there warm water in the shower?
• Does your light turn on?
• Do you see a small flame in the water boiler?
  • Possibly preceeded by "Do you know where your water boiler is and how it looks like?"

In Blueriq both the domain logic and page logic is modelled using Business Rules and Decision Tables. In an example such as this, the preconditions on the page might be heavily dependent on domain knowledge. We have to think carefully on what is page specific and belongs in the interface layer, and what is domain knowledge and belongs in the domain layer.

Important factors for this problem is the truth maintenance of the rule engine, The end user has the possibility to change earlier answers and there is no manner to handle this in the flow in a maintainable manner. We therefore only consider patterns which derive system-set values.

Solutions

External rule

The precondition whether a question should be shown to the user can be determined by an attribute which uses an external rule. The external rule uses much domain knowledge to derive its answer, and it has to be aligned with other external rules for different attributes. This can be challenging, if not impossible to achieve. Furthermore is the knowledge hidden in code, and not in Blueriq.

Expand to see the External Rule pattern characteristics

	Type	Score	Description
Knowledge characteristics	User set or System set	System	An external rule is part of the truth maintenance mechanism and any result is system-set.
	Parameters or complex model	Complex Model	On the external rule parameters can be defined which trigger the truth maintenance. In code you however access to the complete profile, and can use any attribute during the calculation. Although it is best practice only to use the truth maintenance parameters, we classify this as complex model.
	Enhanced by Blueriq Functionality	/	External rules are part of truth maintenance mechanism. However, there are dependencies for the truth maintenance parameters, but there is no way of knowing what happens in the external rule or what attributes are actually needed. In these cases it is not possible to rely on truth maintenace mechanism.
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality.	Focus on Internal or External Use	Internal	External rules are only used by Blueriq.
	Low Implementation complexity		There is a simple hook, and the code that needs to be written is simple. The difficulty lies with keeping the code in line with the model, as the external rule reads attribute values in a hard coded manner.
	Internals invisible (encapsulation)	/	The internal code is not visible from the model. From the code however, you can view the entire model.
	Autonomous		As the complete profile can be input to the external rule, changes in it may lead to side effects during the execution of the external rule. In addition, code and models are highly coupled so it is difficult to test the model autonomously. There is always a strong dependency with code.
	Highly Testable		Unit tests can be written in code. the difficulty lies in the hard link to the defined model. When the model changes, the code might break as it is hard-coded what attributes are needed.
	Highly Reusable		Once you have the external rule defined, then you can distribute the definition in a library and use it simply on any desired attribute.The domain needs however be very similar, as the code reads the values of certain attributes in a hard coded manner. When different attributes are needed for another application, then the code needs to be changed.
	Out of the Box		An external rule requires writing of code.
Deployment characteristics	Part of Application or Separate Deployment (=deployment)	Part of Application	The code has its own life-cycle and is deployed separately. It is however strongly coupled with the domain of an application. This leads to the code moslty only be used by one application. Therefore, we regard it as part of the corresponding application.

Module with Flow

We split the application into two modules, one with all logic of the domain, and one containing logic for the application. The latter is stacked on the former to make use of its content. The advantage of this approach is that the rule engine can do its work and supporting features of Blueriq are available. With a clear differentiation in module, and in naming of the domain it can be clear to the business engineer what is located where. What is not clear is what part of the business domain is internal. This can lead to unwanted side effects when refactoring.

Expand to see the Module with Flow pattern characteristics

	Type	Score	Description
Knowledge characteristics	User set or System set	System set	As the underlying module is included, the rule engine can do its work.
	Parameters or complex model	Complex Model	The entire function can be used as output. There are no clear input parameters defined.
	Enhanced by Blueriq Functionality		This pattern is enhances by Blueriq functionality, as model validations, the Decision Requirements graph, dependencies and specifications keep working.
Maintainability characteristics It should be possible to quickly make changes to business rules independent of other functionality.	Focus on Internal or External Use	Internal	This pattern purely covers internal use. The business function is included in a Blueriq library.
	Low Implementation complexity		Including a library is done quickly and easily. The complexity can however increase drastically in case that many libraries are used and stacked, or if many projects need updates from the same library. When many specializations are present, then the complexity is high.
	Internals invisible (encapsulation)		All internals are visible and increase the mental load of the business engineer. Mistakes may be made when elements are used which were not supposed to be used.
	Autonomous		The business rules are executed in the context of the main application. When the main application uses internals of the library, then making changes generates side effects.
	Highly Testable		The library can be tested on its own, either by unit tests in studio or with special test applications. When the application gets larger testing larger chunks of model can get difficult.
	Highly Reusable		Including libraries by hand can be time-consuming when the number of projects becomes large. The Blueriq Control Center can help with many projects.
	Out of the Box		This is possible without custom coding.
Deployment characteristics	Part of Application or Separate Deployment (=deployment)	Part of Application	The library has to be imported into a project and becomes part of it.

Issues and considerations

With the current possbilities in Blueriq, we advice to use Decoupling Pattern 1: Module with Flow [editor]. One has to clearly indicate what attributes can be used and act as interface and which do not.

One approach which one may look at are Decision tree. With this approach there exists no page specific logic at all, as the page content is created dynamically based on rules in the domain layer. We regard decision trees as a pattern which specifically addresses the separation of the user interface layer and the domain layer, and it can not be used in a different context. One drawback of the decision tree is that all control of the page structure is transfered to the rule engine. If the generated pages are not satisfactory, no tweaking is possible.