JPH11110252A - Device and method for suporting program development, and storage medium recorded with program development support software - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a program development suport technology high in reliability. SOLUTION: The test is executed at the desired condition of a given program 1 by a test part 2, an execution log when a user admits as a correct behavior is stored as test information 3 in a preservation part 4. By adding a guard command for suppressing the behavior that is not recorded in the execution log saved, a change part 5 changes to a program 6. This guard command is generated as a conditional sentence for starting an operation in a program. The behavior which is not tested cannot be guaranteed that it is correct, but since the program 6 attached by the guard command does not perform such a behavior as the untested one, a failure by having non-decisiveness is avoided and reliability of the program is greatly improved.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an improvement in technology for supporting the development of a program for an information processing apparatus represented by a computer, and more specifically, to a technique for developing a highly reliable program. Things.

[0002]

2. Description of the Related Art In order to develop a computer program, a program source code is created using a dedicated program development support device, and a test is executed and a mistake is eliminated (debugged). Such a program development support device has dedicated functions such as an editor and a simulator for executing a test, and is also called a CASE tool or the like.

[0003] Originally, a computer program controls the operation of the computer according to the situation.
If the input changes, the operation changes according to the contents of the program.
However, there are programs that show various operations beyond the range of behavior designed in advance in this way. Such a program whose execution behavior is non-deterministic is called a non-deterministic program. On the other hand, a program whose behavior is uniquely determined when an input is determined as described above is called a definitive program.

[0004] A typical example of a non-deterministic program is a concurrent program. In a concurrent program, a plurality of processes cooperate while operating separately, so that the overall operation differs depending on which part of each process is executed and at what timing. In addition, even when the program itself has no concurrency, non-determinism occurs in the execution order due to the timing of input from the outside and the like, and some programs exhibit virtual non-determinism. For example, IF
In a -THEN rule-type program, the execution order of the rules may change depending on the timing of external input.

[0005] In addition, the nondeterminism in question here is that the semantics of the programming language are ambiguous, that is, the grammar is not unified. This includes cases where the behavior of concurrent programs differs due to stability.

[0006]

The development work for testing and debugging a non-deterministic program represented by a concurrent program is described in "CE McDowell, DP He
lmbold, Debugging Concurrent Programs, ACM Computi
ng Surveys, Vol.21, No.4, 1989. " This is because, when a conventional test / debugging method is applied to a nondeterministic program, the program has a nondeterministic behavior.
Is huge depending on the combination of conditions, and (2)
This is because there is a problem that the bug itself is not reproducible. Approaches conventionally used to solve this problem can be classified into the following three types. (1) Program test technology (such as a debugger for concurrent programs) (2) Program verification technology (such as verification of concurrent programs) (3) Program synthesis method (such as generation of a program from specification description by logic) There are problems that (1) a large part depends on the skill of each user, and (2) it can be applied only to a simple program such as a simplified example.

Further, even in a program that has been sufficiently tested in the test process, the actual environment differs from the test process in the execution environment, that is, the performance of the machine, the input timing, the processing system, and the like. ,
Failure often occurs. In a system that requires high reliability, such as a bank online system, such a bug may cause a fatal accident.

In order to solve such a problem, the present applicant has proposed ultra-sequential programming as a technique for developing a highly reliable concurrent program (Japanese Patent Laid-Open No. 16429/1996). In this technique, a parallel program is temporarily serialized, test execution and debugging are performed on the program, and the entire concurrent program is generated again from the global state transition system in which correct execution logs are merged.

However, in this technique, it is necessary to handle a state transition model having a size corresponding to the size of the program, and it is necessary to serialize the parallel program once and generate it again. For this reason, when the size of the concurrent program is increased, the entire processing amount is increased, and efficient application is difficult.

The present applicant has proposed a programming support device using a scenario. In this technique, the execution order of each part included in a process is represented by a scenario in a state transition diagram format. In this scenario, nodes are connected by edges in a network-like manner. Nodes represent states, edges extending from nodes represent portions of a program that can be executed from the state represented by nodes, and multiple edges are output from one node. Often go. If the user deletes an invalid edge from such a scenario branch, an edge representing a valid execution order remains in the scenario.
By embedding a synchronization command for realizing this order in each process, the execution order recognized by the user is realized.

However, even in this technique, since the entire concurrent program including a plurality of processes needs to be represented in the form of a state transition diagram, a complicated state transition diagram must be handled in proportion to a complicated concurrent program. There was a problem. Also, there are problems that the program becomes complicated and difficult to understand and the capacity increases due to the synchronization instruction embedded in the program. Further, when a synchronization instruction is embedded in a program as described above, the synchronization instruction existing in the program from the programming (coding) stage and the synchronization instruction newly embedded in order to realize the execution order as described above are mutually exchanged. This could have an effect, and we had to be careful with coding to avoid this.

Further, the present applicant has proposed a super-sequential programming invention suitable for programming interrupt processing. In this technique, in a program that uses interrupt processing, a candidate location where interrupt is to be permitted is temporarily specified to test execution. Then, when the user recognizes that the execution result is correct, an interrupt permission instruction is actually added to the candidate where the correct result is generated.

[0013] However, this technique is troublesome in that it is necessary to specify in advance a candidate location for which interruption is to be permitted.

Further, as another conventional technique, an incomplete program in a rule format is input, and a condition is automatically added to a condition part of the rule by using a predetermined algorithm. (Japanese Patent Application Laid-Open No. 6-59879) has been proposed which outputs a program supplemented with. With this technology, if you enter a program that is partially missing,
An experimental program that fills in the missing parts is created. The execution and modification of the experimental program are repeated while measuring the overall performance such as the required execution time, and a program with excellent characteristics is finally created. However, Japanese Patent Application Laid-Open
The -59879 was primarily intended to improve performance, and did not eliminate nondeterministic problems by identifying the correct operation of the program.

The present invention has been proposed to solve the above-mentioned problems of the prior art, and an object of the present invention is to provide a technique for developing a highly reliable program. Another object of the present invention is to provide a program development technique for realizing a correct behavior without requiring a new synchronization instruction or interrupt instruction. Another object of the present invention is to provide a program development technique applicable to various programs such as a parallel logic type program, a rule type program, and a blackboard type concurrent program.

[0016]

According to a first aspect of the present invention, there is provided a program development support apparatus for supporting a program development, wherein the program development support apparatus tests a given program; Means for changing the program so as to exhibit correct behavior using information obtained in the test. According to the first aspect of the present invention, when a correct behavior is obtained by executing and testing a given program, the program is changed so as to exhibit the correct behavior, thereby improving the reliability of the program.

According to a second aspect of the present invention, there is provided a program development support apparatus for supporting a program development, comprising: means for testing by executing a given program; It is characterized by comprising means for storing an execution log, and means for changing a program by adding a guard instruction for suppressing a behavior not recorded in the stored execution log. A program development support method according to a fifteenth aspect grasps the invention according to the second aspect from the viewpoint of the method. In a program development support method for supporting program development, a step of executing a given program to execute a test is provided. Saving the execution log when the behavior of the program is determined to be correct, and modifying the program by adding a guard instruction that suppresses behavior not recorded in the saved execution log,
It is characterized by including. According to a nineteenth aspect of the present invention, the invention of the second aspect is grasped from the viewpoint of a recording medium that records software for supporting program development for supporting program development by controlling a computer. Is a program that allows a computer to test a given program by executing it, save an execution log when the behavior of the program is found to be correct, and suppress the behavior not recorded in the saved execution log. It is characterized in that the program is changed by adding an instruction.

