Decision table

Decision tables are one of many ways to display complex sets of rules in a clear manner. Under a rule is to be understood as a provision which actions are carried out in the presence of a given set of conditions. A rule set is a compilation of different rules.

Use

Decision tables are used to clear, complete and consistent describe complex dependencies between multiple conditions and actions to take. Examples are the design of computer programs, programmable logic controllers ( PLC), test data constellations and many others. In addition, the rule set is often represented by a clearer decision tree graphically or in matrices. The table (s), however, are systematic and can therefore lighter than the tree on consistency and completeness can be checked. Here, the workload in the formulation, in consultation with stakeholders and the control must not be underestimated. But there is a huge relief for the project execution, the update service and the cost calculation.

Decision tables are used in a business rule management system (BRMS ) to allow both the definition and the automatic execution of rules ( business rules ). The decision tables are managed there in a business rule repository.

Structure

A decision table consists of four parts:

• A list of conditions to be considered
• A list of possible actions
• One area in which the possible combinations of conditions are summarized
• One area in which each combination of conditions are associated with the activities carried out in each case.

The columns of R1 to R8 denote the respective rules. Using the example of rule 7 will be explained how the rules are to be read: If the condition 3 is satisfied that conditions 1 and 2 are not, then perform the action 4.

Properties

In the following four criteria for the evaluation of decision tables are presented.

Completeness

A decision table is complete when all the possible combinations of conditions are detected. For n conditions, these are combinations. It is evident that the number of possible combinations with the number of terms grows exponentially - at ten conditions, there is already = 1024 combinations. In most cases, however, this does not lead to the same large number of rules, as rules are often redundant. If in spite of all due care or due to changed circumstances, a decision table is not (more) covers all cases, you come to the end without result and action from the last condition column. Therefore, it is useful, especially for computer programs, after the last condition column, an additional column (eg "RF" ) introduce with all conditions "n". Runs the program in this column, such as "Error - incomplete decision table " can be used as an indication action are issued.

Consolidation

A decision table is be consolidated when multiple rules can be combined into one. In the basic pattern shown above, for example the rules R5, R6, R7 and R8 can be summarized as follows: Since the actions to be dependent only on the condition 1 and conditions 2 and 3 are irrelevant, they can be represented by a single rule:

The horizontal lines are called " Do not care character " as " Irrelevanzanzeiger " or. They indicate that the conditions 2 and 3 are not relevant to the determination of the action to be performed if the condition 1 is satisfied.

Generally, there are two rules for consolidation again: these two rules run first two rules for the same action or sequence of actions AND they differ only in a second condition display, so can be consolidated. Instead of the different condition indicator enters the Irrelevanzzeiger in the consolidated rule.

Redundancy

A decision table is redundant if multiple rules contain identical cases. A case, a combination of conditions (e.g., field "j, n, n ' ), which does not have a " do not care " ( Irrelevanzanzeiger ). In the following table, the control R4 ( "j, j, n" and " j, n, n ' ) also includes the case of the rule R3. In this case, both rules lead to the same actions, so is redundancy in front, otherwise a contradiction. Thus, the rule R3 can be omitted without a loss of information occurs.

Consistency (consistency)

As soon as a decision table contains Irrelevanzzeiger, there is the possibility that the table is inconsistent. An example to illustrate:

The rule R3 states that the actions should be performed 3 and 4, as soon as the condition 1 is satisfied and Condition 2 is not satisfied. The rule R4 states, however, that only the 3 action to be performed if additional condition 3 is not met. Both rules so contradictory, the decision table is therefore inconsistent.

Decision tables to test data discovery

After decision tables have been created and validated, you can use them for test data generation. The following strategies are mentioned, such as test data can be generated and how a test suite can be meaningfully restricted.

• All- Explicit Variants
• All- Variants, All- True All- False, All- Primes
• Each-Condition/All-Conditions
• Binary Decision Diagram ( BDD) Determinants
• Variable negation (* it is not received)
• Nonbinary variable domain Analysis

For all processes, the problem always arises between test coverage and the cost of each test. The difficulty in decision tables is that their creation is very complex. Software contains many conditions and usually the specifications are incomplete, so that a derivation of a decision table is too costly. If one has first a decision table created, the above test strategies can be automated apply.

Extensive or complicated sequences can be easily recognized in decision tables, by creating more coherent decision tables. These are actions that can be broken down into further sub- actions themselves, represented as a separate decision tables. The turn-off from the first decision table is then there, for example by the action " further in ET 2 ". It is helpful to make the first decision table so that it represents the direct, fastest or most commonly trodden flow primarily, the branches represented less often trodden. This results in a kind of hierarchy of decision tables. The entire system of processes is thus clear.