DESIGN TOOLS (DECISION TABLE)

Introduction
We have thus far discussed the need for a systematic program design, and to this
we have explored various design tools such as Flowcharting, Jackson’s
Structured Programming (JSP) and Pseudocode (PDL).

In this chapter, we will look at yet another design tool, namely Decision Tables.
It originates not from software engineering, but has its roots in mathematical
analysis, where it provides a highly logical and systematic means of concerning
alternatives to a problem.

Decision tables are used to analyse a problem. The conditions applying in the
particular problems are set out, and the actions to be taken as a result of any
combination of the conditions arising, are shown.

This fits well into programming constructs which involve decision making based
on multiple conditions and actions. It allows a convenient means of laying out all
the conditions in tabular form and then working through all the possible courses
of actions, without fear of overlooking any.

7.1 Basic Structure of a Decision Table

The four main parts of a decision table are the:

 Condition stub
 Condition entries
 Action stub
 Action entries

Figure 7-1 below shows the physical layout of a typical decision tables.

Rule Entries
Condition Stub Conditions Entries
Action Stub Action Entries

Figure 7-1 : Layout of a decision table

The condition stub lists all the possible conditions associated with that particular
problem. The conditions entries indicate the outcome of each condition as either
a Yes (Y) or No(N).

The action stub lists all likely actions related to the problem. If a particular set of
conditions in a column leads to one or more of the actions, then these are
indicated by one or more ‘X’ in the corresponding row(s) of the action entries.

1
DECISION TOOLS (DECISION TABLE)

The rule entries identify with a number, each unique combination of conditions
leading to a set of action(s). As we shall see later, the maximum number of rules
is mathematically determined by the number of conditions.

7.2 Constructing a Decision Table

To illustrate the use of a decision table, let us consider its application to a simple
set of decisions the driver of a vehicle might encounter while he is on the road
(see Figure 7-2).

Rule 1 Rule 2 Rule 3 Rule 4

C1. Slow traffic ahead? Y Y N N
C2. Approaching a steep slope? Y N Y N
A1. Maintain cruising speed - - X X
A2. Slow down X X - -
A3. Change gear level X - X -
A4. Activate light signal X X - -

Figure 7-2 : A simple decision table can be applied to daily situations

In the illustration, two conditions (C1 and C2) were considered, resulting in a
maximum of four rules. Note that the number actions (A1 to A4) are not directly
related to the number of conditions. For example, one or more actions could be
removed or other possible actions (e.g. look in rear-view mirror) added to the
action stub, with no changes to the conditions, or the number of rules.

How is the maximum number of rules connected to the number of conditions?

If you are familiar with mathematical combinations, you would have arrived at
the following equation:

R = 2c

where R = no. of rules

C = no. of conditions

A programming example

Let us now look at the following problem:

Example 1:
Students who have passed both the course work and exam for a Diploma Course
are allowed to graduate. They are also issued their Diploma scrolls provided
they have completed payment of all fees. Students who have passed their course
work only must attend further exam coaching before sitting for the next exam.
Those who have passed their exam but not their course work are required to

2
DECISION TOOLS (DECISION TABLE)

attend a semester of remedial classes. Any student who has not paid his or her
fees is issued a warning letter.

You will probably have to read the problem several times to understand it fully.
It would even be more difficult to code the program directly. Hence, the use of a
decision table is appropriate here.

3
DECISION TOOLS (DECISION TABLE)

How to begin?

Take the following systematic approach:

a. List down all the conditions

e.g. passed course work?

passed exam?

paid all fees?

b. List down all the actions

e.g. issue graduate status

issue diploma scroll

attend remedial classes

issue warning letter

c. Determine maximum number of rules

e.g. max no. of rules, R = 23

= 8

d. Draw the table and insert the relevant ‘Y’ and ‘N’ for the condition
entry

e. Insert ‘X’ for all relevant actions