According to the second, fifteenth, and nineteenth aspects of the present invention, the program is test-executed under desired conditions, and an execution log is stored when the user determines that the behavior of the program is correct. Then, a description that suppresses a behavior that is not recorded in the execution log recognized as correct is added to the program. Such a description is called a guard instruction and represents a condition that must be satisfied prior to a certain operation in the program. Untested behavior is not guaranteed to be correct, but programs with guard instructions do not perform such untested behavior. For this reason, problems due to non-determinism are avoided, and the program is highly reliable. The “guard instruction” is a broad concept including not only an execution instruction in a narrow sense but also various statements such as a declaration statement and a conditional clause of the instruction and a part thereof. The terms “add” and “insert” for the guard instruction broadly mean that the guard instruction realizes the state that exists in the program, and not only to add a new guard instruction, but also to other statements that already exist in the program. Various modes are included, such as replacing a character string, inserting a new character string, and deleting a part of the character string. According to the present invention, there is no need to handle a state transition model or scenario of a scale corresponding to a program to be developed.
In addition, since the entire program is not reconfigured, the processing is simplified, and it can be easily applied to a large-scale program. Further, according to the present invention, it is not always necessary to embed a completely new synchronous instruction or interrupt-related instruction in the program, so that the program becomes complicated or the synchronous instruction or interrupt-related instruction used in coding may be affected. Absent. Note that the addition of the guard instruction
This can be performed by rewriting an existing statement in the program, but can also be performed by inserting a new statement.

According to a third aspect of the present invention, in the program development support apparatus according to the second aspect, the changing means extracts a non-deterministic part whose behavior is not uniquely determined from a given program; For the extracted non-deterministic part, there is provided a means for generating the guard instruction, and means for adding the generated guard instruction to the non-deterministic part. According to a sixteenth aspect of the present invention, the invention of the third aspect is grasped from the viewpoint of a method. In the program development supporting method according to the fifteenth aspect, the changing step is such that the behavior is uniquely determined from a given program. Extracting a non-deterministic part, generating the guard instruction for the extracted non-deterministic part, and adding the generated guard instruction to the non-deterministic part. It is characterized. According to a twentieth aspect, the invention of the third aspect is grasped from the viewpoint of a recording medium on which software for supporting program development is recorded.
9. In a recording medium recording the program development support software according to 9, the program development support software has a nondeterminism that when the program is changed, the behavior of the computer is not uniquely determined from a given program. A part is extracted, the guard instruction is generated for the extracted nondeterministic part, and the generated guard instruction is added to the nondeterministic part. Claims 3, 16, 20
According to the invention, when a program is changed, a nondeterministic part is first extracted from the program, and a guard is generated and added to this part, thereby avoiding a problem caused by the nondeterminism.

According to a fourth aspect of the present invention, in the program development support device according to the second or third aspect, the program to be developed is a parallel logic type program including a plurality of clauses, and From a logical program,
A plurality of simultaneously executable clauses are extracted as nondeterministic parts, and a guard instruction that suppresses variables of predicates included in the extracted clauses so as to match only the execution sequence recorded in the execution log is used. The guard instruction is generated and added to the non-deterministic part. In a parallel logic type program, an object to be executed (unified) for each clause is specified by a predicate name and a variable, and it is determined in parallel whether or not the clause is executable. There may be more than one possible clause candidate. In this case, only one clause is selected and executed, but it is often indeterminate which candidate is selected, and the behavior of the program may change depending on which candidate is executed. In the invention according to claim 4, even when there are a plurality of clauses that can be executed simultaneously, the non-determinism of the parallel logic type program is suppressed by using the guard instruction that limits the target of unifying the variable of the predicate, Correct behavior is achieved.

According to a fifth aspect of the present invention, in the program development support device according to the second or third aspect, the program to be developed is a rule-type program in which a rule having a condition part and an execution part is combined. The changing means extracts, from the rule-type program, a plurality of rules that can be executed simultaneously as non-deterministic portions, and for the extracted rules, a pattern match of a condition part is recorded in the execution log. And generating a guard instruction that suppresses the execution so as to conform only to the rules of the execution sequence that is present, and adding the guard instruction to the nondeterministic portion. In the rule type program, each rule has a condition part and an execution part, and a rule whose condition part matches data at each time point is activated, and the processing proceeds by executing the execution part of the rule. Claim 5
According to the invention, even when there are a plurality of rules that can be executed at the same time, rules activated by using a guard instruction that restricts conditions for matching rules are limited, so that nondeterminism of a rule type program is suppressed. , Correct behavior is realized.

According to a sixth aspect of the present invention, in the program development support apparatus according to the second or third aspect, the program to be developed is such that a plurality of processes read and write tuples, which are sets of data stored on a blackboard. A blackboard-type parallel program that performs a cooperative operation by means of the blackboard-type parallel program, wherein a plurality of processes that can be pattern-matched with the same tuple stored on the blackboard are defined as non-deterministic parts. According to the extracted execution process and the saved execution log for the extracted process,
A guard instruction for limiting a process of reading and writing tuples on a blackboard is generated, and the guard instruction is added to the nondeterministic portion.
In a blackboard-type parallel program, the operation of each process changes by reading a tuple on the blackboard, but when an unintended process reads the tuple, a problem occurs due to nondeterminism. According to the sixth aspect of the present invention, the description of the tuple write or read is changed to a guard instruction so as to limit the process of reading the tuple that causes nondeterminism. As a result, nondeterminism of the blackboard-type concurrent program is suppressed, and correct behavior is realized.

According to a seventh aspect of the present invention, in the program development support apparatus according to the second or third aspect, the program to be developed is a message exchange type concurrent program in which a plurality of processes cooperate by exchanging messages. The changing means extracts, as a non-deterministic part, a process which may receive a plurality of messages in a different order from the message exchange type parallel program, and stores the extracted process. A guard instruction for controlling reception of messages in the order according to the execution log is generated, and the guard instruction is added to the nondeterministic portion. In a message exchange program, the behavior of each process is affected by the messages exchanged between the processes, so when receiving a plurality of messages, the behavior may differ in the order of arrival. According to the seventh aspect of the present invention, a guard instruction for limiting the order in which messages arrive is created by subdividing the name of a mailbox that serves as a buffer for exchanging messages. Thereby, nondeterminism of the message exchange type program is suppressed, and correct behavior is realized.

According to an eighth aspect of the present invention, in the program development support apparatus according to any one of the second to seventh aspects, means for analyzing at least one of a program, an execution log, and a guard instruction, and the generated guard Means for improving the instruction using the result of the analysis. According to a seventeenth aspect of the present invention, the invention of the eighth aspect is grasped from the viewpoint of a method. In the program development support method according to the fifteenth or sixteenth aspect, at least one of a program, an execution log, and a guard instruction is analyzed. And improving the generated guard instruction using the result of the analysis. Claims 8 and 17
According to the invention, the generated guard instruction is not added to the program as it is, but the guard instruction is improved based on the analysis result, so that the efficiency or reliability of the final program is improved. As an aspect of the improvement, a redundant guard instruction is removed, or an abstraction by integrating or extending the guard instruction is used.

