JPS62267842A - Program checking system - Google Patents

Abstract

PURPOSE:To improve the synthesizing performance and efficiency of a program of a data type reasoning system by using a chart produced in response to the pattern of a data flow to produce the structure of a each module. CONSTITUTION:A data flow 92 of the data 89 is checked and the data 88 written to the flow 92 is read. Then the types of both data 89 and 88 are checked. A data flow 91 of the input data 87 is checked for an instruction 83 using the data 88 as an output and the data 86 is read. Then the types of both data 87 and 86 are checked together with the types of both data 85 and 84. If an unmatched part is detected, the data flow is traced like a check mode of data types. Thus the unmatched part is successively corrected. These check and correction actions are repeated until no unmatched part exist any more. Thus a complete program is obtained.

Description

[Detailed Description of the Invention] [Industrial Application Field] The present invention relates to a program check method, and in particular, in program development, the present invention uses diagrams to express structures corresponding to complex data flow patterns, and data types. The present invention relates to a program checking method suitable for performing inference and data flow analysis.

[Conventional technology]

BACKGROUND ART Today, the increasing cost required for software creation is considered a problem, and various methods for automatically generating programs are being researched as a means to solve this problem. On the other hand, the amount of software that requires a considerable amount of man-hours to create in program development is also increasing, and research into reusing such software is also underway.

In such automatic program creation and software reuse, data type consistency is important. In languages with dives, if the data types are inconsistent, the program cannot be executed, and in symbolic processing languages such as LISP and PROLOG, data type consistency is not so much of an issue, but data type information cannot be used. This makes it possible to detect programming errors and the like. Therefore, attempts have been made to infer the data type from the font of the program, and methods to analyze the data while directly tracing the data flow have been proposed.

In this regard, see, for example, the Proceedings of ``Type Interfaces in Logic Languages and Their Application to Type Checking''.
This can be seen at the 26th National Convention of the Information Processing Society of Japan (first half of 1981).

[Problem that the invention seeks to solve]

In the conventional example above, the method analyzes the data flow by directly following it, so there is a problem that it is difficult to accurately analyze complex data flows, exclusive data flows, hierarchical data flows, etc. there were. In addition, for data that occurs only in an exclusive manner, it is not possible to distinguish it from other data when analyzing only the data flow, and there is a problem that accurate data exchange analysis cannot be performed without referring to the control flow. .

The purpose of the present invention is to solve such conventional problems, to be able to perform data type checking and modification by inference even for modules with complex connection relationships, and to improve control flow even for data flows between exclusive events. The purpose of the present invention is to provide a program check method that allows accurate data type checking without reference.

[Means for solving problems]

In order to solve the above problems, in the present invention, a group of software modules representing calculation procedures of a computer are combined into one.
In order to generate a complete piece of software, the characteristics of a software module are expressed in a set of structures, and the information in the structure is used to transfer data between software modules based on the data type. In the program checking method that checks and corrects by inference, the above structure contains data flow between modules (
A mechanism is provided to indicate the data flow), the connection relationships of modules are expressed in a diagram according to the data flow pattern, the diagram is expressed in a structure, and an identifier is assigned to data that occurs exclusively. The information on the structure and the above mechanism are used to check and modify the data type of hierarchical modules, modules forming networks, modules with complex connection relationships, etc.

Furthermore, it is characterized in that it also performs a data type check on data that occurs exclusively using the above identifier.

[Effect]

In order to search for data flows such as hierarchical module structures, modules forming networks, and modules with complex connection relationships, you can create diagrams according to data flow patterns and use them to search for each data flow. It facilitates the creation of module structures and improves the efficiency and performance of program development (program synthesis) through data type inference. Furthermore, in the data flow analysis method, for data flows related to control flows that occur exclusively, an identifier is attached to the data passed by that data flow to distinguish it from other data flows, and By checking the data type between events, the entire data flow can be analyzed without referring to the control flow.

〔Example〕

An embodiment of the present invention will be described below in detail with reference to the drawings.

This embodiment will be explained separately into a first embodiment and a second embodiment.

(2) First Embodiment The characteristics of each software module (program module) whose program is checked in the first embodiment are expressed in the following structure.

