Evans's Decision Table Language(ID:8014/)Generalisation of the CODASYL decision table rules to incorporate extensions in turns of actions and logic References: A major problem in data processing today is one of communication among subject-matter specialist (accountants, designers, manufacturing planners, credit analysts, etc.), data-processing systems engineers, and computer programmers. The statement of decision logic in the past has been largely in the form of conversation, narrative, flow charts, data tables, and logical equations. The format, depth, accuracy, consistency, and completeness of the documenation have varied from person to person and through various time periods. Our previous approaches to the problem of stating decision logic have resulted in unsatisfactory computer input requirements and computer outputs. This, in turn, has caused excessive costs and time delays in terms of time to state, interpret, refine, obtain agreement of, prepare computer programs for, prepare exhaustive test data for, debug, and reprogram problem-solution decision logic. In addition, excessive costs and time delays have been incurred in these same areas when decision logic has had to be changed to meet new business conditions. Extract: Decision Tables Decision Tables Decision tables offer a formal method of stating decision logic that is readily understood by management, functional specialists, computer programmers, and other systems engineers. Experience with decision tables indicates them to be superior to other methods (narrative, flow charts, and logical equations) for human communication. The systems engineer can use decision tables to permit management to state its decision criteria. He can use decision tables to find out the decision logic of accountants, engineers, inspectors, and other functional specialists. The understanding of the functional-specialist areas is essential in determining the systems characteristics. The systems engineer now has a tool that assists him in stating the problem-decision rules, in a more complete form, to the computer programmer. Decision tables offer a formal method of depicting in a clear and concise manner the cause and effect relationships of each decision rule. In addition, the layout explicitly indicates omissions and inconsistencies and thus assists in assuring complete logical decision rules. Decision tables use a format which is familiar to all of us. Examples of the tabular format are most tabulating reports for accounting, sales analysis, and stock control, as well as rate charts for insurance and utilities. The tabular format has been used for displaying large amounts of data and complex relationships. Decision tables are being used to assist in analyzing and in displaying the decision logic of operating procedures. They are being used because they are more effective and have more utility than previous methods. Extract: Decision Table Entries Decision Table Entries A condition is a state of existence of a specific piece of information. The state of existence may be its presence or absence, a specific value or range of values, its relationship to other data, or combinations of these. Structurally, in decision tables a condition consists of two factors: (1) the data in the stub, and (2) the data in a rule entry. For instance, the condition in Line 3 of Rule 3, "pay experience equals good," is the complete condition. The condition in Line 3 of Rule 4 is "pay experience equals bad." A stub data of a line serves as a common factor for multiple conditions on that line. Actions are commands that perform operations (movement, arithmetic, etc.) on and with data and that control the sequence of considering tables. The structure of actions in decision tables is similar to the structure of conditions explained above. A limited entry condition is shown in Line 2. The entire condition, "credit limit is greater than or equal to OK," is stated in the stub. Data in the entry of each rule, for Line 2, are limited to "Y" and "N" or are left blank. These entries have the following meaning. 1. Y means "Yes" the condition must be satisfied. 2. N means "No" the condition must not be satisfied. 3. Left blank means the condition is irrelevant. A limited entry action is shown in Line 4. The entire action, "move the word 'approved' to order status," is stated in the stub. Data in the entry of each rule, for Line 4, are limited to "X" or left blank. These entries have the following meaning. 1. X means take this action. 2. Left blank means do not take this action. Extended entries have a portion of the condition or action stated in the entry and the remainder in the stub. See Line 3. Mixed entries are formed when a rule or a table contains both limited and extended entries, whichever are more convenient for a particular condition or action. An arithmetic expression is illustrated in Line 2. The condition is "credit limit is greater than or equal to OK." The word "OK is the name of an arithmetic expression which is defined just below the table as: OK = In process amount + Accounts receivable amount $ Order amount. Since long expressions do not fit well in the decision tables, they are named and the name is placed in the table, the expression being defined elsewhere. Each time an arithmetic expression is called for in a condition or action, its value is recomputed. The value of an expression does not persist. A conditional expression is an expression which, taken as a whole, may be either true or false, depending on conditions existing when the expression is examined. Generally, a condEtional expression contains at least one variable quantity, and the truth or falsity of the expression will depend on the particular value assumed by the variable or variables. For example, the expression "A is greater than 10" is conditional, since it may or may not be true, depending on the value of the quantity "A." Obviously, if "A" had a value of 12, the expression would be true; if the value were 7, the expression would be false. Conditional expressions are always written in the decision table, never in the data description. This is one of the major advantages of decision tables-they offer a two-dimensional visual aid in exploring the potential combinations of conditions. Conditional expressions are discussed here in three categories: 1. Simple conditional expression. 2. "AND" compound conditional expressions-simple conditional expressions joined by "and's." 3. "OR compound conditional expressions-conditional expressions of category 1 and/or 2 joined by "or's." Conditional expressions exist as that part of a data rule which must be satisfied prior to taking the indicated actions of that same data rule. Extract: Kinds of Decision Tables Kinds of Decision Tables There are two kinds of decision tables-the open table and closed table. The open table has these unique characteristics: 1. It may be entered only by a GOT0 command (the only exception is the BEGIN table). 2. It may not be entered by a DO command. 3. It may contain DO command(s). 4. It will indicate the next table to be considered by a GOTO, NEXT, or ELSE command. The closed table has these unique characteristics: 1. It may be entered only by a DO command. 2. It may not be entered by a GOTO, NEXT, or ELSE command. 3. It may contain DO commands for tables other than itself. 4. After having been considered (and actions taken), the sequence control is transferred back to the next action of the rule in that table from which control was transferred to this closed table. Extract: Miscellaneous Characteristics of Tables and Rules Miscellaneous Characteristics of Tables and Rules Unconditional Table. A table may contain only actions (commands) and no conditions (there would be only one data rule). This is called an unconditional table and would be of the closed or open kind of table. No-Action Rule. A rule may contain only conditions and the only action is the next table. Table Entity. A decision table is always considered as an entity. A transfer (via GOTO, DO, ELSE, and NEXT) is always to a table as a whole, not to a rule or condition within a table. One Rule Success Per Table. For any one pass through a table, only a single set of conditions for one rule can be satisfied; therefore, only a single set of actions for the same rule can be executed. The rule that is satisfied may be the ELSE condition, and the only action may be to go to the next table via the ELSE NEXT.TABLE. Rule Independence. Each rule is stated as an entity separate from other rules in the same table. A rule must contain sufficient conditions to insure the execution of its actions when the conditions are satisfied regardless of the sequence of considering rules in a table. This means that (1) all conditions pertinent to a rule are indicated and, conversely, (2) conditions that would automatically be met in a current rule due to the failure of a set of conditions in a prior rule of the same table must still be indicated. The only exceptions to this rule independence is when an action is required for the ELSE condition other than "go to the next table." (See discussion of ELSE below.) Condition Independence. For a rule, the sequence of testing conditions is not relevant since all indicated conditions must be satisfied before the actions are executed. This is true from the viewpoint of defining a problem at a level as independent of procedural stdps as possible. When the problem is implemented by a programmer or procedure writer, the sequence of testing conditions may have a significant effect on the efficiency of the process media. Table Form Size. Table form size is designed to the usual 81/2 x 11 inches. Our eyes are trained for this size paper. It is believed that we can comprehend decision rules more quickly when this size form is used. The "one rule success per table" concept tends to keep the decision rules confined to this size form. ELSE Condition. The ELSE condition rule is possible because of the "one rule success per table" concept. The entries in the table header ELSE may be: 1. a TABLE.NAME 2. left blank 3. ST0P.n command. This field is generally used for error detection but may be a systems logical sequence control. When an action is required for the ELSE other than "go to the next table," the word ELSE can be entered as a condition in Operand 2 in the ENTRY portion of the table and the necessary actions indicated. In this case the ELSE rule has to be the last rule considered for the table. Extract: Use of Decision Tables to Date Use of Decision Tables to Date A number of experiments conducted over the past four years have used decision tables on a variety of problems. At a leading electrical manufacturing company, the application of tables to a wide variety of problems was explored, including their use for product design, quality control, operation planning, cost determination, factory scheduling, and financial and scientific problems. The results clearly revealed that decision tables are a major new contribution in our attempt to clarify communication among different functional specialists as well as between these specialists and computer programmers. Manufacturing engineers were able to quickly grasp product-design decision logic and then point out where restraints had been introduced by the product engineer that were of little value. Through this kind of examination, significant improvements can be made in product design and manufacture. Systems engineers from this company estimate a minimum of 10-to-1 improvement over other methods in terms of manpower, time, and money from problem definition through debugging. This savings was said to be across all business and scientific applications. In a consulting firm, management decision rules expressed in tabular form have been used with various customers. These decision tables have been applied to Air Force logistics and various commercial activities such as accounts receivable and accounts payable. From all reports, this work has permitted a more effective and comprehensive statement of the decision logic and provided more meaningful and understandable communication between systems men and programmers. Work on the use of decision tables was also done by a food-processing firm. This work was directed toward communication among different systems engineers, functional specialists, management, and programmers concerning the complex decision rules involved in stock control, sales analysis, credit, and invoicing. Results demonstrated that this approach was an effective formal way to state a very complex logic without requiring knowledge of Boolean algebra. IBM has been working with several customers investigating potential applications of decision tables to a variety of problems such as input, validation, payroll, sorting, and merging. From these experiments, it seems clear that decision tables are frequently easier to prepare than comparable Aow charts or programs, and that they are an effective aid to systems analysis. In these experiments, communication between the systems engineer and programmer has been substantially improved. Communication between the systems engineer and management has also benefited from the common description of decision rules. The CODASYL Systems Group, part of the Development Committee of the Conference on Data Systems Languages, has been looking into the use of decision tables. It feels that the systems analysis method discussed above (including decision tables) will provide a precise and orderly method of documenting the analysis, independent of the processing method. It will offer the analyst an aid in visualizing the relationships and alternatives of the problem, will provide flexibility in changing any portion of the analysis, and will establish a framework for the complete definition of the systems problem. The CODASYL Systems Group intends to develop and experiment with these concepts. To further indicate the potential results from use of tabular form, the following statements paraphrase various user opinions: on the subject of clarity and conciseness-Decision tables are easy to prepare, read, and teach to others; experience shows that non-programmers can learn to prepare satisfactory tables in less than a day. The amount of writing, or number of words, lines, and symbols used to describe complex decisions, is reduced by 25-50 per cent as compared to flow charting. For certain specific cases, problem statement and programming time combined have been reduced significantly. As to meaningful relationships-Table structure serves to improve systems logic by aligning alternatives. It also sharpens cause and effect understanding, so that relationships which are only accidental or incidental can be discovered. Furthermore, actions based on similar or related conditions are apt to be drawn into the same table, making it easier to appreciate and consider interdependent factors. On completeness-Tabular form allows effective visual or desk debugging both by the analyst and by the reviewer. There are fewer errors to start with since the analyst tends to catch his own mistakes; moreover, the reviewer will typically detect a high percentage of the remaining errors by visual examination. Finally, experience shows that with this foundation and suitable test-problem construction, it is easy to rapidly detect the balance of the errors during machine debugging. The evidence quoted on the advantages of decision tables for systems analysis and computer programming is based on actual study projects. Some of these studies even tested decision tables on various dataprocessing machines. There are many current studies which are experimenting with a variety of tabular forms. Extract: Call for Experimentation Call for Experimentation With all the potential advantages of decision tables, it is apparent that we are in the experimental and development stage. Some of the many areas that require further development are: 1. Table structure 2. Relations among tables 3. Language considerations 4. Associated data description 5. Implementation considerations I have written a preliminary Decision Table Reference Manual This paper is, largely, an extract from it. The manual is written as a base language (point of departure) for using decision tables. The language is not all inclusive, and in many instances has been arbitrary in the interest of simplicity. The manual provides a language that interested persons can use to experiment with decision tables in documenting problem definitions. Let us attempt some broad field experience in using decision tables to describe problems at several levels and then refine the language. I would appreciate response from anyone as a result of his experimentation with decision tables in terms of success, failure, weaknesses, advantages, disadvantages, and improvements. The explosive innovations in computer hardware have not been matched by corresponding developments in systems communication. But we are on the threshold of a significant advance and perhaps even a major breakthrough. Both manufacturers and users must balance inventiveness in hardware with creativity in software. Decision tables will aid in the development of a clear, concise, meaningful, and comprehensive systems engineering language. Extract: Discussion Discussion R. S. HATHAWAY (B. F. Goodrich Co.): There is still some question in my mind as to what your opinion is of tabular documentation-nonmachine versus machine documentation. MR. EVANS: We can document problem definition from many levels. We can use this method or other methods to document it from a large systems level which may show only the input and output of the system and perhaps the processing methodology independent of machine runs. We can also do it for the input of the system by machine run and still not necessarily restrict a programmer to the degree which we have in the past. I explain more completely in the manual 1 that this method can be used at any of these levels of documentation. We might have varying formats for the decision table itself based upon which level of documentation we are going to use. We would certainly come up with different types of data description for man-to-man communications than we would for detailed programming considerations. MR. HATHAWAY: What work is being done currently on writing a tabular compiler? MR. EVANS: I indicated several areas-and these were only a few-which we at IBM consider that we need to investigate and experiment with more thoroughly before we write the specifications for such a compiler. General Electric is writing one for TABSOL (Tabular Systems Oriented Language) with GECOM (General Compiler for General Electric Computers) which is a very powerful language. It will be some time, probably a year or two, before any such tabular language will be forthcoming from IBM. J. D. BEENEY (Air Force Logistics Command): I have heard that the most flexible form is a piece of blank paper. Is it possible that you envision a form which is laid out according to the rules of Boolean logic, that would enable you to change systems or to go into system evolution? MR. EVANS: We are at present experimenting with several different types of forms. Some have rigidity-like the one I have shown here; the others have more free form associated with them. Actually, we will probably have more than one manual on decision tables. There will probably be one manual for man-to-man communication, and the format for this type of table will look different and have more free form than the one for the more detailed problem-solution logic. MR. BEENEY: This will mean that you can build the format into your system operations manual and let the user of the system determine the logic he wants to use. MR. EVANS: Of course, the goal which we are shooting for with this approach is to be able to write a procedure from the human level and have a compiler sophisticated enough to accept this directly. If this occurs-and I am fairly sure it will-it means that we will, of necessity, have to change the documentation for the decision logic. This documentation will always be compatible with the existing programs, which is something we have not had in the past. MR. BEENEY: Along the line of flexibility, would you still allow the feature: This is the logic I want to use and I want to change to this type of logic? MR. EVANS: Yes. in Proceedings of the 1961 Computer Applications Symposium, Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois view details in Proceedings of the 1961 Computer Applications Symposium, Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois view details in Proceedings of the 1961 Computer Applications Symposium, Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois view details |