According to a ninth aspect of the present invention, in the program development support apparatus according to the eighth aspect, the means for improving includes a guard instruction required from a guard instruction to be added to the program based on a result of the analysis. It is configured to select only one. According to the ninth aspect of the present invention, redundant guard instructions are removed based on the result of the analysis, and only truly necessary guard instructions are selected and added, so that the processing of changes and the contents of the final program are made more efficient. You. For example, of the two guard instructions to be added to a certain part of the program, if the condition required by one guard instruction is satisfied, the condition required by the other guard instruction is always satisfied, only one guard instruction is added.

According to a tenth aspect of the present invention, in the program development support apparatus according to the eighth aspect, the improving means suppresses a more general-purpose behavior of a guard instruction added to the program based on a result of the analysis. It is configured to be abstracted as follows. According to the tenth aspect of the present invention, since the guard instruction added to the program is abstracted, the functions to be implemented are enhanced with respect to the number of guard instructions to be used and the data capacity. The guard instruction is abstracted according to the result of the analysis. Typically, the abstraction is performed by inductively creating a superordinate concept including several types of guard instructions. Further, as one aspect of the abstraction, it is conceivable to extend the condition by adding a new condition with a logical function OR to the condition described in the guard instruction.

According to an eleventh aspect of the present invention, in the program development support apparatus according to any one of the second to tenth aspects,
In a case where a program is to be changed by adding a guard instruction, the program has means for inquiring for each guard instruction whether or not to change the program. Is configured to change the program by adding a given guard instruction. In the eleventh aspect, before rewriting the original program,
Since the user is inquired about whether rewriting is possible, rewriting that restricts the program more than the user desires can be suppressed.

According to a twelfth aspect of the present invention, in the program development support apparatus according to any one of the second to eleventh aspects,
When executing at least one of a portion of the program changed by the changing unit and a portion not included in the execution log, a unit for ensuring execution safety is provided. . The invention according to claim 18 is ascertained from the viewpoint of the method according to claim 12, and in the program development support method according to claim 15, 16, or 17, a part of the program, which is changed by the changing step. And when executing at least one of the parts not included in the execution log,
The method is characterized by including a step of ensuring execution safety.
According to the twelfth and eighteenth aspects, the security is ensured when the changed program is executed. Therefore, even if an unexpected behavior occurs due to rewriting or a behavior not assumed at the time of the modification occurs. Problems and inconveniences are minimized, and the reliability of the program is improved. Here, as a mode for ensuring the execution safety, when executing the changed part or when a behavior not in the execution log occurs, a warning is output or data for recovering from the failure is stored. And so on.

According to a thirteenth aspect of the present invention, in the program development support apparatus according to the twelfth aspect, the means for ensuring the security is included in a part of the program changed by the changing means and the execution log. When at least one of the parts that has not been executed is executed, a warning is output to ensure the execution safety. According to the thirteenth aspect, a warning is output when a changed part or a part that has not been tested is executed, so that the user can determine the reliability of the program or take various measures in preparation for a failure. This makes it easier to respond. In this case, a portion of the program to be changed may be marked with a software mark, and at the time of execution, the appearance of the mark may be detected and a warning may be displayed. Note that the warning may be selectively displayed from among several types of prepared warnings. For example, if a different warning is displayed for each changed part, the execution state of the program can be grasped concretely.

According to a fourteenth aspect of the present invention, in the program development support device according to the twelfth aspect, the means for ensuring the security is included in a part of the program changed by the changing means and the execution log. When executing at least one of the parts that have not been executed, data representing the execution state of the program at that time is stored. According to the fourteenth aspect, when the changed portion or the untested portion is executed, data representing the execution state of the program is stored. Therefore, even if a failure occurs in any of these parts, the system can be recovered using the stored data for cause analysis and rollback (reversion), minimizing the impact of the failure. Can be suppressed.

[0031]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Next, a plurality of embodiments of a program development support device according to the present invention will be described with reference to the drawings. Although the present invention can be applied to a conventional sequential program, the following embodiments are directed to a parallel program which is more difficult to develop than a sequential program.

[1. First Embodiment] [1-1. Configuration] [1-1-1. Hardware Configuration] First, the hardware configuration of a computer system used to implement the first embodiment (hereinafter, referred to as “first embodiment”) is as follows.
This is shown in the hardware block diagram of FIG. This computer system has N processors 101-1, 101-2,..., 101-N as shown in this figure, and at least one of the processors realizes the function of the first embodiment. Run the software for Each of the processors 101-1, 101-2,..., 101-N is used to execute each process of the concurrent program simultaneously and in parallel. Each of these processors 101-
, 101-N are connected to the I / O interface 102, and the I / O interface 10
2, the shared memory 103 and peripheral devices can be accessed. The shared memory 103 stores each processor 1
Each of the processes executed on 01-1, 101-2,..., 101-N is used to exchange information and perform a cooperative operation. The peripheral devices include an input device 104, an output device 105, an external storage device 106, and the like.

The input device 104 has a keyboard, a pointing device, and the like, and receives various commands and data input by the user. The output device 105 has a CRT display or the like, and is a device for presenting information on a source program or a debugging situation to a user by text display or graphic display. The user operates these input devices 1
The computer can be operated interactively using the output device 104 and the output device 105. The external storage device 106 is configured to be able to write and read information relating to a source program and debugging status using a magnetic disk device or a magneto-optical disk device.

Although the first embodiment is configured using the above-described multi-CPU system, examples of other configurations include, for example, a parallel computer having a shared memory, a parallel computer having no shared memory, and a distributed network computer. The first embodiment can be realized by using a system, a multi-task computer with a single CPU, or the like.

As a form of a concurrent program on these computer systems, a plurality of processes (also called tasks) are distributed among processors, and an interaction (cooperative operation) is performed between the processes. is there. Interaction between processes includes:-Interaction via shared memory / blackboard-Interaction by message exchange-Interaction by communication channel and stream.

The parallel programming languages include: a language in which a synchronous communication mechanism is added to a procedural language; a parallel logic language; and a parallel rule language.

As described above, each function of the present apparatus is realized by software, and the software uses the above-described series of hardware resources to produce the effects of the first embodiment. . Therefore,
The configuration or type of each hardware resource may be replaced with another configuration or type that performs the same function.

[1-1-2. Configuration of Function] Each function of the first embodiment is realized by controlling the above-described computer system by software. Here, each function of the first embodiment is shown in a functional block diagram of FIG. The first embodiment includes a test unit 2, a storage unit 4, and a change unit 5, as shown in FIG. The test section 2 is a means for testing the correct behavior of the program 1 by executing the given program 1 under various conditions. Means ".

The storage section 4 is a means for storing the test information 3 representing the test result, and corresponds to the "storage means" described in claim 2. The test information 3 is, specifically, an execution log when the user recognizes that the behavior of the program 1 is correct. The changing unit 5 is means for changing the program 1 so as to show a correct behavior obtained in the test.
This corresponds to “means for changing” described in 2. Here, the program 1 is changed by adding a guard instruction. The guard instruction is a behavior that is not recorded in the execution log stored in the storage unit 4, in other words, “is a correct behavior. This is a description that suppresses "behavior that does not occur."

Further, the changing unit 5 specifically has a non-deterministic extracting unit 51, a guard generating unit 52, and a guard adding unit 53. Among them, the non-deterministic extracting unit 51 is a means for extracting a part whose behavior is non-deterministic from the given program 1 and corresponds to “extracting means” in claim 3. Further, the guard generation unit 52 is a unit that generates a guard instruction for the extracted nondeterministic portion,
This corresponds to the "generating means" described in claim 3. Further, the guard adding unit 53 is a means for adding the generated guard instruction to the non-deterministic part, and corresponds to the “means for adding” in claim 3.