((I/O data type) (Data flow) (Module inclusion relationship) (Modification rules) The data flow mechanism of the second structure includes information on which data is received from which module and which data is passed to which module. In addition, for data flows that occur exclusively, an identifier is attached to the data.

FIG. 1 is a block diagram of an interactive computer support system showing one embodiment of the present invention. This is a system for interactively developing programs (for example, program synthesis) and testing using a computer.

In FIG. 1, l is a video data terminal for interactively checking the data type of a program, etc., and has a display and a keyboard.

2 is a computer processing device, and 3 is a storage file of a software module. 4 is a program synthesis control section, and a data type check section 5. Modification order control unit 6, inference control unit 7. It includes a dialogue modification section 8.

FIG. 2 is a flowchart showing the program check processing procedure in FIG. 1.

First, under the control of the program synthesis control unit 4 in the computer processing device 2, the structure of each module is read from the storage file 3 (step 201), and the data flow of output data of a module that is not included in any module is read ( Step 202), and the data written there is read (Step 203). Next, it is checked whether the data has an identifier (step 2o4). Classify the data by identifier, perform a data type check for each classified data flow (step 205), then perform a data type check on all data flows that can be traced from that data flow in the same way as in the first case. After that, data types are checked in the same way for data flows that cannot be traced from the output.

After checking all data flows (step 206), if there are no inconsistent parts (step 207)
), the process ends. If there is an inconsistent part, perform the corrections shown below. To correct the data flow of the inconsistent part, as in the case of data type checking, the data flow,
Read the data (steps 208, 209), check the identifier of the read data, and correct the input/output data mechanism of the structure for the inconsistent data for each data classified by the identifier (step 2 to 209). ,
211). After the modification, data flows affected by the modification are traced one after another and modified in the same way. When all possible data flows have been corrected (step 212), the process returns to the first step 201 and the entire data type is checked. Repeat this operation until there are no inconsistent parts.

Next, a procedure for creating charts according to data flow patterns will be explained using the C0BOL language.

FIG. 3 is a diagram showing an example module of a pattern that executes a certain command on input data and outputs the result.

In FIG. 3, 31 is a module, 32 is input data, and 33 is output data. Commands included in this pattern include ADD, MOVE, READ, WRITE, etc. Specifically, taking MOVE as an example, MOVE (
Data 32) TO (Data 33) corresponds to the source code. Here, READ uses the file name as input data.

Use record name as output data.

FIG. 4 is a diagram showing an example module of a pattern that executes a certain command on a plurality of input data and outputs the result.

In FIG. 4, 41 is a module, 42, 43 is input data, and 44 is output data. Commands of this pattern include COMPUTE and the like, and although this example shows a case where there are two input data, the same applies to a case where there are three or more input data. To give a specific example, COMPUTE (data 44) = (data 42) * (data 43).

It corresponds to the source code.

FIG. 5 is a diagram showing an example of a module having only input data and no output data.

In FIG. 5, 51 is a module and 52 is input data. This pattern of instructions has 0 as an executable statement.
This pattern includes PEN, CLO5E, etc., and the IF condition determination section is also displayed in this pattern.

For OPEN and CLOSE, the input data is a file name, and for the condition part of IF, the input data is data for performing condition determination.

As a specific example, IF (data 52) = 1 It corresponds to the source code.

FIG. 6 is a diagram showing an example of modules in a hierarchical pattern. Here, the input data is data that is input to the internal module, and the output data is data that is output from the internal module.

In FIG. 6, 61 is a module, 62 is an internal module (module) of module 61, 63 is input data of module 61, and 64 is input data of module 62, which is the same as input data 63. 65 is the output data of module 62.

This is the same as the output data 66. 66 is output data of the module 61. This pattern of modules includes P
Includes E RF ORM, etc. The internal module may be PERFORM, which may also have a hierarchical module structure, or may be an executable statement. A specific example is PERFORM (module 61).

(Module 61) SECTION.

MOVE (data 64) To (data 65).

EXIT.

It corresponds to the source code.

FIG. 7 is a diagram showing five ORT instructions in modules.

In FIG. 7, 67 is a module, 68.69170
is the internal module (module) of module 67, 7
1.72 is input data of module 67, 73 is input data of module 68, 74 is output data of module 68, 75.76 is input data of module 69, 77
is the output data of module 69, 78 is the output data of module 70
, 79 is the output data of module 7o, 8
0 is the output data of module 67. module 6
8 is an input procedure section that includes a RELEASE command. Module 69 is a 5ORT command, which takes the file name and sort key as input and outputs the file name. Module 70 is an output procedure section that includes a RETURN instruction.

A specific example is 5ORT (data 75).

O N A S C E N D I N G K E
Y (data 76).

