Decision Tree

Decision Tree & Decision Table & Flow-Charts

A decision tree is a decision support tool that uses a tree-like graph or model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility. It is one way to display an algorithm. Decision trees are commonly used in operations research, specifically in decision analysis, to help identify a strategy most likely to reach a goal. Another use of decision trees is as a descriptive means for calculating conditional probabilities.

In decision analysis, a "decision tree" and the closely related influence diagram is used as a visual and analytical decision support tool, where the expected values (or expected utility) of competing alternatives are calculated. A decision tree consists of 3 types of nodes:1. Decision nodes - commonly represented by squares 2. Chance nodes - represented by circles 3. End nodes - represented by triangles

Drawn from left to right, a decision tree has only burst nodes (splitting paths) but no sink nodes (converging paths). Therefore, used manually, they can grow very big and are then often hard to draw fully by hand. Traditionally, decision trees have been created manually - as the aside example shows - although increasingly, specialized software is employed.

Decision tables are a precise yet compact way to model complicated logic. Decision tables, like flowcharts and if-then-else and switch-case statements, associate conditions with actions to perform, but in many cases do so in a more elegant way. In the 1960s and 1970s a range of "decision table based" languages such as Filetab were popular for business programming. 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).

Example
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. The following is a balanced decision table. Printer troubleshooter Rules Printer does not print Conditions A red light is flashing Printer is unrecognised Check the power cable Check the printer-computer cable Actions X Y Y Y Y N N N N Y Y N N Y Y N N Y N Y N Y N Y N X X X X X X X X

Ensure printer software is installed X Check/replace ink Check for paper jam X 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.

Software engineering benefits

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 them. Tools to render nested if statements from traditional programming languages into decision tables can also be used as a debugging tool. Decision tables have proven to be easier to understand and review than code, and have been used extensively and successfully to produce specifications for complex systems.

A flowchart is a type of diagram that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with arrows. This diagrammatic representation can give a step-by-step solution to a given problem. Process operations are represented in these boxes, and arrows connecting them represent flow of control. Data flows are not typically represented in a flowchart, in contrast with data flow diagrams; rather, they are implied by the sequencing of operations. Flowcharts are used in analyzing, designing, documenting or managing a process or program in various fields. Flowcharts are used in designing and documenting complex processes. Like other types of diagram, they help visualize what is going on and thereby help the viewer to understand a process, and perhaps also find flaws, bottlenecks, and other less-obvious features within it. There are many different types of flowcharts, and each type has its own repertoire of boxes and notational conventions. The two most common types of boxes in a flowchart are:

a processing step, usually called activity, and denoted as a rectangular box a decision, usually denoted as a diamond. A flowchart for computing the factorial of N (10!) where N! = (1*2*3*4*5*6*7*8*9*10), see image. This flowchart represents a "loop and a half" a situation discussed in introductory programming textbooks that requires either a duplication of a component (to be both inside and outside the loop) or the component to be put inside a branch in the loop. (Note: Some textbooks recommend against this "loop and a half" since it is considered bad structure, instead a 'priming read' should be used and the loop should return back to the original question and not above it.

Document flowcharts, showing controls over a document-flow through a system Data flowcharts, showing controls over a data flows in a system System flowcharts showing controls at a physical or resource level Program flowchart, showing the controls in a program within a system