[1-2. Operation of the First Embodiment] The first embodiment having the above configuration has the following operation. First, a processing procedure in the first embodiment is shown in a flowchart of FIG. As shown in this figure, in the first embodiment, first, the program 1 is created using an editor or the like, and if necessary, any modification is made in advance (step 1). Subsequently, the test is performed by executing the given program 1 for various test items using the test section 2 (step 2).

That is, the test execution is performed under a number of conditions (test items), and the test items change the contents and timing of test data to be given to the program, and change the execution order for each part of the program. There are several types available. Even if the contents of test data, the timing of application, and the execution order for each part can be variously considered in the manner of permutation combination, this test item is automatically generated in advance for all combinations if the total number is within a certain number. You may. However, if the total number is too large, the test may be repeated using only points or typical examples that are likely to cause problems as test items.

Each time a test is executed for each test item as described above, its execution log is stored in a temporary storage area. The user determines whether the processing result is correct for each execution and inputs the result to the apparatus (step 3). If a failure is found as a result of the test execution (step 3), the process returns to step 1 to debug the program itself. On the other hand, if no defect is found in step 3, the execution log stored in the temporary storage area is an execution log when the execution result is correct, and is copied from the primary storage area to the storage unit 4 as test information 3. It is stored (step 4). By repeating such a procedure, the test is continued until there are no more test items (test data) to be tested (step 5).

When a bug (fault) is found and the program returns to step 1 to correct the program, the execution log stored up to that point is handled as follows. In other words, if the changes made by debugging affect the relationship between the saved execution log and the conditions under which the execution log was obtained, or if the judgment cannot be made, Discard the execution log saved in
The test is performed again on the debugged program 1.
If not, the previous execution log is stored as it is, and new test information 3 is added.

When the accumulation of the execution log is completed as described above, first, the non-deterministic extracting unit 51 (FIG. 2) of the changing unit 5
A non-deterministic part is extracted by analyzing the program 1 (step 6). Here, the extraction of nondeterminism may be performed using a conventionally known technique. For example, if there are instructions between two or more processes that affect reading and writing the same data, but there are no instructions that specify the order or timing of execution of those instructions,
Since two processes are likely to exhibit nondeterministic behavior, they are extracted as nondeterministic parts. The details of the specific method of extracting nondeterminism differ depending on the programming language to be developed. For example, see "Emrath et al., Detecting
Nondeterminacy in Parallel Programs, IEEE Softwar
e, Jan 1992 "(Reference 1).

Subsequently, for each of the extracted nondeterministic parts, the guard generation unit 52 generates a guard instruction for suppressing nondeterminism using the test information 3 (step 7). The guard instruction is a description for suppressing non-deterministic behaviors that are not included in the execution log accumulated as test information, and is generally generated as a conditional statement for starting a certain operation in a program. The details and the method of generating the guard instruction differ depending on the language of the program to be developed. For example, the method can be created as follows.

First, as a case where the execution order becomes a problem between the two parts, there is a case where the two parts are related to each other through some common data such as variables and messages. In such a case, first, such common data is detected from the two parts whose execution order is to be controlled, and the description part relating to the data is rewritten so as to realize the extracted execution order, and the guard instruction is executed. And
The correspondence between what description and what rewriting is performed may be made in advance by creating a comparison table for each language. Then, such a rewriting format is read from the comparison table, and a guard instruction is created by combining the rewriting format with a data name such as an actual variable name.

Such a guard instruction is generally generated as a conditional statement for starting execution of a certain statement. Since the statement to which such a conditional statement is added is not executed unless the condition is satisfied, the statement controls the order of execution between processes. The guard instruction generated in this way is added by the guard adding unit 53 to the corresponding position in the source code of the program 1 to create a modified program 6 (step 8).

Although there is no guarantee that the untested behavior is correct, the program 6 to which the guard instruction is added as described above does not perform such untested behavior. For this reason, according to the first embodiment, problems due to nondeterminism are avoided, and the reliability of the program is greatly improved.

Although the present embodiment can be widely applied to various kinds of languages, the effect of the present invention is particularly large in a pattern matching type parallel programming language, which has many non-deterministic elements. Hereinafter, examples in which the first embodiment is applied will be described for each of the following four types of pattern matching type parallel programming languages. Parallel logic language (GHC) Rule-based language (OPS5) Shared variable or blackboard (blackboard) parallel programming language (Linda-C) Message communication parallel programming language (Ada) [1-3. First Embodiment: Case of Applying to Parallel Logic Language] The first embodiment corresponds to claim 4 and applies the present invention to a parallel logic language GHC. This parallel logic type program includes a plurality of clauses, and an object to be executed (unified) for each clause is specified by a predicate name and a variable. Then, in the parallel logic type program, as a result of judging whether each clause is executable or not in parallel, there may be a plurality of clause candidates that can be executed in a certain situation. In this case, only one clause is selected and executed, and if one candidate is selected and executed, the other candidates will not be executed.

That is, in the conventional sequential logic language, even when there are a plurality of executable clause candidates, the priority order is clearly determined, and the priority is determined at a higher position in the program source code. There was no non-determinism, as the clauses described had precedence. However, in a parallel logic language, whether or not a clause is executable is also determined in parallel, so it is often indeterminate which candidate is selected, and the program depends on which candidate is executed. Behavior can change.

FIG. 4 shows a parallel logic program to be developed in the first embodiment. This program contains each predicate p1, p11, p2, p21,
Each predicate p1, p11, p2, p21 is a description for operating the corresponding process P1, P11, P2, P21, respectively. These processes P1, P11,
FIG. 5 is a conceptual diagram showing that P2 and P21 operate while associating with each other.

In the program of FIG. 4, the predicate p2 is composed of four clauses, but the second clause for even-numbered processing and the third clause for odd-numbered processing can be executed simultaneously with the fourth clause. Therefore, there is nondeterminism in this respect. This non-determinism is referred to as "nd: p2" hereinafter.

When the program shown in FIG. 4 is executed, a phenomenon that a bug occurs or not occurs due to the nondeterminism nd: p2. Here, FIG. 6 shows an example of the execution sequence θ1 having no bug and the execution sequence θ2 having the bug. In these execution sequences, pi / k means the k-th clause of the predicate pi. At the time when the program shown in FIG. 4 is given, the existence of the nondeterminism nd: p2 and the execution sequences θ1 and θ2 are latent and have not been determined yet.

In the first embodiment, when the program 1 shown in FIG. 4 is created in step 1 (program creation) of FIG. 3, in step 2 (test of the program), the program shown in FIG.
The test is performed by executing the test 1 of the program 1 in the test section 2.

At this time, in this program 1, nondeterminism
A bug (FAIL) may or may not occur with nd: p2. That is, the execution sequence θ having no bug shown in FIG.
1 may be obtained, or the execution sequence θ2 having a bug may be obtained. Of the many execution sequences including these two execution sequences θ1 and θ2, only θ1 is executed in the test, and the user confirms that there is no bug in the execution sequence θ1, and when the user inputs that fact, step 4 (execute) In (accumulation of log), the execution log of the execution sequence θ1 is accumulated as the test information 3. It is assumed that θ2 is not executed by chance and no bug is found.

