Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing


Click here to view the complete list of archived articles

This article was originally published in the Fall 2004 issue of Methods & Tools

A Decision Table Based Methodology for the Analysis of Complex Conditional Actions

D. Robert Baker

Background: Decisions

A decision is a choice about a "course of action". A course of action may include many individual actions. A decision may becharacterized on a continuum from unstructured to structured (Simon 1960) [1].

Unstructured Decisions

Unstructured decisions are generally one-time propositions taken in emergent situations (Holsapple and Whinston 1996) [2], i.e. the set ofconditions are unique and there are no fixed rules for the course of action totake based on the conditions. The possible courses of action need not be finite.Making an unstructured decision is therefore heuristic. Automating suchdecisions involves the use of Decision Support Systems, which attempt to obtainand organize as much relevant information as possible for presentation to thedecision maker. The decision maker then applies whatever heuristics he considers appropriate to come up with a course of action.

Structured Decisions

Structured decisions are predictable, i.e. given a particular set of conditions, the course of action to be taken is clear and definable. Thechoice is which actions to take among a predefined, finite collection ofactions. Making a structured decision is therefore algorithmic. There are threecommon methods of expressing these algorithms. Note that all three of these methods are capable of dealing with multivariate, not merely binary conditions.

Figure 1 - A typical natural language expression of a simple policy
for charging for in-flight services on charter flights

Structured English

Structured English is an attempt to allow the use of natural language, stripped of ambiguity, to express actions to be taken under particularconditions. This is accomplished by:

  • choosing a simple subset of natural language verbs and nouns, and
  • defining constructs to express
  • sequence
  • selection
  • and iteration

If this stripping of ambiguity is sufficiently rigorous, the resulting definition defines an executable programming language. This was the approach taken in the creation of the original procedural computer language compilers in the 50s and 60s. These definitions were (and remain) so complex that programmers required months and even years of training to acquire competence in the syntax and semantics of the definition. This made it almost impossible to combine knowledge of the business domain and technical proficiency in the programming language in one individual.

Less rigorous non-executable Structured English definitions are known as pseudocode and are used as analytical tools by analysts to create an intermediate specification. This specification is passed to programmers who translate it into actual compiler-compliant code. This extra step results in added expense both because of extra specialist personnel and because of the inevitable miscommunications and errors involved in an intermediate translation.

Attempts were made in the 70s and 80s to create "natural computer languages" (e.g. NATURAL, ENGLISH) with much looser syntactic andsemantic restrictions. The hope was to eliminate the intermediate step byempowering the compiler to successfully interpret the "sloppy" naturallanguage of the domain expert directly. These efforts met with limited success and are rarely seen today.

Figure 2 a typical executable structured English expression of the policy in Figure 1

Decision Trees

A decision tree is a graphic tool that represents conditions and their resulting actions. It consists of a directed acyclic graph (rootedtree) in which the non-terminal edges represent a set of conditions evaluatedsequentially from the root. A node is a decision point where a condition is evaluated. The terminal edges (leaves) represent actions.

Decision trees are a useful tool for expressing complex decision variables in a format conducive to human visualization. Software thatdirectly manipulates decision trees is available (Oblique Classifier 1,TreePlan), but tends to be limited to highly technical scientific specialtieslike astronomy or DNA sequence analysis and requires a high degree of technical sophistication to use.

Figure 3. a typical decision tree of the policy in Figure 1

Decision Tables

A decision table is a two-dimensional matrix with one row for each possible action and one row for each relevant condition and one column foreach combination of condition states. A decision table can very concisely andrigorously show complex conditions and their resulting actions while remaining comprehensible to a human reader.

The first set of rows indicates the possible actions that may be taken. An "X" in an action row shows that the action will be takenunder the condition states indicated in the column below.

In a bivariate decision table, conditions are binary, restricting condition evaluations to "yes" and "no". Thisresults in a number of columns equal to 2 number of conditions. Thiscan quickly result in a huge number of columns as the number of conditions rise.Fortunately, it is unusual that every combination of conditions results in a different action.

In Figure 4, the use of the "-", or "donít care" notation is illustrated. This means that the condition in that rowdoes not affect the action to be taken. Looking at the first column, we see thatno action will be taken no matter the state of the last two conditions as longas the first condition is false. Each "donít care" reduces thenumber of columns necessary and increases the comprehensibility of the table. In this example the 23 = 8 possible combinations are reduced to 4.

The most common tool for the creation of decision tables is spreadsheet software, such as Microsoft Excel. Although this is really quitesophisticated software, it is cheap, readily available, and has a large base oftrained users. Because of the ubiquity and sophistication of this software, itis quite easy to create additional software that can read decision tablescreated in the spreadsheet, understand the semantics therein contained, and take action to implement the logic expressed in the table.

Such simple software finally allows the removal of the "3rd man" in the analysis-synthesis process, allowing ananalyst or even a logic-savvy policy expert alone to directly create executable code to implement policy.

Figure 4 a typical bivariate decision table of the policy in Figure 1

Page 2   Back to the archive list

SpiraTeam Agile ALM

Software Testing Magazine

Scrum Expert