INPLIT PROCEDURE (Module 6
8).

○UTPUT PROCEDURE (Module 6
9).

It corresponds to the source code.

FIG. 9, which will be described later, is a diagram showing the 5EARCH instruction. In the specific example, 5EARCH (data 97) AT ENDCON
TINUE.

'/'V HE N (Data 101 (Data 100)
) = (data 102).

ADD I To (data 103).

END-5EARCH.

It corresponds to the source code.

As described above, by displaying each instruction in a diagram and connecting each data exchange with a data flow, the connection relationships of all modules can be shown in the diagram. Part 8 to be described later
The figure shows a hierarchical pattern shown in FIG. 6 by connecting two modules of the pattern shown in FIG. 3.

Below, examples of simple module groups and complex module groups will be shown, and the procedure for generating a complete program will be explained.

FIG. 8 is a diagram showing an example of a simple software module group according to the first embodiment. This is an example of a hierarchical module group.

In FIG. 8, 81 is a module, 82, 83 is an instruction, 84 is input data of the module 81, and 85 is an instruction 82.
86 is the output data of the instruction 82, 87 is the input data of the instruction 83, 88 is the output data of the instruction 83, 8
9 is the output J data of the module 81, 90 is the data flow from the input of the module 81 to the instruction 82, 91 is the data flow from the instruction 82 to the instruction 83, and 92 is the data flow from the instruction 83 to the output of the module 81. be.

Here, the function of module 81 is to perform instructions 82 . It executes an instruction 83 and outputs the result as data 89.

Next, the procedure for generating a complete program will be explained using FIG.

First, the data flow 92 of the data 89- is examined, the data 88 written there is read, and the data types of the data 89 and the data 88 are checked.

Next, regarding the instruction 83 that outputs the data 88, the data flow 91 of the input data 87 is examined, the data 86 is read, and the data types of the data 87 and the data 86 are checked. Similarly, the data types of data 85 and data 84 are checked, and if there is any inconsistency as a result, the data flow is followed in the same way as in the case of data type checking, and corrections are made sequentially.

If there are no inconsistent parts, it is a complete program.

This data type checking and correction operation is repeated until there are no inconsistent parts to generate a complete program.

FIG. 9 is a diagram showing an example of a complex software module group according to the first embodiment. This shows the 5EARCH instruction.