Further, in step 6 (extraction of nondeterminism), the second, third and fourth clauses described above are extracted as a nondeterministic part by analyzing the program 1. The following method is used to extract the nondeterministic portion. That is, in the GHC program, if there are a plurality of executable clauses in the execution process, those clauses are nondeterministic parts. Such nondeterminism can be easily extracted by, for example, creating a GHC interpreter, causing a program to be sequentially interpreted and executed, and specifying an executable portion in the program.

In this case, the following step 7 (guard generation)
Then, on the premise of non-determinism nd: p2, the execution sequence θ1 which is an execution log confirmed to be correct is analyzed. By this analysis, a guard instruction with a stricter constraint to match only the execution sequence recorded in the execution log with respect to unification (pattern match) of the variables of the predicates included in the extracted clause is generated. I do.

In this example, as a result, p2 ([num (N, T) | X], Ou
It can be extracted that N and T in t) are not variables but atoms. For this reason, a guard instruction wait (N) is generated such that this section is unified with only an atom, not with any term.

In step 8 (guard addition), the predicate p2 / 4
Guard instruction wait generated as above instead of true
Modify the program by inserting (N) and wait (T). In the modified program (FIG. 7), the non-determinism such that the execution sequence θ2 having a bug occurs is eliminated by the guard instruction.

As described above, in the first embodiment, even when there are a plurality of clauses which can be executed simultaneously, the use of the guard instruction for limiting the target for unifying the variable of the predicate enables the parallel logical type Nondeterminism of the program is suppressed, and correct behavior is realized.

[1-4. Second Embodiment: In the case of application to a rule-based language] The second embodiment is an application of the present invention to a rule-based language (OPS5). A program in a rule type language is a combination of a rule having a condition part and an execution part. A rule whose condition part matches data at each time is activated, and the execution part of the rule is executed. Goes on.

First, FIG. 8 shows a program described in the rule-based language OPS5 as a development target in the second embodiment. This program counts the total number of odd and even numbers for integer data in the working memory. This program includes rule2, rule3
, As nondeterminism nd for rule4, rule2 for odd numbers
And even-numbered rule3 can be executed simultaneously with rule4.

When this program is executed, a bug may or may not occur due to the nondeterminism described above.
Here, assuming that (data 1 unmark) exists in the working memory, an execution sequence θ1 having no bug and an execution sequence θ2 having a bug are shown. -Execution sequence without bug θ1: rule1 → rule2 → rule4, result (count odd 1) ・ Execution sequence with bug θ2: rule1 → rule4, result (count 1 1) In the second embodiment, step 1 (program creation) )so,
When the program shown in FIG.
In the (program test), when a test is performed by the test unit 2, the above-described execution sequences θ1 and θ2 may be obtained. Here, when the user tests only θ1 out of θ1 and θ2, confirms that there is no bug in the execution sequence θ1, and inputs that fact, step 4 (accumulation of execution log)
Then, the execution log of the execution sequence θ1 having no bug is the test information 3
Is stored in the storage unit 4. It is assumed that θ2 happens not to be executed and no bug is found.

Further, in step 6 (extraction of nondeterminism), rule2, rule3, and rule4 described above are extracted from the program 1 as portions having nondeterminism. In a rule-based program in a rule-based language, if there are a plurality of rules applicable in the execution process, which means nondeterminism, a rule interpreter is created and the program is executed. Nondeterminism can be easily extracted by detecting the portion that becomes available.

In step 7 (guard creation), the execution log of the execution sequence θ1 is analyzed on the premise of the nondeterministic portion extracted as described above.
A guard instruction is generated by strengthening the constraint so that the pattern match of the condition part of the rule matches only the rule of the execution sequence. In this example, (mark ^ val
ue <Type>) is not an integer, but a more specific od
Use as a guard instruction by setting it to d or even.

Then, the guard "odd_" created in this manner is created.
or_even (<Type>) is inserted in place of <Type> in rule 4 in step 8 (addition of guard), and the program shown in FIG.

As described above, in the second embodiment, even when there are a plurality of rules that can be executed at the same time, the rules to be activated by using the guard instruction in which the conditions for matching the rules are limited are limited. Therefore, nondeterminism of the rule type program is suppressed, and correct behavior is realized.

[1-5. Third Embodiment An example in which the present invention is applied to a blackboard-type parallel programming language] A third embodiment corresponds to claim 6, in which the present invention is applied to a blackboard-type parallel programming language (Linda-C). is there. This blackboard-type parallel programming language has multiple processes,
A cooperative operation is performed by reading and writing a tuple, which is a set of data stored on a blackboard (tuple space).

In the blackboard type parallel program, the operation of each process changes by reading a tuple on the blackboard. On the other hand, tuples written on the blackboard can be accessed by all processes unless otherwise specified. Therefore, when there are a plurality of processes that can be pattern-matched with the same tuple, a non-deterministic situation occurs.

In this blackboard-type parallel program, a plurality of processes that can be pattern-matched with the same tuple stored on the blackboard are extracted as nondeterministic portions. Then, a guard instruction is generated and added to the extracted process in accordance with the stored execution log so as to limit the processes that can read and write tuples on the blackboard. In the present invention, non-determinism can be restricted by adding the following tuple term. (T1, T2, ..., Guard) This is a generalization of the form of the tuple term to be added. T1 and T2 abstractly show the contents of information to be written on the blackboard as tuples. Indicates a description to restrict the process that can read the tuple.

For example, FIG. 10 shows each process P1 to P4
Is a conceptual diagram showing a state in which tuples A and B on a tuple space S are read and written. In this figure, information ('a', 2) is written as tuple A and information ('b', 1) is written as tuple B as specific contents of information T1 and T2 to be written in the tuple. As shown in this figure, in the program 1 given first, a tuple A (T1, T2) generated by the process P1 is replaced by processes P2, P3 and P4.
It can be read by any of. However, if the tuple A generated by the process P1 is always read by the process P2 in the stored test execution log, the tuple A to be written is changed by changing the write instruction of the tuple A in the process P1 to ( T1,
T2, 'P1-P2'). Further, the instruction to read tuple A in the process P2 is changed to (T1, T
2, 'P1-P2'). This makes it impossible for the processes P3 and P4 to read the tuple A, thereby suppressing nondeterminism (FIG. 11).

