Decision Table

A decision table is a modified truth table. A decision table is useful for enumerating all possible cases, and assigning an action to each possible case. Note that decision tables cannot represent iterations.

A decision table has two parts. The first part is a group of columns, in which each column represents a condition. This first part specifies all the possible conditions to be considered. The second part is also a group of columns, in which each column represents an action to take. Each row is a ``rule'' that maps a combination of conditions to a combination of actions.

Note that given $n$ unrelated and independent conditions, you can end up with $2^n$ rows. This means with 6 independent conditions, you can end up with 64 rows.

For complicated cases, a huge decision table can be partitioned to smaller ones. A ``parent'' table contains a (small) number of conditions. Instead of specifying actions, each row of a parent table refers to a ``child'' table. In return a child table can resolve a few conditions and refer to grandchild tables. The last descendents are tables that actually refer to actions.

Tables can be simplified. Two rows containing exactly the same action combination and condition combinations that indicate a condition is not used for decision can be merged. This process can be repeated until no two row can be merged.

Here is an example. Let's say we need to represent the following rules:

• if username exists, but number of consecutive failed login is at least 3, tell the user to call in
• if username exists, number of consecutive failed login is less than 3, and password matches, reset the number of consecutive failed login and proceed to the following step
• if username does not exist, tell user that ``username/password does not match'' and let the user try again
• if username matches, but password does not match, and number of consecutive failed login is less than 3, increment the number of consecutive failed login, tell user that ``username/password does not match'' and let the user try again

The truth table needs to enumerate all the conditions. In this case, our conditions are as follows:

• C1: does the username exist?
• C2: does the password match? Note that this condition is not independent of the first one.
• C3: is the number of consecutive failed login less than 3?

Our actions also need to be enumerated:

• A1: reset number of consecutive failed login and proceed to next step
• A2: increment number of consecutive failed login
• A3: indicate ``username/password does not match'' and ask user to try again
• A4: ask user to call in

Now, we can construct the decision table:

C1	C2	C3	A1	A2	A3	A4
T	T	T	X
T	T	F				X
T	F	T		X	X
T	F	F				X
F	T	T			X
F	T	F			X
F	F	T			X
F	F	F			X

Because our conditions are not truely independent, you can see that some rows can be merged. Particularly, if the username does not match, it makes no sense to see if the password match, or to check the number of consecutive failed login. For these situations, we can specify ``?'' for a condition to indicate ``don't care'' or ``not applicable''. The simplified table is as follows:

C1	C2	C3	A1	A2	A3	A4
T	T	T	X
T	?	F				X
T	F	T		X	X
F	?	?			X