Decision tables are a precise yet compact way to model
complicated logic. Decision tables, like if-then-else and switch-case
statements, associate conditions with actions to perform. But, unlike the
control structures found in traditional programming languages, decision tables
can associate many independent conditions with several actions in an elegant
way.
The production flowchart is a visual representation of the sequence of the content of your
product. It shows what comes first, second, third, etc. as well as what your
audience will do, if anything, and what will happen when they've done it. A
completed flowchart organizes your topics, strategies, treatments, and options
into a plan from which you can work out the details of what each screen, page,
frame, or shot will look like.
Structure
Decision tables
are typically divided into four quadrants, as shown below.
The four
quadrants
|
|
Conditions
|
Condition
alternatives
|
Actions
|
Action entries
|
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.
Printer
troubleshooter
|
||||||||||
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/replace
ink
|
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.
ADVANTAGES
AND DISADVANTAGES
Decision tables
make it easy to observe that all possible conditions are accounted for. In the
example above, every possible combination of the three conditions is given. In
decision tables, when conditions are omitted, it is obvious even at a glance
that logic is missing. Compare this to traditional control structures, where it
is not easy to notice gaps in program logic with a mere glance - sometimes it
is difficult to follow which conditions correspond to which actions!
Just as decision
tables make it easy to audit control logic, decision tables demand that a
programmer think of all possible conditions. With traditional control
structures, it is easy to forget about corner cases, especially when the else
statement is optional. Since logic is so important to programming, decision
tables are an excellent tool for designing control logic. In one incredible
anecdote, after a failed 6 man-year attempt to describe program logic for a
file maintenance system using flow charts, four people solved the problem using
decision tables in just four weeks. Choosing the right tool for the problem is
fundamental.
No comments:
Post a Comment