A History of Decision Tables
Presenting decision procedures in a tabular form goes back at least to ancient Babylon, where the rules for performing multiplication of cuneiform numerals were baked in clay tablets for students. Tables are a quick and easy way for a human being to read, understand and execute a complex procedure. Tabular forms for computer programming dates back to the late 1950's when General Electric, the Sutherland Corporation, and the United States Air Force worked on a complex file maintenance project. Attempts at using flowcharts and traditional narratives failed to define the problem after more than six labor-years of effort. This was typical of most large projects at that time. Then, in 1958 four analysts using decision tables successfully defined the problem in less than four weeks. When the right tool was used the problem was solved almost immediately.
The Sutherland Corporation also used these tables for program specifications, leaving it to the programmers to translate the tables into code by hand. General Electric, realizing that flowcharts and narratives were completely inadequate for complex logic, then automated the method to directly generate source code from the tables.
Automating the tables also formalized the method and made programs to handle them available. The use of tables for code generation became popular in the early 1960's and most of the research on optimal code generation algorithms was done then. The name Decision Tables quickly became the standard term for the method. The Canadian Standards Association issued a formal standard for decision tables in 1970 (DECISION TABLES, CSA Standard Z243.1-1970), which can be obtained through the American National Standards Institute (ANSI) in the United States.
Tables did not reach wide spread use for several reasons. The early decision table software was written for mainframe computers and required a large amount of main storage. Programmers and analysts simply did not get computer time to do development work. The early decision table programs were written in either mainframe assembly languages or COBOL, so they could not easily be rewritten to run on early mini-computers (or later, to the first personal computers), even if the machines had had the required storage available at that time. The user interface was usually punch cards, keyed from printed forms and submitted as a batch job. The lack of interactive video terminals is also a major reason that there were no mainframe word processors or spreadsheets back then, too.
As you can imagine, it was very costly to run these early mainframe decision table packages, both in terms of programmer and computer time. Computing a decision table by hand is difficult work, much like trying to use a quill pen and ledger for corporate accounting. The result was that most programmers never worked with decision tables or decision table software unless they were developing mission critical systems for certain government agencies or the military.
But once again times have changed and decision tables have now evolved into logic processing, just as manual typing evolved into word processing. The changes in the environment which made this possible came in the form of better hardware, better software and better programming practices. Minicomputers, workstations and personal computers became big enough, fast enough and cheap enough to support applications which had formerly been done only on mainframes. Interactive video terminals with good user interfaces replaced punch cards for input. Software for personal computers also became more powerful, so it became reasonable to develop serious applications on small machines. The small computer user changed from a hobbyist to a serious developer.
Finally, structured analysis and design became popular, and developers began to focus on the underlying methodologies of creating quality software. These methods are all driven by finding correct program logic, with the assertion that it is possible to formally prove the correctness of a program.
An Overview of LogicGem
LogicGem is a decision table processor which is useful at all levels of the software development process:
- High level tables can be easily read and filled out by non-programmers. This makes them an ideal way to capture user specifications at analysis time. The high level tables can generate English language documentation as a deliverable product.
- Tables can be automatically tested for all possible combinations of conditions. If any combinations are not covered by the program logic, the analyst or programmer knows it immediately from the LogicGem screen. If any combination of conditions causes contradictory actions, the analyst or programmer knows it immediately. These things are not obvious from looking at a problem with thousands of possible states.
- Low level tables can automatically generate program modules which have been formally proven to cover all possible combinations of conditions in a non-contradictory fashion. Furthermore, the generated code will be optimized in a manner specified by the programmer.
Research has shown that most bugs are put into programs during the design phase and they are usually errors in program logic, not in computation. Decision tables are useful at all phases of software development for the simple reason that all phases of software development need correct logic. The only thing that changes is the conceptual level of the conditions and actions given in the tables. The analysis phase will use high level concepts, the design phase will use lower level concepts and the coding phase will have actual computer language code in the table.
Tables are easy to read and can convey more information in a smaller space and clearer format than flowcharting, pseudo-code, narratives and other conventional documentation techniques. They are also easier for both analysts and users to construct and alter than conventional system analysis techniques. The non-analyst user can be given an empty decision table and be asked to fill it out himself. He can provide information to the systems analyst which would normally require intensive interviews and a great deal of time to obtain.
Tables can be used to automatically generate source code in any programming language which supports if/then/else or switch/case control constructs. While the time saved by generating code would be worth the effort of learning decision tables, there are other benefits.
The first benefit is that the code from a perfected table will have far fewer bugs and less complexity than a program written by a human programmer. A human being has extreme difficulty in keeping in mind more than six or seven things at the same time. As the number of decisions in a module approaches ten, it is increasingly harder to understand and maintain. This is why most bugs are control flow problems, and not computations.
The second benefit is that LogicGem can optimize the generated code by considering the relative cost and frequency of the whole table. The cost of a rule is a number assigned to performing the associated actions of the rule. The cost can be subjective (estimated difficulty on a scale from one to ten) or objective (actual computer time and resources used). For example, "write a letter" would have a lower cost than "write an epic poem" on a subjective scale.
The frequency of a rule is how often the rule is expected to be invoked. The frequency can be estimated or actual, and is often expressed as a percentage for convenience. For example, an automobile insurance company might know that 80% of their clients are males between the ages of 18 and 25 who have not taken a drivers education course. This frequency information would be used to optimize generated computer source code.
LogicGem is also a powerful maintenance tool. Even the best program will perform badly if its environment changes. For example, a program written for the automobile insurance company may slow down when 80% of their clients are females over 45 years of age who have taken a drivers education course. Cost and frequency are independent of each other, and both are independent of the structure of the table. LogicGem allows the analyst to change cost and frequency for the rules and immediately create completely new optimized source code at the push of a button. Furthermore, an option in the generated computer source code will save the frequency information, so that the program can be changed as the environment changes.