Decision tables are a concise visual representation for specifying which actions to perform depending on given conditions. They are algorithms whose output is a set of actions. The information expressed in decision tables could also be represented as decision trees or in a programming language as a series of if-then-else and switch-case statements.
Overview
Each decision corresponds to a variable, relation or predicate whose possible values are listed among the condition alternatives. Each action is a procedure or operation to perform, and the entries specify whether the action is to be performed for the set of condition alternatives the entry corresponds to. To make them more concise, many decision tables include in their condition alternatives a don't care symbol. This can be a hyphen or blank, although using a blank is discouraged as it may merely indicate that the decision table has not been finished. One of the uses of decision tables is to reveal conditions under which certain input factors are irrelevant on the actions to be taken, allowing these input tests to be skipped and thereby streamlining decision-making procedures. Aside from the basic four quadrant structure, decision tables vary widely in the way the condition alternatives and action entries are represented. Some decision tables use simple true/false values to represent the alternatives to a condition, other tables may use numbered alternatives, and some tables even use fuzzy logic or probabilistic representations for condition alternatives. In a similar way, action entries can simply represent whether an action is to be performed, or in more advanced decision tables, the sequencing of actions to perform. A decision table is considered balanced or complete if it includes every possible combination of input variables. In other words, balanced decision tables prescribe an action in every situation where the input variables are provided.
Example
The limited-entry decision table is the simplest to describe. The condition alternatives are simple Boolean values, and the action entries are check-marks, representing which of the actions in a given column are to be performed. A technical support company writes a decision table to diagnose printer problems based upon symptoms described to them over the phone from their clients. The following is a balanced decision table. Of course, this is just a simple example, but even so, it demonstrates how decision tables can scale to several conditions with many possibilities.
Decision tables, especially when coupled with the use of a domain-specific language, allow developers and policy experts to work from the same information, the decision tables themselves. Tools to render nested if statements from traditional programming languages into decision tables can also be used as a debugging tool. Decision tables have proven to be easier to understand and review than code, and have been used extensively and successfully to produce specifications for complex systems.
History
In the 1960s and 1970s a range of "decision table based" languages such as Filetab were popular for business programming.
Program embedded decision tables
Decision tables can be, and often are, embedded within computer programs and used to "drive" the logic of the program. A simple example might be a lookup table containing a range of possible input values and a function pointer to the section of code to process that input.
Input
Function Pointer
"1"
Function 1
"2"
Function 2
"9"
Function 9
Control tables
Multiple conditions can be coded for in similar manner to encapsulate the entire program logic in the form of an "executable" decision table or control table. There may be several such tables in practice, operating at different levels and often linked to each other.
