DETOC(ID:4426/det010)ISL decision table languagefor DEcision table TO Cobol Decision Table translator from Information Systems Leasing Corporation Structures: Related languages
References: DOI Extract: Introduciton Optimized algorithms Have been developed for the processing of extended-entry decision tables, and for the direct conversion of extended-entry tables to code without translation of the extended-entry decision tables to limited-entry tables. One of the algorithms Is described and discussed In this paper. Examples are given to illustrate why direct code conversion Is better, and why It Is better. Although the amount of improvement will vary from table to table, and Indication of the savings is Included. The methodology presented in this paper was developed by the author while employed by Information Systems Leasing Corporation. The resultant algorithms are an integral part of the decision table processor, Detoc III, which is marketed and maintained by ISL. It is with the permission of I SL that this paper is presented. Any questions relating to the contents of this paper or Detoc III should be addressed to the author, c/o ISL Corporation, 15 Pebble View Lane, Doylestown, Pa. 18901. Decision tables have been used in data processing for over 15 years. An analyst, in defining a problem, often uses extended-entry statements because of their ease of use and for clarity in stating the problem. For over eight years, there have existed several computerized systems available to the public that convert limited-entry decision tables into various source languages. A few of these have been enhanced by the addition of an initial pass to convert extended-entry into limited entry decision tables before conversion into source code. This method of converting extended-entry decision tables into code has several inherent disadvantages. To the author's knowledge, the algorithm presented here is the only existing automated method for the direct conversion of extended-entry decision tables into source code for computer programs. The discussion in this paper is limited to an optimized method of generating code from the Condition section of extended-entry tables. It is assumed that the reader has: a basic knowledge of decision tables. Definitions and formats will be discussed only as needed for clarity. Structure of extended-entry decision tables Figure1 is a diagram of the structure of a decision table. Since this paper is primarily concerned with the translation of the Condition section of extended-entry decision tables, the explanations given will be those dealing with the Condition section. A Condition section consists of one or more Condition specifications, each of which consists of two parts: the Condition statement (or Condition stub), and the corresponding Rule entries. A Condition specification may have one of two formats: limited-entry, or extended-entry . A 1imited-entry Condition specification consists of a complete condition statement that can be answered Yes or N, and Rule entries that are limited to the set (Y,N,-). Rule entries are Y for Yes if the condition must be true to satisfy the rule, N for No if the condition must be false to satisfy the rule, and - if the condition need be neither true nor false to satisfy the rule. All limited entry conditions are either true or false; no other value is permitted. An extended entry Condition specification is a Condition that has multiple values. It consists of an incomplete Condition statement where the rule entries supply the missing portion of the statement. Within the statement, a symbol is used to indicate where the rule entry is to be substituted, or the rule entries are limited to some predefined portion of the statement. In this paper, the symbol *** is used to identify the position where the rule entry is to be substituted. Rule entries that complete a statement usually consist of data-names, constants, or operators, such as =, >, and <) . There are two special rule entries for extended-entry condition specifications. A - indicates that the result of testing a condition is irrelevant to determining if the rule is satisfied. NNN is used to represent all values of the Condition variable besides those specified in the other rule entries for that condit ion. One essential requirement of each extended-entry cond-ition specification is that the set of statements formed by substituting the rule entries must be mutually exclusive. If the sta tement formed by using rule entry 1 is true, it implies that ail state ments formed by subs tituting any dif ferent rule entry must be false, given the same set of c ond i t i on va 1 ue s . A special rule, the Else rule, is available for ease of defining a problem. If no other rule is satisfied, the Else rule will be satisfied.. In this paper, an Else rule is identified by a final, right-most rule in which all condition entries are -? An Else rule is useful for many d ecis ion tables, but should not be required in a tabie that is otherwise complete.] in [ACM] SIGPLAN Notices 6(09) September 1971 Special issue on decision tables view details in [ACM] ACM Computing Surveys (CSUR) 6(2) June 1974 view details |