Note: There is no limit as to the number of actions that can be associated with
each rule. All the actions can be taken or only one of them. Note, each
rule must have at least one action. If it doesn’t, then either you
interpreted the problem wrongly or your action list is incomplete!

If the steps have been followed correctly, then the resulting decision table would
be:

R1 R2 R3 R4 R5 R6 R7 R8
Passed course work? Y Y Y Y N N N N
Passed exam? Y Y N N Y Y N N
Paid all fees? Y N Y N Y N Y N
Issue graduate status X X - - - - - -
Issue diploma scroll X - - - - - - -
Attend exam coaching - - X X - - X X
Attend remedial classes - - - - X X X X
Issue warning letter - X - X - X - X

Figure 7-3 : Decision table to determine student status

4
DECISION TOOLS (DECISION TABLE)

From the decision table we not only have a clear understanding of the problem,
but we are also able to identify the elements of each rule quickly and easily.
Furthermore, modifications (e.g. a new condition is added, a change in actions,
etc.) can be incorporated into the structure without much difficulty.

7.3 Advantages of Using Decision Tables

Each program design tool, as with physical tools (e.g. hammer, screwdriver, saw,
etc.), would has its set of advantages. But it is clearly not exclusively appropriate
for all levels of program design.

A hammer for example is an excellent tool for driving a nail into the wall, but a
terrible one for loosening a bolt.

Similarly, a decision table would be an ideal design tool if a programmer is

interested in unravelling the complex decision structures inherent within a
problem, but it would be quite useless if the same programmer is interested in
outlining the modular flow of a program. A JSP would be more suitable for the
latter.

Thus it is important that one is aware of the benefit of using one tool over
another. The advantages of using a decision table are as follow:

1. It provides a clear-cut procedure for identifying conditions and actions.

2. It establishes the relationship between conditions and actions in a compact
and unambiguous manner.
3. It makes it possible to examine all alternatives to a problem
(since the maximum number of rules is known).
4. It forces the programmer to think logically.

5. It is easy to construct and to understand.

6. It serves as a convenient form of communication between users, systems

analysts and programmers, being readily understandable and verifiable by all.
7. It can be readily translated into a program code (see section 7.5) either by the
programmer, or by a software known as a decision table pre-processor.

Figure 7-4 : Advantages of using a decision table

7.4 Types of Decision Tables

Through their development, decision tables have taken many forms, some more
complex than others, to adapt to each particular area of application. In this
section, we will examine some convenient variations which will enable us to
represent the problem more accurately.

5
DECISION TOOLS (DECISION TABLE)

7.4.1 Limited Entries

Example 1 is called a Limited Entries Decision Table because the condition

entries are limited to either a ‘Y’ or ‘N’. Likewise the action entries is limited to
either a ‘X’ (i.e., perform that action) or a ‘-’ (i.e., do not perform the action). By
far this is the most common form of a decision table, and is the easiest to
understand.

7.4.2 Extended Action Entries

Consider the following decision table:

R1 R2 R3 R4 R5 R6 R7 R8
Is passenger’s age > 21? Y Y Y Y N N N N
Is passenger a citizen? Y Y N N Y Y N N
Is passenger a member? Y N Y N Y N Y N
Fare structure Type A X - - - X - - -
Fare structure Type B - X - - - - X -
Fare structure Type C - - X X - X - -
Fare structure Type D - - - - - - - X
Coach Class 1 X X - - X - - -
Coach Class 2 - - X X - X - -
Coach Class 3 - - - - - - X X

Figure 7-5 : Decision table to determine the fare types and coach class for
train passengers

In the action stub you can see that all the SEVEN actions can be classified into
two types.

: one for the Fare Type;

: and the other for the Coach Class.

For each action type the difference lies only in the values (i.e. either A,B,C or D
for Fare Type and 1,2 or 3 for Coach Type).

Clearly it is more efficient to condense the action entries thus:

R1 R2 R3 R4 R5 R6 R7 R8
Is passenger’s age > 21? Y Y Y Y N N N N
Is passenger a citizen? Y Y N N Y Y N N
Is passenger a member? Y N Y N Y N Y N
Fare structure Type A B C C A C B D
Coach Class 1 1 2 2 1 2 3 3

6
DECISION TOOLS (DECISION TABLE)

Figure 7-6 : Decision table with extended action entry

Instead of indicating the relevant actions with the ‘X’s, the values of each
corresponding action is indicated instead (i.e. A, B, C, D or 1, 2, 3).

Such extended action entries decision tables can be applied to many situations
where the selection is made from a series of similar data types e.g. which month,
which code, which amount to pay, etc.

7
DECISION TOOLS (DECISION TABLE)

7.4.3 Extended Condition Entries

Similarly, if necessary, the condition entries can contain extended entries too. For
example in Figure 6-6 there could have been further sub-divisions to the age
range, as follow:

Is passenger’s age > 55?

Is passenger’s age between 21-55?

Is passenger’s age between 12 - 20?

Is passenger’s age < 12?

Instead of creating 4 conditions in the condition stub just to represent all the
ranges of the “passenger’s age”, these new set of age ranges could be represented
by extended condition entries as in Figure 7-7 below.

In Figure 7-7 the condition entries consist of both extended and limited entries.
In such a situation, the table is also known as a Mixed-Entries Decision Table.

R1 R2 R3 R4 R5 R6 R7 R8
Passenger’s age range? 21-55 21-55 > 55 > 55 < 12 < 12 12-20 12-20
Is passenger a citizen? Y Y N N Y Y N N
Is passenger a member? Y N Y N Y N Y N
Fare structure Type A B C C A C B D
Coach Class 1 1 2 2 1 2 3 3

Figure 7-7 : Decision table with extended action and condition entries

7.4.4 Combining Rules with Identical Actions

Refer to Figure 7-5 or Figure 7-6 again. On closer scrutiny you will notice that
Rule 1 and Rule 5 share an identical set of actions, although the conditions are
not exactly the same. The same is true for Rule 3, Rule 4 and Rule 6. When such
situations arise, it implies that there is a possibility that two or more rules with
identical actions can be combined to form one new rule.

How would this depend on the conditions then?

Firstly, let us extract Rule 1, Rule 5, Rule 3, Rule 4 and Rule 6 from Figure 7-6
and place them next to each other.

R1 R5 R3 R4 R6
Is passenger's age > 21? Y N Y Y N
Is passenger a citizen? Y Y N N Y
Is passenger a member? Y Y Y N N
Fare structure Type A A C C C
Coach Class 1 1 2 2 2

8
DECISION TOOLS (DECISION TABLE)

Figure 7-8 : Rules with identical actions

For Rule 1 and Rule 5, you will notice that the passenger must be both a citizen
and a member to qualify for Fare structure Type A and Coach Class 1. It appears
that regardless of the passenger’s age, the same sets of actions are taken. Thus,
these two rules can be combined as in Figure 7-9, where the ‘-’ means that the
outcome of that particular condition is not important.

Similarly, in Rule 3 and Rule 4, it is not important whether the passenger is a

member or not, as long as he is above 21 years of age and he is not a citizen.
These two rules can also be combined as shown in Figure 7-9.

R1 R3 R6
Is passenger's age > 21? - Y N
Is passenger a citizen? Y N Y
Is passenger a member? Y - N
Fare structure Type A C C
Coach Class 1 2 2

Figure 7-9 : Two pair of rules can be combined, but not rule 6

Can the same be said of Rule 3 and Rule 6? Clearly, none of the three conditions
share any similar outcome for these two rules. That is, the two rules are distinct.
Thus, these two rules cannot be combined (see Figure 7-9), although their actions
are identical.

Incorporating this back into Figure 7-6, we have:

R1 R2 R3 R6 R7 R8
Is passenger's age > 21? - Y Y N N N
Is passenger a citizen? Y Y N Y N N
Is passenger a member? Y N - N Y N
Fare structure Type A B C C B D
Coach Class 1 1 2 2 3 3

Figure 7-10 : Decision table with extended action entry and combined rules

9
DECISION TOOLS (DECISION TABLE)

7.4.5 ELSE Rule

Consider Figure 7-6 once more. Since Rule 3, Rule 4 and Rule 6 all lead to the
same actions, we could also simplify the decision table thus:

R1 R2 R7 R8 NEW
Is passenger's age > 21? - Y N N E
Is passenger a citizen? Y Y N N L
S
Is passenger a member? Y N Y N E
Fare structure Type A B B D C
Coach Class 1 1 3 3 2

Figure 7-11 : Decision table with extended action entry and ELSE rule

In this case we have further simplified the decision table such that we essentially
need to consider the first four Rules only. All other combinations of the
conditions will simply lead to the ELSE Rule being applicable.

Such a feature is useful if we have a fairly large decision table, with many sets of
conditions leading to the same set of actions. However, caution has to be taken to
ensure that we have not accidentally ‘dumped’ some rules into the ELSE Rule,
without first ensuring that they actually lead to the same set of actions.

Let us look at another example

Example 2:

Develop an extended action entry decision table with combined rules to show
when the result of multiplying three real numbers would result in a value with
either a positive or negative sign (assume that zero is positive).

Solution:

First, construct the decision table with the full set of rules as in figure 7-12
below:

R1 R2 R3 R4 R5 R6 R7 R8
Is first number positive? Y Y Y Y N N N N
Is second number positive? Y Y N N Y Y N N
Is third number positive? Y N Y N Y N Y N
Sign of product of the three numbers +ve -ve -ve +ve -ve +ve +ve -ve

Figure 7-12 : Decision table with extended action entry

10
DECISION TOOLS (DECISION TABLE)

Next, let us pick out the products which result in positive signs only. Next,
classify the rest (i.e., those which result in negative signs) under ELSE:

R1 R4 R6 R7 NEW
Is first number positive? Y Y N N E
L
Is second number positive? Y N Y N
S
Is third number positive? Y N N Y E
Sign of product of the three numbers +ve +ve +ve +ve -ve

Figure 7-14 : Decision table with extended action entry and ELSE rule

7.4.6 Hierarchical

There might exist a whole host of conditions and associated actions in an actual
programming problem. If these were to be represented in one decision table, it
may very well result in a considerably large and complicated table. This would
defeat the purpose of drawing up the decision table, as it would not help to
clarify the problem at hand.

In such a case, a set of Hierarchical Decision Tables might be considered

instead.

Let us look at an illustration of this, as shown in Figure 7-14 below:

R1 R2 R3 R4
Family members > 4? Y Y N N
Combined income < $2000? Y N Y N

Figure 7-13 : Highest level table in a hierarchical set activates lower level tables

The above decision table represents the selection criteria for the purchase of a
low-cost apartment. The two conditions listed here are the two main criteria, and
based on the outcome of these, other more detailed criteria as would be listed in
the lower level decision tables (i.e. A2, A3 or A4) are called into play. However,
if neither criteria is satisfied then the application is immediately rejected.

Each set of conditions in the above figure leads to another decision table (i.e. A2,
A3 or A4) and not directly to an action. Each of these lower level tables has its
own set of conditions and actions, and if necessary, may lead to yet another set of
lower level tables.

Therefore, a sequential set of table hierarchies could be established, whereby the

conditions and actions of each rule can be systematically traced to its conclusion.

11
DECISION TOOLS (DECISION TABLE)

7.4.7 Sequenced Actions

In some situations the order or sequence in which a set of actions are carried out
under each rule can be of importance, especially when the outcome of the
previous action(s) is required to successfully perform the next.

For example, in order to update a master record in the Master File, it is necessary
to perform different validation checks on the transaction records first, and then
perhaps to perform some preliminary calculations on certain fields of that record.
Such a situation is illustrated in Figure 7-15 below.

