GB/T 15535-1995 Specification for hit determination table for information processing
Some standard content:
National Standard of the People's Republic of China
Information processing
Specification of single-hit decision tables
Information processing--Specification of single-hit decision tables
GB/T 15535—1995
IS0 5806—1984
This standard is equivalent to the international standard ISO5806-1984 Information processing: Specification of single-hit decision tables. 1 Subject content and scope of application
This standard specifies the basic format and related definitions of single-hit decision tables, and recommends the conventions for compiling and using the decision tables. Note: ① This standard is related to the use of decision tables in the compilation of computer information system files, and is not related to other uses (such as the representation of program statements). ② The compilation and use format and conventions of multiple-hit decision tables are not within the scope of this standard. 2 Referenced standards
GB5271.1 Data processing vocabulary Part 01 Basic terms GB5271.7 Data processing vocabulary Part 07 Digital computer programming 3 Terms
The following definitions of terms apply to this standard.
3. 1 Decision table
A table that lists the various situations that may occur when solving a problem and the corresponding actions to be taken (see GB5271.1). 3.2 Single-hit decision table "single-hit" decision table A decision table in which any set of conditions only meets one rule. 3.3 Multiple-hit decision table \multiple-hit decision table A decision table in which at least one set of conditions can meet multiple rules (see Chapter 1 Note ②). 3.4 Rule
A single column consisting of the condition item and action item parts of the decision table, which specifies a unique set of conditions that need to be met and a set of corresponding actions to be taken. If all conditions meet the condition items of a rule, the rule is met. 3.5 ELSE rule "ELSE" rule
Action taken for all combinations of conditions not covered by other rules in the decision table. Note: The use of ELSE rule is optional. 3.6 Condition
A description of a possible sequence of events to be considered in the representation of a problem, or a reference to another process to be considered as part of a condition.
3.7 Action
A description of an operation to be performed to solve a problem. 3.8 Condition entry
An indication of the relevance of a condition to a specific rule. Approved by the State Administration of Technical Supervision on 1995-D4-05 and implemented on 1995-12-01
3.9 Action entry
GB/T15535--1995
An indication of the relevance of an action to a specific rule. 3.1G Condition stub
A list of all conditions to be considered in the problem description. 3.11 action stub action stub
a list of all actions to be performed when solving a problem. 3.12 table heading
a symbolic name or other representation of a decision table from another file. A clear description of the table may also be given. 3.13 initialization section initialization section an optional list of unconditional actions to be performed sequentially, before the first condition is tested, in the line immediately following the table heading. 3.14 limited entry table a decision table that gives a complete description of all conditions and actions without reference to rules [see Appendix B (Supplement) Example 1]. 3.15 extended entry table a decision table that gives only a general, incomplete description of actions and conditions, but specifies them in detail with values specified in rules [see Appendix B (Supplement) Example 2].
3.16 mixed entry table a decision table that contains both limited and extended entries in the stub [see Appendix B (Supplement) Example 4]. Note: In fact, the extended term table contains restricted terms, so it is also a mixed term table. Any extended term table can be converted into a restricted term table. See Appendix B (Supplement) Example 3.7.
3.17 Complete table complete table
A decision table for which there is a rule that can be met for all conditional term combinations. 4 Format
4.1 Decision table
The general representation of a decision table is shown in Figure 1. The table is divided into four parts by two sets of double lines (or two single thick lines), which separate the condition part from the action part and the term. Table header
(see clause 3.12)
First condition
(see clause 3.6)
Last condition
First action
See clause 3.7)
Final action
First condition (see clause 3.4)
Figure 1 General format
First condition (see clause 3.8)
Last condition item
First action item (see clause 3.5)
Final action item
Last rule
(ELSE rule is optional)
Note: For ease of reading, draw thin horizontal lines between conditions and actions, and thin vertical lines between rules. For unique reference, you can name the conditions, actions, and rules of the decision table arbitrarily. 4.2 Conditional item
Text, value or code
GB/T 15535—1995
Meaning in the rule
The condition is true only when it satisfies this rule (Y=*Yes\)The condition is false only when it satisfies this rule (N=\No\)The text (or value or code) is a detailed description of the incomplete condition in the rule: the condition is satisfied only when it satisfies this rule. If a code is used, the meaning of the code is described in the reference note of the text
The condition is irrelevant to whether the rule is met; in other cases, the condition cannot appear in the context of this rule. Sometimes, "#\" can be used instead of "-\" to emphasize it. Note: Any binary value symbol can be used to indicate the condition value. 4.3 Action Items
Text, Value or Code
Relationships between List Elements
5.1 Conditions
Meaning in the Rule
When the rule is met, the corresponding action should be performed
The text (or value or code) is a detailed description of the incomplete action in the rule; when the rule is met, the action should be performed. If a code is used, the meaning of the code should be described in the cross-reference solution
When the rule is met, the corresponding action should not be performed
Restricted Items
Extension Items
Items of Any Type
Restricted Itemswww.bzxz.net
Extension Items
Items of Other Types
The relationship between the conditions is a logical "AND" relationship, assuming that the first condition to be tested is preceded by an "IF" [e.g.: IF (first condition) AND (second condition), AND (last condition). The order in which the conditions are listed may be important. If the order is not important, for ease of reading, list the important or critical conditions first. Such a sequence may be different from the preferred sequence in program design. 5.2 Actions
The execution relationship of actions is sequential; if "THEN" is followed by the first action to be executed, the first action, the second action, and the last action are executed in sequence. The actions should be described in the order in which they are executed. When the execution order of actions between rules is different, these actions need to be described separately to show these different sequences. In order to avoid confusion with extension codes, it is recommended not to use sequence numbers (see Section 4.3). Unless the decision table itself is complete, in any rule, the last action executed should indicate where the next process is described. 5.3 Rules
The relationship between each rule is a logical "or" (i.e., \OR\) relationship. The order between the rules in the decision table is irrelevant, but pay attention to this convention. If the ELSE rule is used, it usually appears as the last rule in the table for readability (see Figure 1). 6 Relationships between decision tables
A human-shaped and/or complex problem can be captured by a set of decision tables. There are four types of combined relationships between these decision tables. a
Order:
Selection;
Repetition,
d. Nesting.
GB/T15535—1995
When these decision tables are related, each decision table should be logically complete. The conditional test in one table does not depend on the result of the conditional test in another table. The effect of this requirement is to make the rules of related tables unrelated. However, it does not exclude the convention that the result of a test of a condition in a table is indicated by an action in that table (e.g., setting a flag), so that the indication can be checked by testing the condition in the subsequent table.
6.1 Sequential Relationship
If the first table has a direct successor table, the two decision tables form a sequential relationship, as shown in Figure 2. Similarly, if the nth table is the only direct successor table of the (n1-1)th table, then more than two decision tables can also form a sequential relationship. In a sequential relationship, the preceding decision table contains an action that provides a pointer to the subsequent table. In any rule, the action pointing to the subsequent table should be executed last.
Processing Table 2
Figure 2 Sequential Relationship of Decision Tables
6.2 Selection Relationship
If the first table has multiple direct successor tables to choose from, these decision tables form a selection relationship, as shown in Figure 3. In a selection relationship, the preceding table should contain an action that provides a pointer to the subsequent table. In any rule, the corresponding action pointing to the subsequent table should be executed last.
6.3 Repeating relationship
Processing 2
Processing 3
GB/T15535
Figure 3 Selection relationship of decision table
If at least one rule needs to repeatedly test the conditions in the table, the decision table must be interpreted repeatedly (see Figure 4). Such a rule or multiple rules require that the final action should be pointed to by a pointer to another decision table, Table 1
Repeat 1
Figure 4 Repeating relationship of decision table
6.4 Nesting relationship
When a table is fully interpreted, it is necessary to test a condition in another table (see Figure 5) or execute an action in the table (see Figure 6), then the two decision tables have a nested relationship. The definition of this relationship is the same as the definition of nested subroutines (see GB5271.7). Nested tables require that there is a pointer in the relevant conditions or actions to point to the nested table in an appropriate form. The nested table must also have an action that points back to the nested table. This action should be the last action of any rule in the nested table that continues the nesting relationship. The pointer of the nested table points as follows: for a condition, it points to the initial exit condition, because the test of the condition is related to the interpretation result of the nested table; for an action, it points to the next related action. 1
(Execution table 2)
Condition verification
GB/T 15535 --1995
Return to Table 1
Figure 5 Nested Table (Exit at Condition)
Note: In Figure 5, Table 2 is executed before checking the "Condition Check" in Table 1, and then the "Condition Check" in Table 1 is checked. Table A
6.5 Combination of Relations
Quick Table B
Return to Table A
Figure 6 Nested Table (Exit at Action)
When necessary, any arrangement of relations can be used to describe the problem and its solution. Figure 7 shows some combined relations. GB/T15535—1995
Figure? Combined relations
In Figure 7, Table 1 has two rules requiring the table to be repeated, and the other two rules sequentially point to Table 2; Table 2 Two rules point to Table 3 in sequence, while the other two rules point to Table 4. Table 3 and Table 4 are nested with Table 5 respectively, in order to evaluate a condition. The choices that can be obtained from Table 1 are one of the following: Repeat Table 1:
points to Table 2, Table 3 in sequence and nests Table 5;
- points to Table 2, Table 4 in sequence and nests Table 5. 7 Interpretation of decision tables
7.1 Vertical method
Find out the rules that meet the requirements by determining a specific situation and then comparing it with each rule in turn. The required steps are: a. For this specific situation, check all conditions and determine their values; b. Compare these values with each rule in turn until a unique set of identical values is found, and then press Execute all actions specified by the rule in sequence,
C. For this specific situation, if there is no condition value that meets all the rules, all actions specified by the ELSE rule should be executed in sequence.
7.2 Horizontal method
GB/T15535—1995
Determine the rules that are met by testing each condition in turn. The required steps are: 2. Test the first condition,
b. Eliminate all rules that do not meet the test results of this condition; test the next condition related to the remaining rules, and do not consider any remaining conditions with only "one" condition item (see 4.2);
d. Repeat b. and c. until all conditions are tested or eliminated. e. It is possible to find a rule that satisfies all the conditional test results; or if there are no more rules left, the ELSE rule can be used. In either case, the actions specified by that rule must be executed in sequence. 7.3 Completeness
By definition (see 3.2), either of the above two interpretation methods must produce one (and only one) rule that is met. If the table contains an ELSE rule, by definition (see 3.5), it does not apply to a situation that meets a certain rule. Any decision table containing an ELSE rule is always complete. In fact, the ELSE rule is a default rule. The use of the ELSE rule should be cautious because it replaces the rule that was omitted due to errors. If a decision table does not contain an ELSE rule, all logically possible conditional arrangements should be specified. The compilation of such a table should be more careful so that all arrangements are covered. Verification of completeness is an essential part of compiling a decision tableA1 Constructing condition items
GB/T 15535
Appendix A
Compilation suggestions
(Supplement)
When initially drafting a decision table, it is recommended that the complete arrangement of the condition items be listed before any work is done to compress the table to ensure that no combination of conditions is missed.
The total number of rules for any table is always the product of the number of allowed values for each condition item. Example: A table has three conditions. For these items: a. Condition 1 has two values;
b. Condition 2 has three values;
C. Condition 3 has four values.
Total number of rules - 2×3X×4=24
Therefore, the general process for constructing an item is as follows;
Step 1: Divide the total number of rules by the number of allowed values for the first condition item, thus obtaining the number of adjacent rules required for each of these values.
Step 2: Divide the quotient obtained in step 1 by the number of values of the next condition item to obtain the number of adjacent rules for each value. Step 3. Continue to divide the number of consecutive condition values by each consecutive quotient, and the final quotient is 1. Example: The extended item table has three conditions:
Condition 1 has two values: Y, N;
b. Condition 2 has three values: ABC
c. Condition 3 has four values: 1, 2, 3, 4. The total number of rules = 2×3×4=24
The number of rules for each value of condition 1 - 24 - 2-12 (i.e. 12 Ys, 12 Ns).
The number of rules for each value of condition 2 - 12 + 3 to 4 (i.e. 4 A, 4 B, 4 C).
Number of rules for each value of condition 3 — 44-1
(i.e., 1 for each of 1, 2, 3, and 4)
Thus, the complete arrangement of the condition items is as follows:
Condition 1￥
Condition 2
Condition 312
YYYYYYY
Note: This method is very cumbersome for large tables, and other methods of ensuring completeness should be sought. A2 Table Separation
ＮNIＮN
For some types of problems, the number of conditions may make the number of plans quite large. Since it cannot be drawn on a piece of paper, the table is difficult to read. It is recommended to separate such tables on a logical interface and use appropriate sequences or selections (see 6.1, 6.2) to generate two or more tables.
GB/T15535-1995
Condition 1
Condition 2
Condition 3
Processing table 2
Processing table 3
The separation method is as follows: construct a decision table based on only one value of the first condition item; give a rule for each other allowed value of the condition item, in which the symbol \_二 is inserted for the successive condition items, and a single action that references the subsequent table is given, and the commercialization of A3
The expansion item table or the mixed item table can only be simplified by inspection. This is a very difficult task. If the specified requirements described below are met, the restricted item table can be simplified, and any two rules can be merged if and only if: they contain exactly the same action combination and sequence; e
b. Their conditional terms differ in only one line. In the merged rule, "Y\ and \N\" are replaced by the symbol "two". Following the above procedure, it is also possible to merge a pair of previously merged rules. Note that the symbol "two\" in the conditional term of one rule does not have the same meaning as "Y\" or "N\" in another rule, for example:
a) Complete table
Condition A
Condition B
Condition C
Action P
Action Q
Action R
Action S
In this table, the first four rules can be merged. The fifth rule has the same action but cannot be merged. The seventh and eighth rules can also be merged.
b) Simplified table
Condition A
Condition R||t t||Condition C
Action P
Action Setting
Action R
Action s
Note: For many tables, it may be necessary to reduce the size of the table due to the presence of mutually exclusive conditions. In the example shown below, it is obvious that two conditions can be combined. A4 Rule Count Check
GB/T15535-1995
An Lian Staff
Male Difficult Staff
As described in A1, the total number of rules in any table is the product of the number of allowed values for each condition. In practice, the following steps can be used to check the completeness of the table:
Count each "simple" rule (i.e., one that does not contain the symbol "-") as \1" For each rule that contains the symbol "-", the count is the product of its "factors \". b.
If a condition has a specific value, the factor is 1: If a dash is used, the factor is the number of possible values indicated by the dash. The counts are added together to get the total number of all rules in the complete table and compared to the expected count. c.
When using ELSE rules, it is more difficult to check the rule counts, and the number of rules involved can only be determined by careful inspection. Example: From the table shown in Example 1 of Appendix B (Supplement), the following counts are obtained: 4, 2, 1, 1, 8. The total number of "simple" rules is therefore 16.
Record B
Examples of various decision tables
(Supplement)
Example 1: Restricted item decision table
Table 3 Control changes
Are there any records left?
Same as previous member?
Same as previous section
Same as previous department
Merge records
Print member details
Change section totals
Print section totals
Change department totals
Clear section totals
Print department totals
Change totals
Clear department totals
Print new title
Processing table?
Processing Table 4
GB/T15535—1995
Example 2: Extension Item Decision Table
Table 7 Deductive Analysis
Grading One
Deductive Code =
Set Deductive Value One
Processing Table
Example 3: Conversion from Extension Item Table to Restricted Item Table Note: For logical completeness,
The restricted item table below is an example of how to convert from the extension item table shown in Example 2. The ELSE rule has been introduced with an additional action line. Deductive analysis
Classification—1
Classification—2
Classification=3
Classification=4
Deductive code-0
Deductive code=A
Deductive code B
Set deductive value to 0
First deductive value=10
Set deductive value=20
Last deductive value-30
Deductive value=40
Last deductive value—60
Processing table 6
Processing table 8
Processing table 9
Processing table 20
Example 4: Comprehensive item determination table
Basic change (Table 13)
End of transaction document
End of main input document
Key comparison TM-
T code 1Extension Item Decision Table
Table 7 Deductive Analysis
Grading One
Deductive Code =
Set Deductive Value One
Processing Table
Example 3: Conversion from Extension Item Table to Restricted Item Table Note: For logical completeness, the restricted item table below is an example of how to convert from the extension item table shown in Example 2. The ELSE rule has been introduced with an additional action line. Deductive analysis
Classification—1
Classification—2
Classification=3
Classification=4
Deductive code-0
Deductive code=A
Deductive code B
Set deductive value to 0
First deductive value=10
Set deductive value=20
Last deductive value-30
Deductive value=40
Last deductive value—60
Processing table 6
Processing table 8
Processing table 9
Processing table 20
Example 4: Comprehensive item determination table
Basic change (Table 13)
End of transaction document
End of main input document
Key comparison TM-
T code 1Extension Item Decision Table
Table 7 Deductive Analysis
Grading One
Deductive Code =
Set Deductive Value One
Processing Table
Example 3: Conversion from Extension Item Table to Restricted Item Table Note: For logical completeness, the restricted item table below is an example of how to convert from the extension item table shown in Example 2. The ELSE rule has been introduced with an additional action line. Deductive analysis
Classification—1
Classification—2
Classification=3
Classification=4
Deductive code-0
Deductive code=A
Deductive code B
Set deductive value to 0
First deductive value=10
Set deductive value=20
Last deductive value-30
Deductive value=40
Last deductive value—60
Processing table 6
Processing table 8
Processing table 9
Processing table 20
Example 4: Comprehensive item determination table
Basic change (Table 13)
End of transaction document
End of main input document
Key comparison TM-
T code 1
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.