Further, as a similar example, for example, in the execution log of another test, if the tuple B generated in the process P3 is always read by the process P4, similarly, (T1, T2, 'P3-P4 ') Is converted to write a tuple B as shown in FIG. Further, the instruction to read tuple B in process P4 is changed to (T1, T2, 'P3-P
4 '). This makes it impossible for the processes P1 and P2 to read the tuple B, thereby suppressing nondeterminism (FIG. 11).

As described above, in the third embodiment, the description of tuple writing and reading is changed to a guard instruction so as to limit the process of reading tuples that cause nondeterminism. Nondeterminism of type-concurrent programs is suppressed, and correct behavior is realized.

[1-6. Fourth embodiment: When applied to a message exchange type concurrent programming language] A fourth embodiment corresponds to claim 7, and the present invention relates to a message exchange type concurrent programming language (Ada, C language + μIT
RON). In this message exchange type concurrent program, a plurality of processes cooperate by exchanging messages. In such a message exchange type program, the behavior of each process is affected by the messages exchanged between the processes. Therefore, the behavior of a process receiving a plurality of messages may differ depending on the order in which the messages arrive.

Here, the message exchange is performed by using a send statement and a wait statement.
Assume that this is done in sentences. If the original program grammar allows selective execution according to guard conditions, such as Ada, guard conditions are added in the same manner as in the previous embodiments to suppress nondeterminism. It is possible.

FIG. 12 shows an example of a program in the fourth embodiment. In this program, processes P1 and P2
Are the same mailbox MB without considering each other's context
To send messages X and Y to Therefore, the order in which the process P3 receives the messages via the mailbox MB is non-deterministic, and depends on which of the message X from the process P1 and the message Y from the process P2 is received first. Results in different processing. FIG. 13 shows that when the program of FIG. 12 is followed, the process P3 is executed by one mailbox MB.
FIG. 3 is a conceptual diagram showing that two messages X and Y are received. That is, in this case, since the process P3 only sequentially reads the contents of the mailbox MB, the order of messages to be received depends on which of the message X from the process P1 and the message Y from the process P2 arrives first. Both X and Y cases and Y and X cases may occur.

In the extraction of nondeterminism in this case, a process that may receive a plurality of messages in different orders is extracted as a nondeterministic part from the message exchange type parallel program of FIG. The non-deterministic detection corresponding to the fourth embodiment is described in detail in the above-mentioned Reference 1. Then, in this embodiment, a guard instruction for controlling to receive messages in the order according to the stored execution log is created and added to the extracted process.

In the above example, if the process P3 receives the message from the process P1 earlier than the message from the process P2 in the test execution log, the program to which the guard is added is as shown in FIG. become. In other words, the program after this change is modified such that the mailbox name is subdivided into MB1 and MB2 so that the first wait statement can always receive only the message from the process P1.

FIG. 15 conceptually shows how the process P3 receives two messages X and Y via the two mailboxes MB1 and MB2 in accordance with the program of FIG. 14 thus changed. That is, in this case, the process P3 includes the mailboxes MB1 and MB1.
2, the message X from the process P1 is always sent to the mailbox MB1, and the message Y from the process P2 is always sent to the mailbox MB2. Therefore, regardless of which one arrives first, the process P3 can receive the messages X and Y in a predetermined order.

As described above, in the fourth embodiment, a guard instruction for limiting the order in which messages arrive is created by subdividing the name of a mailbox that serves as a buffer for exchanging messages, for example. Thereby, nondeterminism of the message exchange type program is suppressed, and correct behavior is realized.

[1-7. Effects of First Embodiment] According to the above-described first embodiment, the following advantages can be obtained. For example, even if the program to be developed is large, it is not necessary to handle a large-scale state transition model or scenario in proportion thereto. In addition, since the entire program is not reconfigured, the processing is simplified, and it can be easily applied to a large-scale program. Further, since a guard instruction in which an instruction originally existing in the program is rewritten is used as means for realizing the correct behavior of the program, it is not always necessary to newly embed a synchronous instruction or an instruction relating to an interrupt in the program. For this reason, the program is not complicated, and the synchronous instruction and the instruction related to the interrupt used in the coding are not affected.

[2. Second Embodiment] In a second embodiment (hereinafter, referred to as a "second embodiment"), a user is inquired whether to change the program for each guard instruction to be added. FIG.
It is a functional block diagram showing the configuration of the second embodiment. Second
As shown in this figure, the embodiment has a confirmation unit 7 in addition to the configuration of the first embodiment shown in FIG. Confirmation part 7
Is a means for inquiring the user for each guard instruction whether or not to change the program by adding a guard instruction, and corresponds to "inquiring means" in claim 11. Correspondingly, the changing unit 3 in the second embodiment, in particular, the guard adding unit 53, changes the check unit 7 only when the user gives a response to the inquiry that the change may be made.
It is configured to add a guard instruction.

As a specific example of the inquiry, the guard instruction and the related information are displayed as text on the screen and "1:
An option such as “Addition 2: Ignore” is displayed, and each time the user answers with a number, the option is added or the process proceeds to the next. As another example, the original program is displayed on the screen, and a different color is displayed for each location where the guard instruction to be added is added. When the user clicks and selects a guard command that the user may add, the clicked guard command is highlighted. When the user operates a predetermined input key after all guard instructions to be added are highlighted by repeating clicking, the selected guard instruction is added to the program at a stretch.

As described above, in the second embodiment, before rewriting the original program, the user is inquired about whether or not rewriting is possible, so that rewriting that restricts the program more than necessary can be suppressed.

[3. Third Embodiment] A third embodiment (hereinafter, referred to as a "third embodiment") is an example provided with means for ensuring safety when executing the changed program 6.

In each of the above embodiments, a guard was prepared so as to completely suppress the behavior other than the behavior whose correctness was confirmed in the test, whereas in the present embodiment, the behavior was partially suppressed. It is made from the viewpoint that it may be a typical thing.

For example, first, the program is divided into a part that follows the execution order extracted from the correct execution log and a part whose execution order is free in the other parts. For each part that follows the execution order, a priority is set by a numerical value or the like so that the part that is executed first has a higher priority, and the other parts that have a free execution order have a lower priority. Set the degree. And when the program runs,
Each part is executed in descending order of priority by the action of a compiler or an interpreter. In this case, the behavior of the part with the priority set is prioritized, but if there is no such high-priority behavior in the part of the program that can be executed at a certain point in time, other behaviors are allowed. I do.
In this way, the necessary execution order is realized,
Nondeterminism (good nondeterminism) is left in other parts. Such good nondeterminism contributes to an improvement in the processing efficiency of the entire system, for example, in a process with a light load, the process is advanced.

In such a case, since the modified program 6 shown in FIG. 2 also shows behavior other than the test, it is particularly desirable to provide a means for ensuring security during execution. Even when such priorities are not used, the parts changed by the changing unit 5 have the original coding contents changed, so that it is desired to ensure the security as well.

[3-1. Configuration] FIG. 17 is a functional block diagram showing the configuration of the third embodiment. As shown in this figure, in the third embodiment, in addition to the configuration of the first embodiment shown in FIG. 2, an execution unit 8 that executes the changed program 6
And a safety unit 9 for ensuring safety in this execution. The execution unit 8 compiles the changed program 6, and executes each of the processors 101-1 and 101-1.
.., 101-N to execute the program 6 by executing the respective processes. Further, the security unit 9 is a means for ensuring the execution safety when executing a part of the program 6 changed by the changing unit 5 and a part not included in the execution log. This corresponds to “means for ensuring safety” described in No. 12. The safety section 9 is configured to output a warning 10 and store data 11 representing the execution state of the program at that time when executing each of the above parts.

[3-2. Detection Method] The third embodiment having the above configuration operates as follows. First,
The part that was not included in the execution log, that is, the behavior other than the behavior whose correctness was confirmed in the test (hereinafter referred to as “behavior outside the guaranteed range”),
It can be detected as follows. That is, when the low-priority part set as described above is executed, it may be regarded as the behavior outside the guaranteed range, or the behavior whose correctness is confirmed in the test and the part outside the guaranteed range may be identified by an address or the like. Classification may be made, and it may be determined whether the behavior is out of the guaranteed range depending on which classification is being executed. Further, in order to detect the changed portion, when changing the program, the portion may be marked with a software mark, and the appearance of the mark may be detected at the time of execution.

[3-3. Output of Warning] A possible countermeasure when these are detected is to output a warning 10 first (claim 13). As a specific example, a program for controlling a power plant is out of the guaranteed range. For example, a warning may be given to the operator to call attention. Further, the warning 10 may be selectively displayed from among several types prepared. For example, if a different warning is displayed for each changed part, the execution state of the program can be grasped concretely. Also, if the percentage of the CPU execution time that is out of the guaranteed range is displayed in real time on the screen using numbers or bar graphs, etc., under what conditions the program is executed, It can be easily determined whether or not the reliability of the behavior can be expected. As described above, if the warning 10 is output when executing the changed part or the part that has not been tested, the user can determine the reliability of the program,
It becomes easy to take various measures such as taking measures in preparation for a failure.

[3-4. Saving of Data] Further, as another countermeasure in the case where a changed portion or a portion that has not been tested is detected, saving data 11 representing the execution state at that time may be mentioned (claim 14). Here, it is desirable that the execution state to be saved is a state immediately before the behavior outside the guaranteed range is actually started. In this way, in the fault-tolerant system, if a trouble occurs outside the guaranteed range, the roll-back (return and return) can be performed to a state immediately before entering the out of the guaranteed range. Note that a fault-tolerant system is a system that can continue operation even if there is a failure, and rollback is to return the processing contents to the processing contents at a previous point in time. In this way, even if a failure occurs in those portions, the effect of the failure can be minimized by restoring the system by using the stored data for cause analysis and rollback.

[3-5. Detection of non-secure state) When a changed part or untested part is detected, as another countermeasure, the function of detecting the non-safe state may be used when executing the detected part. Conceivable. That is, if an unsafe state such as a deadlock (infinite loop) due to a guard is detected at the time of execution, a program that has fallen into such a state can be moved to a safe state.

In this case, the detection of the non-safety state is performed by monitoring the variable area and the gilesta used in the execution of the program. For example, if a numerical value indicating the execution position of a program such as a program counter repeats the same numerical value more than a certain value, it can be determined that deadlock has occurred. When such an unsafe state occurs, the execution state of the program is moved to a safe state by using an exception handling mechanism of the program. The safe state here can be freely defined by the user, for example, by saving data at the time when the non-safe state occurs, and transferring control of the CPU to an error processing routine or an operating system.

As described above, in the third embodiment, since the security is ensured when the changed program is executed, unexpected behavior may occur due to rewriting, or the behavior not assumed in the modification may be performed. Occurs, the inconvenience caused thereby is minimized, and the reliability of the program is improved.

[4. Fourth Embodiment] In a fourth embodiment (hereinafter referred to as a "fourth embodiment"), a generated guard instruction is not added to a program as it is, but a document "K. Ueda and M. Morita, Moded" Flat GHC and Its Me
ssage-Oriented Implementation Technique. New Gener
ation Computing, Vol.13, No.1, pp.3-43, November 1
994. "and the like, so that a more appropriate guard instruction is generated or the guard instruction is improved and added to the program (claim 8).

FIG. 18 is a functional block diagram showing the configuration of the fourth embodiment. In the fourth embodiment, as shown in this figure, in addition to the configuration of the first embodiment shown in FIG. 2, the changing unit 5 is provided with an analyzing unit 54 and a guard improving unit 55. The analysis unit 54 is a unit that analyzes the given program 1, the execution log, and the generated guard instruction, and corresponds to “analysis unit” according to claim 8. Further, the guard improving unit 55 is a means for improving the guard instruction generated by the guard generating unit 52 by using the result of the analysis by the analyzing unit 54, and corresponds to “improving means”.

Typical modes for improving the guard instruction are removal of redundant guard instructions and abstraction (simplification) of guard instructions.
It is. Removal of redundant guard instructions (claim 9) is to select only essential guards from guard instructions to be added to a program by removing extra guards based on the result of the analysis. It is. For example, of the two guard instructions to be added to a certain part of the program, if the condition required by one guard instruction is satisfied, the condition required by the other guard instruction is always satisfied, only one guard instruction is added.

By removing redundant guard instructions based on the result of analysis in this way, only truly necessary guard instructions are selected and added, so that the processing of changes and the contents of the final program are made more efficient. Is done.

Further, the guard instruction is abstracted.
Is to abstract a guard instruction to be added to a program based on the result of analysis, and is typically performed by inductively creating a superordinate concept that includes several types of guard instructions. Further, as one aspect of the abstraction, it is conceivable to extend the condition by adding a new condition with a logical function OR to the condition described in the guard instruction.

The object to be analyzed is at least one of the program 1, the execution log, and the guard instruction, and the analysis can be freely performed by combining two or more. For example,
As an example of abstracting a guard instruction using the result of analyzing a program, when the processing result is always the same even if one module is replaced with another module not in the execution log in the execution order realized by the guard instruction It is conceivable to extend the guard instruction to cover such another module.

The following can be considered as an example of abstracting a guard instruction by analyzing an execution log. For example, it is conceivable to add a guard instruction that waits for the execution of each preceding module under an OR condition based on a test result that certain processing is executed after any of several preceding modules. In this case, as a result of analyzing the execution log, even after executing any module,
Suppose that it has been found that the behavior is correct because a specific state is established. In this case, if only a guard instruction that waits for such a state is added, correct behavior can be obtained without referring to each preceding module.

As an example of analyzing and abstracting a guard instruction itself, a guard instruction satisfied by an “even number” and a guard instruction satisfied by an “odd number” are to be added to the same location. When it is sufficient that the guard instruction is satisfied, both can be abstracted and a guard instruction based on a superordinate concept of “integer” can be used. The abstraction method, such as what kind of guard instruction can be used when what kind of guard instruction is prepared, may be stored in the comparison table in advance. As described above, by abstracting the guard instruction added to the program, the functions to be realized are enhanced with respect to the number of guard instructions to be used and the data capacity.

As described above, in the fourth embodiment, the generated guard instruction is not added to the program as it is, but the guard instruction is improved based on the analysis result.
The reliability of the final program is improved. Such a fourth embodiment is particularly suitable for a parallel logic type program.

[5. Other Embodiments] The present invention
The present invention is not limited to the above embodiment, but includes other embodiments as exemplified below. For example, it is conceivable to add a guard instruction by rewriting an existing statement (description) in a program, but it is also possible to add a new statement by inserting a new statement.

Further, in each example of the first embodiment, a program in a pattern matching type parallel programming language has been exemplified, but the application of the present invention is not limited to these. That is, the present invention can be applied not only to nondeterminism in a concurrent program but also to nondeterminism due to an external input and nondeterminism due to a processing system problem that can occur in a sequential program.

When applied to such a sequential program, for example, by analyzing a correct execution log,
The order relationship between a specific input from the outside and a certain part of the program may be extracted, and a guard instruction may be added so as to wait for such a specific input and execute the part. In addition, the state of the processing system is recorded in an execution log, and if it is analyzed that a certain part of the program can be executed safely when the processing system is in a certain state, it is necessary to wait for the establishment of such a state. What is necessary is just to comprise so that a guard instruction may be added.

[0109]

As described above, according to the present invention,
Since a highly reliable program can be efficiently developed even for a large-scale program, productivity in program development is improved.

[Brief description of the drawings]

FIG. 1 is an exemplary view showing a hardware configuration of a computer system used in a first embodiment of the present invention.

FIG. 2 is a functional block diagram showing the configuration of the first embodiment of the present invention.

FIG. 3 is a flowchart showing a processing procedure according to the first embodiment of the present invention.

FIG. 4 is a diagram showing an example (source code) of a program in a parallel logic language according to the first embodiment of the present invention;

FIG. 5 is a conceptual diagram showing a process when the program of FIG. 4 is executed.

FIG. 6 is a diagram showing an execution sequence when the program in FIG. 4 is executed.

FIG. 7 is an example of a program obtained by changing the program of FIG. 4;
The figure which shows (the source code part after conversion).

FIG. 8 is a diagram showing an example (source code) of a program in a rule type language in the first embodiment of the present invention.

FIG. 9 shows an example of a program obtained by modifying the program of FIG. 8;
The figure which shows (the source code after conversion).

FIG. 10 is a conceptual diagram showing a state in which a process reads and writes a tuple by the action of a blackboard type concurrent program in the first embodiment of the present invention.

FIG. 11 is a conceptual diagram showing a state in which a process reads and writes a tuple by the operation of a changed blackboard type concurrent program in the first embodiment of the present invention.

FIG. 12 is a diagram showing an example of a program in a message exchange type concurrent programming language in the first embodiment of the present invention.

FIG. 13 is a conceptual diagram showing a state where messages are exchanged between processes using a single mailbox by the program of FIG. 12;

FIG. 14 is a diagram showing an example of a program obtained by modifying the program of FIG. 12 by adding a guard instruction.

FIG. 15 is a conceptual diagram showing a state in which messages are exchanged between processes using two mailboxes by the program of FIG. 14;

FIG. 16 is a functional block diagram showing a configuration of a second embodiment of the present invention.

FIG. 17 is a functional block diagram showing a configuration of a third embodiment of the present invention.

FIG. 18 is a functional block diagram showing a configuration of a fourth embodiment of the present invention.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 101 ... Processor 102 ... I / O interface 103 ... Shared memory 104 ... Input device 105 ... Output device 106 ... External storage device 1 ... Provided program 2 ... Test part 3 ... Test information 4 ... Storage part 5 ... Change part 51 ... Nondeterministic extraction unit 52 Guard generation unit 53 Guard addition unit 54 Analysis unit 55 Guard improvement unit 6 Changed program 7 Confirmation unit 8 Execution unit 9 Safety unit 10 Warning 11 Data p ~ , P ~ ... Process A, B ... Tuple S ... Tuple space MB ... Mail box

Claims (20)

[Claims] 1. A program development support device for supporting development of a program, comprising: means for testing a given program; and means for changing the program so as to exhibit correct behavior using information obtained in the test. A program development support device, comprising: 2. A program development support device for supporting program development, comprising: means for testing by executing a given program; means for storing an execution log when the behavior of the program is recognized to be correct; Means for changing a program by adding a guard instruction that suppresses a behavior not recorded in the stored execution log. 3. The means for changing includes: means for extracting a nondeterministic part whose behavior is not uniquely determined from a given program; and generating the guard instruction for the extracted nondeterministic part. 3. The program development support apparatus according to claim 2, further comprising: means for adding a generated guard instruction to the nondeterministic portion. 4. A program to be developed is a parallel logic type program including a plurality of clauses, and the means for changing includes a part having a non-deterministic property from a parallel logic type program to a plurality of clauses which can be executed simultaneously. And generating a guard instruction that suppresses a variable of a predicate included in the extracted clause so as to match only the execution sequence recorded in the execution log. The program development support device according to claim 2, wherein the program development support device is configured to be added to the program development support device. 5. A program to be developed is a rule-type program in which rules having a condition part and an execution part are combined. A rule is extracted as a non-deterministic part, and a guard instruction that suppresses a pattern match of a condition part of the extracted rule so as to conform only to a rule of an execution sequence recorded in the execution log is provided. 4. The program development support device according to claim 2, wherein the guard instruction is generated and added to the non-deterministic part. 6. A program to be developed is a blackboard-type parallel program in which a plurality of processes cooperate by reading and writing tuples, which are sets of data stored on a blackboard, wherein the changing means Extracts, from a blackboard-type parallel program, a plurality of processes that can be pattern-matched with the same tuple stored on the blackboard as non-deterministic parts, and for the extracted processes, 4. The program development support according to claim 2, wherein a guard instruction for limiting a process of reading and writing tuples on a blackboard is generated, and the guard instruction is added to the nondeterministic portion. apparatus. 7. A program to be developed is a message exchange type concurrent program in which a plurality of processes cooperate by exchanging messages, and the changing means comprises a plurality of message exchange type concurrent programs. Processes that may receive messages in a different order are extracted as nondeterministic parts, and a guard instruction is generated for the extracted processes to control the messages to be received in the order according to the stored execution log. 4. The program development support apparatus according to claim 2, wherein said guard instruction is added to said non-deterministic part. 8. The apparatus according to claim 2, further comprising: means for analyzing at least one of a program, an execution log, and a guard instruction; and means for improving the guard instruction using a result of the analysis. 8. The program development support device according to any one of 7. 9. The method according to claim 1, wherein said improvement means is configured to select only an essential guard instruction from guard instructions to be added to the program based on a result of the analysis. 8. The program development support device according to 8. 10. The method according to claim 1, wherein the improving unit is configured to abstract a guard instruction to be added to the program so as to suppress more general behavior based on a result of the analysis. Item 9. The program development support device according to Item 8. 11. When a program is to be changed by adding a guard instruction, means for inquiring for each guard instruction whether or not to change the program is provided. The program development support device according to any one of claims 2 to 10, wherein the program is modified by adding a guard instruction to which a response to the effect is given. 12. When executing at least one of a portion of the program changed by the changing means and a portion not included in the execution log,
The program development support apparatus according to claim 2, further comprising a unit for securing execution safety. 13. The method according to claim 13, wherein the security unit issues a warning when executing at least one of a part of the program changed by the changing unit and a part not included in the execution log. 13. The program development support device according to claim 12, wherein the output is output so as to ensure execution safety. 14. The method according to claim 1, wherein the means for ensuring security executes at least one of a part of the program changed by the changing means and a part not included in the execution log. 13. The program development support device according to claim 12, wherein data representing an execution state of the program in the program is stored. 15. A program development support method for supporting program development, wherein a step of testing by executing a given program, a step of storing an execution log when the behavior of the program is recognized to be correct, Changing the program by adding a guard instruction that suppresses a behavior that is not recorded in the stored execution log. 16. The changing step includes: extracting a non-deterministic part whose behavior is not uniquely determined from a given program; and generating the guard instruction for the extracted non-deterministic part. The method according to claim 15, further comprising: adding a generated guard instruction to the nondeterministic portion. 17. The method according to claim 15, further comprising: analyzing at least one of a program, an execution log, and a guard instruction; and improving the guard instruction using a result of the analysis. The described program development support method. 18. When executing at least one of a part of the program changed by the changing step and a part not included in the execution log,
18. The program development supporting method according to claim 15, further comprising a step of ensuring execution safety. 19. A recording medium on which a program development support software for supporting a program development by controlling a computer is provided. The program development support software executes a test by executing a given program on a computer. And storing the execution log when the behavior of the program is found to be correct, and modifying the program by adding a guard instruction that suppresses the behavior not recorded in the stored execution log. A recording medium that stores software for supporting program development. 20. A recording medium on which the program development support software according to claim 19 is recorded, wherein the program development support software has a behavior unique to a computer from a given program when the program is changed. Extracting a part having nondeterminism that is not determined by the above, generating the guard instruction for the extracted part having nondeterminism, and adding the generated guard instruction to the part having nondeterminism. A recording medium that records support software.