Validation Options - Gnorion/BizVR GitHub Wiki

The purpose of the validator is to check a set of rules for logical inconsistencies. To do this you send validator a json file containing the rules you want validated. Rules are grouped into tables and tables are grouped into decisions. Decisions may also be grouped into projects. The json file structure reflects this:

• A project is one or more decision
• A decision is one or more ruleset (table)
• A table is one or more rule

You have some options when sending rules to the validator:

1. Send One Entire decision

• The json file will contain a single decision in the decisions array.
• All its tables (rulesets) will be in the rulesets array
• Any declared inputs will be listed in the decision inputs array. For DMN these will be the ovals on the diagram.
• Any declared outputs will be listed in the outputs array. DMN does not specify outputs.
• Test cases will be generated for the entire decision using the inputs specified

2. Send One table

• The json file will contain a single decision in the decisions array.
• But now the ruleset array will contain only one table
• The decision inputs array will contain all of the conditions listed in the table
• The decision outputs array will contain all the actions listed in the table
• Test cases will be generated for the single table only using the inputs specified

Normally you would perform validation on individual tables (as you create them) and once all the tables are created you would perform validation on the entire decision and all its tables

However there are some additional options that you can use

3. Send Multiple Decisions

Because the json file has an array for decisions you can send it more than one decision at the same time.

• Each of these decisions can be a single table or a complete set of tables for a decision or any arbitrary set of tables
• Each decision in the decisions array needs to follows the requirements listed above in #1 or #2
• Each of these separate decisions would need its own separate inputs array listing the relevant inputs to that particular decision.
• Test cases will be generated based on the inputs specified

For a DMN model you could divide up the tables into separate decisions and send them to validator as separate entries in the decisions array.

When you send multiple decisions to the validator it will apply all of its analysis rules to the entire set of rules.

This means that if there are conflicts across decisions these will be detected.

Example Suppose you have this decision model

when you view the entire decision diagram you can validate the entire model - all the tables are sent the the validator as a single decision

When you view an individual table such as this

You can validate just that table.

But its also possible to validate parts of the model.

Validate Table 1 and Table 2

For example you might decide to validate just the tables in the red box

In this case you would send a single decision (in the decisions array) and only those two tables would be included in the ruleset array.

The decision inputs in this case would be A, B and T1 (the result that would come from table 3 if it were present).

Test cases will be generated far the variables A, B and T1

Validate Table 2 and Table 3

Alternatively you might choose to validate this portion of the decision:

In this case the json decisions array will contain one decision that has the two tables T2 and T3 and the inputs array will contain B and C.

Test cases will be generated for variables B and C

Validate Table 1+Table 2 and Table 3 as two separate decisions

Finally you might decide to validate two decisions at the same time.

In this case the json file would contain TWO decisions in the decisions array.

The first would be for Table 1+Table 2 and the second would just be for Table 3

While this is technically possible its better to do two separate validations for the decision of interest rather than a single combined validation.

VV will show the dependencies as

Validate Table 1 and Table 3 (omitting Table 2)

T1 and T3 can be sent to the validator as two separate decisions or as one. Either way the validator will detect that T1 and T3 and are not connected (because T2 is missing)

Also note that the tables you send to the validator do not need to be part of the same model - you can send any set of tables that come from any models anywhere. VV will still analyze them. If there are conflicts, VV will tell you. If the tables have nothing in common VV will tell you that too.

Validate Table 1, Table2 and Table 3 as three separate Decisions

Each table can be sent to the validator (in a single json file) as three separate decisions by making three entries in the decisions array (one for each table). Validation will proceed as normal. However the connection graph will look like this (because as separate decisions, some extra inputs are required)

And because now we have include all the table, everything in the diagram connects

The high level structure of the json would be as follows:

Each decision in the decisions[] array now contains only one table (though you can have as many as you want)

Generating Test Cases for multiple Decisions

Also when you send in separate decisions in the decisions[] array you will get back test cases separated by decision. For example for the model with T2 and T3 which has two separate decisions in the array you get separate test cases for each.

You can see the inputs are different for each decision - but since the tables only have a single rule there's not much test data generated.

Similarly when you pass in three separate decisions (T1 and T2 and T3)you get back separate test cases for each decision:

and if you add an extra rule to table 1 (T1 and T2 and T3 with more rules) then you will get more test cases

DT1: R1: if T2 = 'yes' and A > 0 then output is 'yes'    
DT1: R2: if T2 = 'no' and A < 0 then output is 'no'    
DT2: R1: if T1 = 'yes' and B > 100 then T2 is 'yes'    
DT2: R2: if T1 = 'no' and B < 100 then T2 is 'yes'    
DT3: R1: if C in [0..100] then T1 is 'yes'