Decision table

Template:Short description

Play golf dataset
Independent variables				Dep. var
Outlook	Temperature	Humidity	Windy	Play
sunny	85	85	FALSE	Don't play
sunny	80	90	TRUE	Don't play
overcast	83	78	FALSE	Play
rain	70	96	FALSE	Play
rain	68	80	FALSE	Play
rain	65	70	TRUE	Don't play
overcast	64	65	TRUE	Play
sunny	72	95	FALSE	Don't play
sunny	69	70	FALSE	Play
rain	75	80	FALSE	Play
sunny	75	70	TRUE	Play
overcast	72	90	TRUE	Play
overcast	81	75	FALSE	Play
rain	71	80	TRUE	Don't play

Decision tables are a concise visual representation for specifying which actions to perform depending on given conditions. Decision table is the term used for a Control table or State-transition table in the field of Business process modeling; they are usually formatted as the transpose of the way they are formatted in Software engineering.

OverviewEdit

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.

To make them more concise, many decision tables include in their condition alternatives a don't care symbol. This can be a hyphen<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref name="Ross">Template:Cite journal</ref> or blank,<ref name="Snow" /> although using a blank is discouraged as it may merely indicate that the decision table has not been finished.Template:Cn 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.Template:Sfn

Demonstration of “don’t care” symbol

		Rules
Conditions	Feeling energetic?	Template:Yes	Template:No	Template:Yes	Template:No
Conditions	Is raining?	Template:Yes	Template:Yes	Template:No	Template:No
Actions	Stay inside	Template:MaybeCheck	Template:MaybeCheck
	Go running			Template:MaybeCheck
	Tend the garden			Template:MaybeCheck	Template:MaybeCheck

		Rules
Conditions	Feeling energetic?	Template:Sdash	Template:Yes	Template:No
Conditions	Is raining?	Template:Yes	Template:No	Template:No
Actions	Stay inside	Template:MaybeCheck
	Go running		Template:MaybeCheck
	Tend the garden		Template:MaybeCheck	Template:MaybeCheck

The two tables convey identical information, but the second one uses a hyphen as a don't-care symbol for brevity.

Aside from the basic four quadrant structure, decision tables vary widely in the way the condition alternatives and action entries are represented.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> Some decision tables use simple true/false values to represent the alternatives to a condition (similar to if-then-else), other tables may use numbered alternatives (similar to switch-case), and some tables even use fuzzy logic or probabilistic representations for condition alternatives.<ref name="WetsEtAl1996">Template:Cite book</ref> 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).

A decision table is considered balanced<ref name="Snow" /> or complete<ref name="Ross" /> 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.<ref name="Snow">{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

ExampleEdit

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.

The following balanced decision table is an example in which a technical support company writes a decision table to enable technical support employees to efficiently diagnose printer problems based upon symptoms described to them over the phone from their clients.

Printer troubleshooter
		Rules
Conditions	Printer prints	Template:No	Template:No	Template:No	Template:No	Template:Yes	Template:Yes	Template:Yes	Template:Yes
	A red light is flashing	Template:Yes	Template:Yes	Template:No	Template:No	Template:Yes	Template:Yes	Template:No	Template:No
	Printer is recognized by computer	Template:No	Template:Yes	Template:No	Template:Yes	Template:No	Template:Yes	Template:No	Template:Yes
Actions	Check the power cable			Template:MaybeCheck					Template:Sdash
	Check the printer-computer cable	Template:MaybeCheck		Template:MaybeCheck					Template:Sdash
	Ensure printer software is installed	Template:MaybeCheck		Template:MaybeCheck		Template:MaybeCheck		Template:MaybeCheck	Template:Sdash
	Check/replace ink	Template:MaybeCheck	Template:MaybeCheck				Template:MaybeCheck		Template:Sdash
	Check for paper jam		Template:MaybeCheck		Template:MaybeCheck				Template:Sdash

This is just a simple example, and it does not necessarily correspond to the reality of printer troubleshooting. Even so, it demonstrates how decision tables can scale to several conditions with many possibilities.

Software engineering benefitsEdit

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.<ref>"A Real CCIDE Example"</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

HistoryEdit

In the 1960s and 1970s a range of "decision table based" languages such as Filetab were popular for business programming.

Program embedded decision tablesEdit

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.

Static decision table
Input	Function Pointer
"1"	Function 1 (initialize)
"2"	Function 2 (process 2)
"9"	Function 9 (terminate)

Control tablesEdit

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 (either by pointers or an index value).

ImplementationsEdit

Filetab, originally from the NCC
DETAB/65, 1965, ACM
FORTAB from Rand in 1962, designed to be imbedded in FORTRAN<ref>"FORTAB: A Decision Table Language for Scientific Computing Applications", 1962, Rand</ref>
A Ruby implementation exists using MapReduce to find the correct actions based on specific input values.<ref>Alexander Williams (2015). "Ruby decision table parser"</ref>

ReferencesEdit

Template:Reflist

External linksEdit

RapidGen Software For Windows, Unix, Linux and OpenVMS versions of decision table based programming tools and compilers
LogicGem Software For Windows decision table processor for perfecting logic and business rules
LF-ET Software For Windows, Unix, Linux a decision table editor, program generator and test case generator
[1] A Decision Table Example