In FIG. 9, 93 is a module, 94 is a search, and 95 is a module.
is the instruction, 96.97, 98.99 is the module 93 (7
1 input data, 100, 101, 102 are input data of search 94, 103 is input data of instruction 95, 104 is output data of search 94, 105 is output data of instruction 95,
106 and 107 are module 93 (7) output data, 1
08,109° 110 is the data flow from the input of the module 93 to the search 94, txt is the data flow from the input of the module 93 to the instruction 95, 112 is the data flow from the search 94 to the output of the module 93, 113 is the instruction 95 9 is the data flow to the output of module 93. Here, the function of the module 93 is to use the search 94 to check the array format data 101 in order from the 100th data to see if there is any that is the same as the data 102, and if there is the same, output the array number as the data 104. It also outputs data 105, which is the result of executing instruction 95 on data 99, and in C0BOL,
This corresponds to the search function.

Next, the procedure for generating a complete program will be explained using FIG.

As in the case of FIG. 8, data flows 112 and 113 are traced from data 106 and 107, and data flows 104 and 10
Perform data type check with 5.

Then, trace data 100, 101.1027, 1%, etc. data 70-108, 109, 110, and data 98
, 97.98, and also traces the data flow ill from data 103 to data 99.
Perform data type check with.

As a result, if there is no inconsistency, the data type check is completed, and if there is any inconsistency, the data flow is similarly followed and corrected. 1 until a complete program with no inconsistencies
Repeat the above operations.

Here, in both FIGS. 8 and 9, there is only one data flow for each data, so the RA separate check is not relevant.

In this manner, in the first embodiment, the structure of each module can be easily expressed by using a diagram corresponding to the data flow pattern, thereby facilitating the data flow search. Therefore, data types can be inferred even for complex functions as shown in FIG. 9 using the same method as for simple functions as shown in FIG. In addition to COBOL, PAS
CAL.

PL/1. A similar system also holds true for other languages such as PL/H.

(2) Second Embodiment The characteristics of each software module whose program is checked in the second embodiment are expressed in the following structure.

((input/output data type) (data flow) (module inclusion relation) (module function) (modification rule) Data that occurs only exclusively in the data flow mechanism of this structure should be given an identifier. attach to it.

FIG. 10 is a block diagram of an interactive computer support system showing a second embodiment of the present invention. This is a function of the data identification section 9 in the program synthesis control section 4 of the system configuration shown in FIG.
is added. Therefore, please refer to FIG. 1 for details.

In the program generation (program synthesis) performed in the first embodiment, there was only one identifier for each data, but for events that occur exclusively, one data can be used for multiple (two or more) Flows may exist. Therefore, an identifier is attached to data that occurs only in an exclusive manner, the identifier is identified by the data identification section 9, and the identification result is used for checking the data type that occurs in an exclusive manner.

FIG. 11 is a flowchart showing the control procedure of the second embodiment. The operation of this embodiment will be explained below with reference to FIG.

First, a data flow is read from the structure of the module to be checked (step 1101). Read the data written to that data flow from the input/output data type mechanism of the structure of the module that has that data (
Step 1102). It is checked whether an identifier is attached to each data (step 1103). If there is accompanying data, depending on the type of identifier,
Classify the data (step 1104). For each classified data, data transfer between modules is checked (step 1105). If there is no data with an identifier attached, all data is checked at once (step 1106), and so on.

A procedure for performing a program check will be explained by showing a specific example of a software module (program check) group having data that occurs exclusively.

FIG. 12 is a diagram showing the connection relationship of a group of software modules according to the second embodiment.

In FIG. 12, 120 is a module, 12■ is a condition, 122 is an instruction, 123 and 124 are input data of the module 120, 125 is input data of the instruction 122, 126
is the output data of the instruction 122, 127 is the module 120
The output data of 128 is the input of condition 121, data 1
29 is a data flow from the input of the module 120 to the instruction 122;

130 is a data flow from the output of the instruction 122 to the output of the module 120, 131 is a data flow from the input of the module 120 to the output of the module 120, and 132 is a data flow from the input of the module 120 to the condition 121. Here, the function of the module 120 is that if the data 123 does not satisfy the condition 121, the data 124
is output as is, and if condition 121 is satisfied, data 1
24, data 126 which is the result of executing the instruction 122 is output.

Next, with reference to FIG. 12, a procedure for performing a data crab check on data that occurs exclusively will be explained.

First, the data flow on the output side of the module 120 is read, in which two data flows 130 and 131 are written. Each data flow reads data 124 and data 126.

Here, since the data 126 is data that occurs only when the condition 121 is satisfied, the identifier "1" is attached thereto. By checking the identifiers of data 124 and data 126, data 124. Data 126 is classified into two types. First, the data 126 with the identifier “1”
Then, for the instruction 122 that uses the data 126 as output data, the data flow 129 of the input data 125 is read, and the data 124 written there is read. Since there is only one flow, check the data type of data 124 and data 125. Next, check the data type of data 124 with no identifier attached to data 127. This will allow you to check the data type of data 124 and data 125. As for the flow, everything has been checked. Next, the data flow 132 of the input data 128 of the condition 121 is read, and the corrupted data 123 is read therein. Here, since there is only one data flow, the data types of data 123 and data 128 are checked. Now that we have checked all the data flows within module 120, we can output a list of inconsistencies or a message indicating that they are consistent to the display of the video data terminal l, and
Finish the data type check within.

FIG. 13 is a diagram showing the connection relationship of another software module group according to the second embodiment.

In FIG. 13, 135 is a module, 13"8,1
37 is an instruction, 138 is a condition, 139 is a module 135
140 is the output data of the module 135, 141 is the input data of the instruction 136, 142 is the instruction 13
6 output data, 143 is input data of instruction 137, 1
44 is the output data of the instruction 137, 145 is the input data of the condition 138, 146 is the data flow from the input of the module 135 to the instruction 136, 147 is the data flow from the instruction 136 to the instruction 137, and 148 is the data flow from the instruction 137 to the condition 138. 149 is the data flow from the instruction 137 to the instruction 136, and 150 is the data flow from the instruction 137 to the output of the module 135. here,
The function of module 135 is to execute instructions 136 and 137 on input data 139, and then repeat instructions 136 and 137 until the output data of instruction 137 satisfies condition 138.

Next, with reference to FIG. 13, a procedure for checking data types of other software module groups in the second embodiment will be explained.

First, data flow 15 of the output part of module 135
0 is read, and the data 144 written there is read. Here, since there is one data flow, data 14
4 and data 140 are checked. Next, the input data 14 of the instruction 137 that outputs the data 144 is
3 data flow 147 is read, and the data 142 written therein is read. Here, the data flow is 1
Since it is a book, it performs a data type check for data 142 and data 143, and also an instruction 1 that outputs data 142.
36 input data 141 data flows 149 and 146
Read the data 14 written in each data flow.
4. Read data 139. Here, data flow 1
49 occurs exclusively due to condition 138, so the data 144 is attached with the identifier "2". By checking the identifiers, data 144 and data 139 are classified into two types. First, data types of the data 144 and the data 141 attached with the identifier "2" are checked. Next, a data type check is performed on data 139 without an identifier and data 141. This completes the checking of all data flows that can be traced from the output data 140.

Next, 1 condition 138 human data 145 data flow 1
48 and the data 144 written therein. Here, there is only one data flow, so data 1
44 and data 145 are checked. Now that we have checked all the data flows inside the module 135, we can output a list of inconsistencies or a message that there is consistency, and
Finish the data type check in 5.

In this way, in the second embodiment, data flows that only occur exclusively can be classified and checked as appropriate, so data flows 130 and 131 in FIG. Data flow 146 and data flow 149 in FIG. 13 can also be checked individually.
Check and confuse mutually exclusive events at once. This does not happen, and accurate data type checking can be performed. Further, correction in the case of data type inconsistency can be performed in the same manner as in the first embodiment.

〔Effect of the invention〕

As explained above, according to the present invention, by creating a diagram according to a data flow pattern and using it to create a structure for each module, data type checking and correction in data type inference can be easily performed. Since it is possible to easily search for a data flow for a program, it has the effect of improving the performance efficiency of program synthesis using a data type inference method. Furthermore, data flows that can only occur in an exclusive manner are classified into data flows according to the case without being confused with other data flows, and data types are checked for each group of classified data flows. Performance is improved because you can do complete data type checking without referencing the control flow.

It has the effect of improving efficiency.

[Brief explanation of drawings]

Fig. 1 is a configuration diagram of an interactive computer support system showing a first embodiment of the present invention, Fig. 2 is a flowchart showing a control procedure of the first embodiment, and Figs. 3 to 7 show each program module. A diagram representing a structure in a diagram according to a data flow pattern, FIG. 8 is a diagram of the connection relationship of a group of software modules according to the first embodiment, and FIG. 9 is a diagram of the connection relationship of a group of other software modules according to the first embodiment. 10 is a configuration diagram of an interactive computer support system showing a second embodiment of the present invention, FIG. 11 is a flowchart showing a control procedure of the second embodiment, and FIG. 12 is a group of software modules according to the second embodiment. FIG. 13 is a diagram showing the connectivity of a group of software modules according to the second embodiment. 1: Video data terminal, 2: Computer processing unit, 3: Accumulated file, 4 Niprogram synthesis control unit, 5:
Data type checking section, 6: Modification order control section, 7: Inference control section, 8: Dialogue modification section, 9: Data identification section. Figure 2 Figure 3 Figure 4 Figure 6 Figure 6 Figure 7 Review Figure 8 8.4 Figure 9 IQd 107

Claims (1)

[Claims] 1. In order to combine a group of software modules representing calculation procedures of a computer to generate one completed software, the characteristics of each software module are expressed in a group of structures, and the characteristics of each software module are expressed in a group of structures. In a program checking method that uses structure information to check the data exchange between software modules based on the data type and make corrections based on inference, the above structure contains information about the flow of data between modules (data flow). Flow)
A module that represents the coupling relationship of modules in a diagram according to a data flow pattern, expresses the diagram in a structure, and uses the information of the structure and the above mechanism to form a hierarchical module, A program check method that is characterized by checking and modifying data types of modules forming a network, modules with complex connection relationships, etc. 2. Express the characteristics of the software modules in a group of structures and use the information in the structures in order to combine a group of software modules that represent computer calculation procedures to generate one complete piece of software. By doing this, in a program checking method that checks the data exchange between software modules based on the data type and makes corrections based on inference, a mechanism that indicates the data flow between modules is included in the above structure. established,
The connection relationships of modules are expressed in a diagram according to the data flow pattern, the diagram is expressed in a structure, an identifier is attached to data that can occur exclusively, and the information in the structure is The above mechanism is used to check and modify the data type of hierarchical modules, modules forming networks, modules with complex connection relationships, etc., and data that is excluded due to the above identifiers. A program checking method that also performs type checking.