Decision tables are a precise yet compact way to model complex rule sets and their corresponding actions.
In the 1960s and 1970s a range of "decision table based" languages such as Filetab were popular for business programming.
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 (or in what order) the action is to be performed for the set of condition alternatives the entry corresponds to. Many decision tables include in their condition alternatives the don't care symbol, a hyphen. Using don't cares can simplify decision tables, especially when a given condition has little influence on the actions to be performed. In some cases, entire conditions thought to be important initially are found to be irrelevant when none of the conditions influence which actions are performed.
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 (akin to if-then-else), other tables may use numbered alternatives (akin to switch-case), 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 (check the actions to perform), or in more advanced decision tables, the sequencing of actions to perform (number the actions to perform).
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 (created by Systems Made Simple).
|Conditions||Printer does not print||Y||Y||Y||Y||N||N||N||N|
|A red light is flashing||Y||Y||N||N||Y||Y||N||N|
|Printer is unrecognized||Y||N||Y||N||Y||N||Y||N|
|Actions||Check the power cable||X|
|Check the printer-computer cable||X||X|
|Ensure printer software is installed||X||X||X||X|
|Check for paper jam||X||X|
Of course, this is just a simple example (and it does not necessarily correspond to the reality of printer troubleshooting), but even so, it demonstrates how decision tables can scale to several conditions with many possibilities.
Software engineering benefits
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.
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.
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.
|'1'||Function 1 (initialize)|
|'2'||Function 2 (process 2)|
|'9'||Function 9 (terminate)|
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.
All listed implementations are distributed under open source licenses.
- A Ruby implementation exists using MapReduce to find the correct actions based on specific input values.
- Decision trees
- Case based reasoning
- Cause-effect graph
- Dominance-based rough set approach
- Semantic decision table
- [dead link]
- Wets, Geert; Witlox, Frank; Timmermans, Harry; Vanthienen, Jan (1996), "Locational choice modelling using fuzzy decision tables", Biennial Conference of the North American Fuzzy Information Processing Society, Berkeley, CA: IEEE, pp. 80–84 Missing or empty
- "A Real CCIDE Example"
- Experience With The Cope Decision Table Processor
- Udo W. Pooch, "Translation of Decision Tables," ACM Computing Surveys, Volume 6, Issue 2 (June 1974) Pages: 125–151 ISSN:0360-0300
- Alexander Williams (2015). "Ruby decision table parser"
- Dwyer, B. and Hutchings, K. (1977) "Flowchart Optimisation in Cope, a Multi-Choice Decision Table" Aust. Comp. J. Vol. 9 No. 3 p. 92 (Sep. 1977).
- Fisher, D.L. (1966) "Data, Documentation and Decision Tables" Comm ACM Vol. 9 No. 1 (Jan. 1966) p. 26–31.
- Giles, John (2012) "The Nimble Elephant: Agile Delivery of Data Models using a Pattern-based Approach" Ch. 13-14. Technics Publications. ISBN 978-1-93550-425-2
- General Electric Company (1962) GE-225 TABSOL reference manual and GF-224 TABSOL application manual CPB-l47B (June 1962).
- Grindley, C.B.B. (1968) "The Use of Decision Tables within Systematics" Comp. J. Vol. 11 No. 2 p. 128 (Aug. 1968).
- Jackson, M.A. (1975) Principles of Program Design Academic Press
- Myers, H.J. (1972) "Compiling Optimised Code from Decision Tables" IBM J. Res. & Development (Sept. 1972) p. 489–503.
- Pollack, S.L. (1962) "DETAB-X: An improved business-oriented computer language" Rand Corp. Memo RM-3273-PR (August 1962)
- Schumacher, H. and Sevcik, K.C. (1976) "The Synthetic Approach to Decision Table Conversion" Comm. ACM Vol. 19 No. 6 (June 1976) p. 343–351
- CSA, (1970): Z243.1-1970 for Decision Tables, Canadian Standards Association