Actions Sequence
Perform set X validation checks 1
Perform set Y validation checks 2
Perform error routine K 3
Perform error routine L 3
Perform calculation P 4
Perform calculation Q 5
Perform calculation R 5
Update Master File 6

Figure 7-15 : Listing in action stub with sequence numbering

Based on the respective sets of conditions, different sets of actions might be

carried out, and the order in which these are to be done is shown by the
numbering in the sequence column.

The actions with similar numbers can be performed in any order. For example, it
does not matter whether calculation Q or calculation R is done first, as long as
calculation P comes before them.

7.5 Converting a Decision Table to Pseudocode

Given a decision table by the systems analyst, a programmer might need to
convert it into a suitable piece of pseudocode, or even into a section of an actual
program code. Depending on the complexity of the decision table, the conversion
may be done in any manner the programmer finds convenient. The programmer
however cannot do an accurate conversion if he is not perfectly clear about the
logical construct of the problem as presented by the decision table.

As an illustration, we will see how such a conversion can be achieved using the
outline of a typical decision table with 3 conditions. This is shown in Figure 7-
16.

12
DECISION TOOLS (DECISION TABLE)

R1 R2 R3 R4 R5 R6 R7 R8
Condition C1 Y Y Y Y N N N N
Condition C2 Y Y N N Y Y N N
Condition C3 Y N Y N Y N Y N
Action A1 X - - - - X X -
Action A2 X X - - X - - X
Action A3 - X X - - X - -
Action A4 - - - X X - - -

Figure 7-16 : Decision table with 3 conditions and 4 actions

The above decision table has selections which can be fully represented by a series
of NESTED - IFs. The first level of nesting is determined by C1, the next level
by C2, and the third by C3.

The most important step is to develop the structure of this set of nesting
correctly. This is as shown in Figure 7-17 below:

Nesting Structure Nesting Level

IF C1 THEN
IF C2 THEN
IF C3 THEN
… 3rd level
ELSE
…
ELSE 2nd level
IF C3 THEN
… 3rd level
ELSE
… 1ST level
ELSE
IF C2 THEN
IF C3 THEN
… 3rd level
ELSE
…
ELSE 2nd level
IF C3 THEN
… 3rd level
ELSE
…

Figure 7-17 : Nesting logic of pseudocode after conversion from a decision table

13
DECISION TOOLS (DECISION TABLE)

Notice that all four of the 3rd level nesting structures are a repetition of one
another. The same is true of the 2nd level nesting. Such a pattern provides us
with a convenient way of converting a decision table to pseudocode, where
necessary.

Once the nesting structure has been established, it remains only to insert the
corresponding actions, as shown in Figure 7-18 below.

Nesting Structure Actions for each Level

IF C1 THEN
IF C2 THEN
IF C3 THEN
DO A1 actions for R1
DO A2
ELSE
DO A2 actions for R2
DO A3
ELSE
IF C3 THEN
DO A3 actions for R3
ELSE
DO A4 actions for R4
ELSE
IF C2 THEN
IF C3 THEN
DO A2 actions for R5
DO A4
ELSE
DO A1 actions for R6
DO A3
ELSE
IF C3 THEN
DO A1 actions for R7
ELSE
DO A2 actions for R8

Figure 7-18 : Pseudocode with actions inserted

14
DECISION TOOLS (DECISION TABLE)

On some occasions a programmer might be required to convert a piece of

pseudocode back into a decision table, perhaps to reconfirm that all possible
combinations of conditions have been accounted for.

In such an instance, the process need merely be reversed. That is, firstly list
down all the conditions. Then put down the required number of rules, after which
systematically insert in the ‘Y’ and ‘N’ for the condition entries. Finally, go
through each of the NESTED-IFs levels and mark with an ‘X’ all the required
actions, until all levels of the NESTED-IFs are completed.

15