WO2015087409A1 - Source code generation device, source code verification device, source code generation method, and source code generation program - Google Patents

Abstract

The present invention verifies that a source code that is generated from a software specification written in a formal language is the result of refining the software and that said source code is a source code for implementing the software. A source code generation device is provided with: a scheduler editing means that edits a scheduler that defines a control structure including at least an "if" conditional branching structure and a "do" loop structure; a source code generation means that generates source code including at least an "if" conditional branching structure or a "do" loop structure from a software specification and the edited scheduler; a scheduled model generation means that generates a scheduled model including a control structure that is written in a formal language from the software specification and the edited scheduler; and a flattened code generation means that generates a flattened code that is written in a programming language, that does not include an "if" conditional branching structure or a "do" loop structure, and that does contain a "goto" statement from the software specification and the edited scheduler.

Description

Source code generation device, source code verification device, source code generation method, and source code generation program

The present invention relates to technology for supporting software development, and more particularly to technology for generating source code from software specifications.

To verify the correctness of the software specification using the formal method, the specification of the software is described in a formal language having a mathematical meaning, and the correctness of the software specification described in the formal language (hereinafter referred to as a formal model) is confirmed. This is done by proof based on mathematical methods. Patent Document 1 further discloses a method for generating a source code from the proven formal model. By generating source code from a certified formal model, it is possible to avoid troubles in manual source code development and reduce the effort of source code development. As a result, effects such as a reduction in software development man-hours and a reduction in software defects can be obtained.

For example, Event-B, which is a type of formal method, is intended to prove the specifications of upstream development processes with many uncertainties, so the formal model is described in a formal language with a high degree of abstraction that does not specify the control structure of the process (event) To do. On the other hand, in a general source code description language (programming language) such as C language, a process control structure is described in detail. Therefore, in order to generate source code from a formal model that does not include the control structure as in the Event-B formal model, it is necessary to define the control structure.

Non-Patent Document 1 discloses a method that enables source code generation from a formal model described in the Event-B language by extending the Event-B language so that the control structure can be defined. . This method makes it possible to generate source code from a formal model that does not include the control structure. As a result, even when the software specification is proved by a formal model that does not include the control structure, an effect of reducing the software development man-hour by generating source code can be obtained.

Japanese Patent No. 2946715

The above-mentioned conventional technology makes it possible to define a control structure for a formal model and to generate source code from the formal model including the control structure. The generation of the source code is realized by a tool. At this time, if there is an error in the implementation of the tool, there is a possibility that the error is also mixed in the generated source code. “Error” here means that the generated source code is not the result of refining the software specification represented by the format model of the generation source, and does not realize the software specification.

That is, in the conventional technology, there is a possibility that an erroneous source code is generated due to a failure of the tool. When a formal model is described in a formal language having a high level of abstraction that does not include the control structure as in Event-B, there is a difference that the formal model and the source code include / do not include the control structure. In the formal language, the process is described in an event format, but in the source code description language, the process is described in a procedural format. For the above reason, it is difficult to compare the formal model with the generated source code, and there is a problem that the error cannot be detected.

Although the test is effective for detecting the source code having the error, the test cannot always detect the error, and is not sufficient as a means for solving the problem.

As described above, when a formal model is described in a formal language with a high level of abstraction that does not specify a control structure such as Event-B, and source code is generated from the formal model, errors in the source code can be detected. Is a problem.

In view of the above, it is an object of the present invention to provide a technique for reducing software defects by addressing the above problems and making it possible to detect errors in the source code generated from the formal model.

In order to solve the above-described problems and achieve the object, a source code generation device according to the present invention is a source code generation device that generates a source code described in a programming language from a software specification described in a formal language. The processing of the software specification that does not include a control structure, scheduler editing means for editing a scheduler that defines a control structure including at least an if conditional branch structure and a do loop structure, and the software specification and the edited scheduler, Source code generation means for generating source code including at least an if conditional branch structure or do loop structure, and a scheduled model for generating a scheduled model including a control structure described in the formal language from the software specification and the edited scheduler Generating means; and And a flattened code generation means for generating a flattened code including a goto statement without including an if conditional branch structure and a do loop structure, from a software specification and an edited scheduler. Configured as a source code generator.

The present invention can also be understood as a source code generation method and a source code generation program performed by the source code generation device. In addition, the present invention is configured as a source code certifying device that proves refinement and equivalence using data received from the source code generating device.

According to the present invention, it is possible to provide a technique for reducing software defects by making it possible to detect an error in a source code generated from a formal model.

It is a block diagram which shows the structural example of a source code production | generation apparatus. It is a block diagram which shows the hardware structural example of a source code generation apparatus. It is a block diagram which shows the structural example of a source code certification | authentication apparatus. This is an example of a developed model (machine). This is an example of a developed model (machine). This is an example of a developed model (context). It is an example of a Restricted model (machine). It is an example of a Restricted model (machine). It is an example of a Restricted model (context). It is an example of a scheduler. It is an example of a Scheduled model. It is an example of a Scheduled model. It is an example of a Scheduled model. This is an example of Flattened code. It is an example of Target code. It is a flowchart which shows the example of a procedure of a model conversion part. It is a flowchart (Scheduled model generation procedure) which shows the example of a procedure of an intermediate product production | generation part. It is a flowchart (Scheduled model generation procedure) which shows the example of a procedure of an intermediate product production | generation part. It is a flowchart (Scheduled model generation procedure) which shows the example of a procedure of an intermediate product production | generation part. It is a flowchart (Flattened code generation procedure) which shows the example of a procedure of an intermediate product production | generation part. It is a flowchart (Flattened code generation procedure) which shows the example of a procedure of an intermediate product production | generation part. It is a flowchart (Flattened code generation procedure) which shows the example of a procedure of an intermediate product production | generation part. It is an example of a conversion rule from Event-B language to C language. It is a flowchart which shows the example of a procedure of a code production | generation part. It is a flowchart which shows the example of a procedure of a code production | generation part. It is a flowchart which shows the example of a procedure of a model detailed certification | authentication part. It is a flowchart which shows the example of a procedure of an intermediate equivalence equivalence part. It is a flowchart which shows the example of a procedure of an intermediate equivalence equivalence part. It is a flowchart which shows the example of a procedure of a code equivalence | correspondence proving part. It is a flowchart which shows the example of a procedure of a goto conversion process. It is a flowchart which shows the example of a procedure of a goto conversion process.

Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

This embodiment is applied to a source code generation device. In the present embodiment, when generating a Target code that is a source code to be generated from a Restricted model that is formally proof of the correctness of software specifications, a Scheduled model that is a formal model including a control structure is generated. Generate Flattened code which is source code using goto statement instead of if branch and do loop. The Scheduled model and the Flattened code play a role of bridging the difference regarding the presence / absence of the control structure between the Restricted model and the Target code and the difference in language. In other words, the Target code is proved by proving the refinement relationship between the Restricted model and the Scheduled model, proving the equivalence between the Scheduled model and the Flattened code, and proving the equivalence between the Flattened code and the Target code. However, it becomes possible to prove that it is a result of refining the specification represented by the Restricted model.

Therefore, according to the present embodiment, since it is possible to detect that the Target code that is the generated source code has an error, it is possible to reduce defects in software that uses the Target code.

In this embodiment, in order to generate the Target code, the Scheduled model, and the Flattened code from the Restricted model, an input of a scheduler representing the control structure of the Restricted model process is received. The scheduler can describe an if conditional branch structure, a do loop structure, and a sequential connection using events included in the Restricted model. Further, the scheduler can describe a pre-state and a post-state that are conditions to be satisfied before and after execution of the event, the if conditional branch structure, and the do loop structure.

In addition, in the present embodiment, it is possible to confirm that the control structure indicated by the scheduler is executable by confirming that there is no contradiction regarding the precondition and the postcondition in the scheduler. When a control structure that cannot be executed by the scheduler is designed, the Scheduled model is not the result of refining the Restricted model. That is, the scheduler design error can be confirmed before generating the Scheduled model, the Flattened code, and the Target code. Therefore, according to the present embodiment, it is possible to reduce the number of reworking steps when there is a design error in the scheduler.

Further, in this embodiment, there is a restriction that variables and constants included in the Restricted model have an upper limit value and a lower limit value. Similarly, when the Restricted model includes an arithmetic expression, the arithmetic expression has a restriction that a value exceeding the upper limit value and the lower limit value is not assigned to the variable. Furthermore, in the present embodiment, the Restricted model is generated from a developed model that does not have the above-described restrictions. It can be proved that the Restricted model is a result of refinement of the developed model. Therefore, according to the present embodiment, it is possible to reduce the number of steps for creating the Restricted model from the Develop model in order to obtain the Target code.

FIG. 1 is a block diagram illustrating a configuration example of the source code generation device 201 in the present embodiment for Event-B.

The source code generation device 201 includes a model editing unit 101, a developed model holding unit 102, a model conversion unit 103, a restricted model holding unit 104, a code generation unit 105, a scheduled model holding unit 106, a flattened code holding unit 107, and a target code holding unit. 108, model refinement proving unit 109, refined proving result holding unit 110, scheduler holding unit 111, scheduler editing unit 112, scheduler checking unit 113, intermediate equivalence equivalence proving unit 114, intermediate product proving result holding unit 115, code equivalence It includes a sex proof unit 116, a code proof result holding unit 117, and an intermediate product generation unit 118.

The model editing unit 101 accepts creation / editing of a developed model described in the Event-B language, and registers it in the developed model holding unit 102. The Developed model is a formal model that includes variables and constants that do not have an upper limit or lower limit.

The model conversion unit 103 acquires the developed model from the developed model holding unit 102 and converts it to the restricted model described in the Event-B language. An example of the conversion procedure is shown in FIG. Variables and constants included in the Restricted model have upper and lower limits. In addition, when the Restricted model includes an arithmetic expression, the upper limit value and the lower limit value of the constant are prevented so that a value exceeding the upper limit value and the lower limit value is not assigned to the variable by the arithmetic expression. Is set. The created Restricted model is registered in the Restricted model holding unit 104.

The code generation unit 105 acquires the Restricted model from the Restricted model holding unit 104, generates a Target code described in a programming language such as C language from the acquired Restricted model, and registers the Target code in the Target code holding unit 108. The Target code is a source code including an if conditional branch structure and a do loop structure. An example of the code generation procedure is shown in FIGS.

The scheduler editing unit 112 receives the creation / editing of the scheduler and registers it in the scheduler holding unit 111. The scheduler can describe an if conditional branch structure, a do loop structure, and a sequential connection by using events (EVENTS) included in the Restricted model. Further, the scheduler can describe a pre-state and a post-state that are conditions to be satisfied before and after execution of the event, the if conditional branch structure, and the do loop structure.

The scheduler checking unit 113 acquires the scheduler from the scheduler holding unit 111, and checks whether there is no contradiction regarding the pre-condition and the post-condition in the scheduler. For example, it is assumed that there is an event evt that is executed when a condition is satisfied in an if conditional branch structure bran having a certain condition cond. In this case, it is necessary to be able to derive the precondition of the event evt from the precondition of the if conditional branch structure bran and the condition cond. At the same time, the post condition of the if conditional branch structure bran must be derived from the post condition of the event evt. In addition, when the sequential combination of the event evt1 and the event evt2 is executed instead of the event evt, the precondition of the event evt2 must be derived from the post condition of the event evt1. When these derivations are impossible, the control structure indicated by the scheduler is an erroneous control structure that cannot be executed.

FIG. 8 shows an example of the scheduler, and a line 803 surrounded by [] represents a post-condition of the above do loop structure. A line 804 surrounded by {} represents a precondition of the event final below. The intermediate product generation unit 118 obtains a Restricted model from the Restricted model holding unit 104 and is described in the Event-B language. A Flattened code written in a programming language such as the Scheduled model and C language is generated. The generated Scheduled model and Flattened code are registered in the Scheduled model holding unit 106 and the Flattened code holding unit 107, respectively. The Scheduled model is a model reflecting the control structure defined by the scheduler in the Restricted model. Unlike the Target code, the Flattened code does not include an if conditional branch structure and do loop structure. Instead, the Flattened code includes a goto statement. Examples of the procedure for generating the Scheduled model and the Flattened code are shown in FIGS. 13A to 13C and FIGS. 14A to 14C, respectively.

In this embodiment, the C language is used as an example of the description language of the Target code, but Target codes described in other programming languages can also be generated. For this purpose, the flattened code must be described in another programming language similar to the Target code, and the code equivalence proving unit 116 must correspond to the other programming language. Alternatively, there is a method in which the flattened code is described as an abstract pseudo code (Pseudo code), and a code equivalence proving unit 116 is prepared for each description language of the Target code.

The model refinement proving unit 109 acquires the Restricted model and the Scheduled model from the Restricted model holding unit 104 and the Scheduled model holding unit 106, respectively, and proves that the Scheduled model is a result of refining the Restricted model. . The certification result is registered in the detailed certification result holding unit 110. An example of the proof procedure is shown in FIG. The proof result held by the detailed proof result holding unit 110 is composed of the developed model and the restricted model and a message “success of proof” or “failure of proof”.

Similarly, the model refinement proving unit 109 acquires the developed model from the developed model holding unit 102 and proves that the restricted model is a result of refinement of the developed model. The certification result is registered in the detailed certification result holding unit 110. The above proof can be implemented by the same procedure as shown in FIG. The proof result held by the detailed proof result holding unit 110 is composed of the Restricted model and the Scheduled model and a message “Certification success” or “Certification failure”.

The intermediate equivalence equivalence proving unit 114 acquires the scheduled model and the flattened code from the scheduled model holding unit 106 and the flattened code holding unit 107, respectively, and proves that the scheduled model and the flattened code are equivalent. The certification result is registered in the intermediate certification result holding unit 115. An example of the proof procedure is shown in FIGS. 18A and 18B. The proof result held by the intermediate proof result holding unit 115 is composed of the Scheduled model, the Flattened code, and a message of “proof successful” or “proof failed”.

The code equivalence proving unit 116 acquires the flattened code and the target code from the flattened code holding unit 107 and the target code holding unit 108, respectively, and proves that the flattened code and the target code are equivalent. The proof result is registered in the code proof result holding unit 117. An example of the proof procedure is shown in FIGS. 19 and 20A and 20B. The certification result held by the code certification result holding unit 117 is composed of the Flattened code and the Target code, and a message “Certification success” or “Certification failure”.

FIG. 2 is a diagram illustrating a hardware configuration example of the source code generation device according to the present embodiment.

The source code generation device 201 includes a CPU 202, a memory 203, an external storage device 204, a display device 205, an input device 206, and an external medium input / output device 207.

The CPU 202 executes various processes by executing programs stored in the memory 203. The memory 203 functions as a work area for the CPU 202 and stores programs and data necessary for executing the programs. Specifically, the model editing unit 101, the model conversion unit 103, the code generation unit 105, the model detailing certification unit 109, the scheduler editing unit 112, the scheduler checking unit 113, the intermediate equivalence equivalence unit 114, the code equivalence certification unit 116 and a program constituting the intermediate generation unit 118 are stored, and at the same time, the developed model holding unit 102, the restricted model holding unit 104, the scheduled model holding unit 106, the flattened code holding unit 107, the target code holding unit 108, and the detailed certification Data held by the result holding unit 110, the scheduler holding unit 111, the intermediate certification result holding unit 115, and the code certification result holding unit 117 is stored.

The external storage device 204 stores various data. The external storage device 204 is, for example, a hard disk device. Specifically, the developed model holding unit 102, the restricted model holding unit 104, the scheduled model holding unit 106, the flattened code holding unit 107, the target code holding unit 108, the refined proof result holding unit 110, the scheduler holding unit 111, an intermediate product A certification result holding unit 115 and a code certification result holding unit 117 are stored.

Alternatively, the model editing unit 101, the model conversion unit 103, the code generation unit 105, the model detailing verification unit 109, the scheduler editing unit 112, the scheduler checking unit 113, the intermediate equivalence verification unit 114, the code equivalence verification unit 116, and At least a part of the program constituting the intermediate generation unit 118 may also be stored in the external storage device 204, and the CPU 202 may read the program into the memory 203 and execute the program when executing various processes. Each program may be stored in the memory 203 or the external storage device 204 in advance, or may be introduced from another device into the memory 203 or the external storage device 204 via an available medium as necessary. Also good. The medium refers to, for example, a storage medium that can be attached to and detached from the external medium input / output device 207, or a communication medium such as a network, a carrier wave that propagates through the network, and a digital signal.

Display device 205 displays the processing result of the program. The display device 205 is, for example, a display. The input device 206 receives a process execution instruction and input of information necessary for the process from the user. The input device 206 is, for example, a keyboard and a mouse.

The external medium input / output device 207 inputs / outputs data stored in the external storage device 204 with the external medium. The external medium is a portable storage medium that can be attached to and detached from the external medium input / output device 207, and the external medium output device 207 is a drive device that can read from and write to the external medium.

The communication device 212 transmits and receives data stored in the external storage device 204 with the external medium. For example, a local area network or the Internet.

The source code generation device 201 is connected to the source code certification device 210 through the network 209. The source code verification device 210 has the same hardware configuration as the source code generation device 201.

The source code generation device 201 is used by the developer 208, and the created developed model, restricted model, scheduled model, flattened code, and target code are transmitted to the source code certification device 210 through the communication device 212 and the network 209. The The verifier 211 receives the developed model, restricted model, scheduled model, flattened code, and target code using the source code verification device 210. Then, each proof is performed using the model refinement proving unit 109, the intermediate equivalence proving unit 114, and the code equivalency proving unit 116, which are also included in the source code generating device 201.

In this embodiment, a network is adopted as a means for passing the developed model, restricted model, scheduled model, flattened code, and target code. However, even if the external medium input / output device 207 is used to perform the transfer by an external medium. good.

FIG. 3 is a block diagram illustrating a configuration example of the source code certification device 210.

The source code certification device 210 includes a developed model holding unit 102, a restricted model holding unit 104, a scheduled model holding unit 106, a flattened code holding unit 107, a target code holding unit 108, a model refined certification unit 109, and a refined certification result holding unit. 110, an intermediate equivalence proof unit 114, an intermediate proof result holding unit 115, a code equivalence proof unit 116, a code proof result holding unit 117, and an input receiving unit 301.

The input receiving unit 301 receives input of the developed model, restricted model, scheduled model, flattened code, and target code, and the developed model holding unit 102, restricted model holding unit 104, scheduled model holding unit 106, flattened code holding unit 107, respectively. Register in the target code holding unit 108. The detailed relationship and equivalence of the registered model and code is proved by a method similar to that of the source code generation device 201.

4A, 4B, and 5 are examples of machines and contexts constituting the developed model held by the developed model holding unit 102. FIG. 6A, 6B, and 7 are examples of machines and contexts that constitute a restricted model held by the restricted model holding unit 104. FIG.

FIG. 8 shows an example of a scheduler held by the scheduler holding unit 111. 9A to 9C are examples of the scheduled model held by the scheduled model holding unit 106. FIG. The Scheduled model includes the counter variable pc, and the control structure of the process (event) is defined using the counter variable. For example, the control structure of a process (event) is defined by using it as a guard like a guard 913.
FIG. 10 shows an example of a flattened code held by the flattened code holding unit 107. FIG. 11 shows an example of the Target code held by the Target code holding unit 108. FIG. 12 is a flowchart illustrating a procedure example of the model conversion unit. The processing shown below is realized by a program executed by the memory 203 by the CPU 202 included in the source code generation device 201. And this program is comprised from the code | cord | chord for performing the various operation | movement demonstrated below.

The CPU 202 executes the model conversion unit 103 to create a new machine by further refining (REFINES) the detailed machine most refined by refinement in the developed model acquired from the developed model holding unit 102. To do. At the same time, a new context is created by extending (EXTENDS) the context referenced by the detailed machine. The new machine references (SEES) the new context (step 1201). In the example of FIGS. 6A and 6B, the new machine m_res refines (REFINES) the detail machine m2 of the developed model, and further references (SEES) the new context c0_res. Also, as shown in FIG. 7, the new context c0_res extends (EXTENDS) the context c0 referred to by the detailed machine m2.

Event-B employs a formal model design method called refinement (for example, Non-Patent Document 2 (by Jean-Raymond Abrial, “Modeling in Event-B”, Cambridge University Press, 2010)). pp. 21 etc.) Refinement is a design method in which a part of the target software specification is abstractly modeled and then the specification is added and refined step by step. The correctness of the refinement is proved by proving a logical expression called a proof duty regarding the refinement.

In the new context, the model conversion unit 103 defines an upper limit value and a lower limit value for defining a range of variables, constants, and carrier sets included in the new machine and the new context (step 1202). In the example of FIG. 7, the upper limit value MAX_INT and the lower limit value MIN_INT are defined by the constant declaration 701 and the axiom 703.

The model conversion unit 103 defines arithmetic functions for the four arithmetic operations in the new context (step 1203). In the example of FIG. 7, the arithmetic functions c_plus, c_minus, c_mul, and c_div are defined in the constant declaration 702 and the axiom 704.

The model conversion unit 103 uses the upper limit value and the lower limit value defined in step 1202 to limit the constants included in the new context and the range of the carrier set (step 1204). In the example of FIG. 7, the range of constants is limited by the axiom 705.

The model conversion unit 103 limits the range of variables included in the new machine using the upper limit value and the lower limit value defined in step 1202 (step 1205). In the example of FIGS. 6A and 6B, the invariant 601 limits the value range of the variable. However, since the restriction of the invariant 601 can be derived from the axiom 705, it is defined as a theorem (THEOREMS).

The model conversion unit 103 replaces the arithmetic expression included in the event of the new machine with an arithmetic expression using the arithmetic function created in Step 1203 (Step 1206). In the example of FIGS. 4A and 4B and FIGS. 6A and 6B, the action 401 of the event inc is replaced with an action 602. Similar replacements are made for other events.

The model conversion unit 103 limits the constant range so that the value calculated in the middle of the arithmetic expression replaced in step 1206 does not exceed the upper limit value and the lower limit value defined in step 1202. (Step 1207). In the example of FIG. 7, in the action act2 included in the action 602, the value of r + 1 + q is calculated halfway. The value of the constant n is limited by the axiom 706 so that this value does not exceed MAX_INT above.

13A to 13C are flowcharts showing an example of a procedure for generating a Scheduled model among the procedures of the intermediate product generation unit.

The processing shown below is realized by a program executed by the memory 202 by the CPU 202 included in the source code generation device 201. And this program is comprised from the code | cord | chord for performing the various operation | movement demonstrated below.

The CPU 202 executes the intermediate product generation unit 118 to acquire the first line among the unprocessed lines of the scheduler (step 1301). The intermediate product generation unit 118 executes the following procedure depending on the type of acquisition line acquired in step 1301. If the acquisition line is an event, step 1303 is executed. If the acquired line is an if branch condition, step 1309 is executed. If the acquired line is a do loop condition, step 1314 is executed. In other cases, Step 1308 is executed (Step 1302).

The intermediate product generation unit 118 determines whether or not the acquired event is INITIALIZATION. If the event is INITIALIZATION, step 1305 is executed. If the event is not INITIALIZATION, step 1304 is executed (step 1303).

The intermediate generation unit 118 deletes all the guards for the event included in the Restricted model (step 1304). Taking the event inc in FIGS. 6A and 6B as an example, the guard 603 is deleted as shown in FIGS. 9A to 9C.

The intermediate product generation unit 118 confirms that a counter variable for controlling the execution order of events is added to the Restricted model. If not added, add the above counter variable. Thereafter, an action “initialize the counter variable to 1” is added to the action of the INITIALIZATION event (step 1305). In the example of FIGS. 9A to 9C, an action 903 is added.

The intermediate product generation unit 118 confirms that a counter variable for controlling the execution order of events is added to the Restricted model. If not added, add the above counter variable. Thereafter, a guard meaning that “the counter variable is equal to the scheduler line number of the event” is added to the event (step 1306). The scheduler line number means the line number of the acquired line acquired in step 1301. 9A to 9C, a guard 901 is added as the guard.

The intermediate generation unit 118 adds an action “increment the counter variable” to the event (step 1307). In the example of FIGS. 9A to 9C, an action 902 is added. If there is an unprocessed line in the scheduler, the intermediate generation unit 118 returns to Step 1301. If all rows have been processed, execution is terminated (step 1308).

The intermediate product generation unit 118 creates a true event that is a branch event when the acquired if branch condition is true and a false event that is a branch event when the acquired if branch condition is false. The affirmation of the if branch condition is set for the guard of the true event. In the false event guard, negation of the if branch condition is set (step 1309). Taking the if branch condition 801 of FIG. 8 as an example, as shown in FIGS. 9A to 9C, an event if1_true is created as a true event, and an event if1_false is created as a false event. In each event, a guard 904 and a guard 905 are added.

The intermediate product generation unit 118 adds a guard that “the counter variable is equal to the scheduler line number of the if branch condition” to each of the true / false events (step 1310). In the example of FIGS. 9A to 9C, a guard 906 and a guard 907 are added.

The intermediate product generation unit 118 adds an action “increment the counter variable” to the true event (step 1311). In the example of FIGS. 9A to 9C, an event 908 is added.

The intermediate product generation unit 118 adds an action “substitute a value obtained by adding 1 to the scheduler line number of else corresponding to the if branch condition to the counter variable” to the false event (step 1312). ). In the example of FIG. 8, the row number of else 807 is 4. Therefore, as shown in FIGS. 9A to 9C, an action 909 is added.

The intermediate product generation unit 118 creates an exit event to escape from the branch when the if branch condition is true. The exit event has a guard that “the counter variable is equal to the scheduler line number of the else” and an action “substitute a value obtained by adding 1 to the scheduler line number of fi for the counter variable”. (Step 1313). In the example of FIG. 8, the line number of else 807 is 4 and the line number of fi 805 is 5. Therefore, as shown in FIGS. 9A to 9C, an exit event 910 is added.

The intermediate product generation unit 118 creates a true event that is a branch event when the acquired do loop condition is true and a false event that is a branch event when the acquired do loop condition is false. Set affirmative of the do loop condition to the guard of the above true event. The negative of the false event guard is set (step 1314). Taking the do loop condition 802 of FIG. 8 as an example, as shown in FIGS. 9A to 9C, an event loop1_true is created as a true event and an event loop1_false is created as a false event. In each event, a guard 911 and a guard 912 are added.

The intermediate generation unit 118 adds a guard that “the counter variable is equal to the scheduler line number of the do loop condition” to the true / false event (step 1315). In the example of FIGS. 9A to 9C, a guard 913 and a guard 914 are added.

The intermediate product generation unit 118 adds an action “increment the counter variable” to the true event (step 1316). In the example of FIGS. 9A to 9C, an action 915 is added.

The intermediate product generation unit 118 adds an action of “substitute a value obtained by adding 1 to the scheduler line number of od to the counter variable” to the false event (step 1317). In the example of FIG. 8, the line number of od is 6. Therefore, as shown in FIGS. 9A to 9C, an action 916 is added.

The intermediate generation unit 118 creates a return event for returning from od to do by a do loop. The return event has a guard that “the counter variable is equal to the scheduler line number of od” and an action that “assigns the scheduler line number of do to the counter variable” (step 1318). In the example of FIG. 8, since the line number of od is 6, a return event 917 is added as shown in FIGS. 9A to 9C.

14A to 14C are flowcharts showing an example of a procedure for generating a Flattened code among the procedures of the intermediate product generation unit.

The processing shown below is realized by a program executed by the memory 202 by the CPU 202 included in the source code generation device 201. And this program is comprised from the code | cord | chord for performing the various operation | movement demonstrated below.

The CPU 202 executes the intermediate product generation unit 118 to acquire the first line among the unprocessed lines of the scheduler (step 1401).

The intermediate product generation unit 118 executes the following procedure depending on the type of acquisition line acquired in step 1401. If the acquisition line is an event, step 1403 is executed. If the acquired line is an if branch condition, step 1409 is executed. If the acquired line is a do loop condition, step 1413 is executed. In other cases, Step 1407 is executed (Step 1402).

The intermediate product generation unit 118 determines whether or not the acquired event is INITIALIZATION. If the event is INITIALIZATION, step 1404 is executed. If the event is not INITIALIZATION, step 1405 is executed (step 1403).

The intermediate product generation unit 118 creates a code that declares a variable that is initialized by the acquired INITIALIZATION event (step 1404). In the example of FIGS. 6A and 6B, since variables p, q, and r are initialized by the INITIALIZATION event, these variables are declared by code 1001 as shown in FIG.

The intermediate product generation unit 118 converts the acquired action of the event into a code of the programming language. An example of the conversion rule is shown in FIG. (Step 1405). Taking the event inc of FIGS. 6A and 6B as an example, a code 1002 is created as shown in FIG.

The intermediate product generation unit 118 assigns the scheduler line number of the event as a label at the top of the code created in step 1405 (step 1406). For example, in the example of FIG. 8, since the scheduler line number of the event inc is 3, the label 3 is given to the code 1002 in FIG.

If there is an unprocessed line in the scheduler, the intermediate generation unit 118 returns to Step 1401. If all the rows have been processed, the process proceeds to step 1408 (step 1407). The intermediate generation unit 118 arranges the created codes in the order of the label numbers (step 1408).

The intermediate product generation unit 118 creates an if statement code having the negation of the acquired if branch condition as a branch condition. In the processing of the if statement code, a goto statement code for jumping to the label obtained by adding 1 to the scheduler line number of else corresponding to the acquired if branch condition is described (step 1409). Taking the if branch condition 801 of FIG. 8 as an example, the row number of the corresponding else 807 is 4. Therefore, the code 1004 in FIG. 10 is created.

The intermediate product generation unit 118 assigns the scheduler line number of the if branch condition as a label of the if statement code (step 1410). In the example of FIG. 10, label 2 is given as indicated by code 1004.

The intermediate product generation unit 118 creates a goto statement code that jumps to a label obtained by adding 1 to the scheduler line number of fi corresponding to the above if branch condition (step 1411). In the example of FIG. 8, since the line number of fi 805 is 5, the code 1005 is created in the example of FIG.

The intermediate product generation unit 118 assigns the else scheduler line number corresponding to the if branch condition as a label of the goto statement code (step 1412). In the example of FIG. 8, the line number of else 807 is 4, and therefore, in the example of FIG. 10, the label 4 is given as indicated by the code 1005.

The intermediate product generation unit 118 creates a code for an if statement having the negation of the acquired do loop condition as a branch condition. In the processing of the if statement code, a goto statement code that jumps to a label obtained by adding 1 to the scheduler line number of od corresponding to the acquired do loop condition is described (step 1413). Taking the do loop condition 802 of FIG. 8 as an example, the line number of the corresponding od 806 is 6. Therefore, the code 1003 in FIG. 10 is created. The intermediate product generation unit 118 assigns the scheduler line number of the do loop condition as a label of the if statement code (step 1414). In the example of FIG. 10, label 1 is given as indicated by code 1003.

The intermediate product generation unit 118 creates a goto statement code that jumps to the label of the if statement code (step 1415). In the example of FIG. 10, a code 1006 is created. The intermediate product generation unit 118 assigns the scheduler line number of od corresponding to the do loop condition as a label of the goto statement code (step 1416). In the example of FIG. 10, the label 6 is given as indicated by the code 1006.

Fig. 15 shows an example of conversion rules from Event-B language to C language. The conversion rule 1501 includes an Event-B description 1502 and a C language description 1503. An Event-B description 1502 represents a description of the conversion source Event-B language, and x and y appearing in the description are meta variables to which an arbitrary logical expression representing a true / false value is substituted. Similarly, a and b are meta variables to which an arbitrary logical expression representing a numerical value is substituted. The C language description 1503 represents the description of the conversion destination C language, and x and y, and a and b appearing in the description correspond to the same symbols appearing in the Event-B description 1502. A description such as T (x) represents the result of converting x by this conversion rule. For example, for variables p and q, T (p∧q) means (p && q).

16A and 16B are flowcharts showing an example of the procedure of the code generation unit. The processing shown below is realized by a program executed by the memory 203 by the CPU 202 included in the source code generation device 201. And this program is comprised from the code | cord | chord for performing the various operation | movement demonstrated below.

The CPU 202 executes the code generation unit 105 to acquire the first line among the unprocessed lines of the scheduler (step 1601).

The code generation unit 105 executes the following procedure depending on the type of acquisition line acquired in step 1601. If the acquisition line is an event, step 1603 is executed. If the acquired line is an if branch condition, step 1607 is executed. If the acquired line is a do loop condition, step 1408 is executed. If the acquisition line is else, step 1611 is executed. If the acquisition line is fi, step 1609 is executed. If the acquisition line is od, step 1610 is executed. If the acquired line is a precondition or a postcondition, step 1606 is executed (step 1602).

The code generation unit 105 determines whether or not the acquired event is INITIALIZATION. If the event is INITIALIZATION, step 1604 is executed. If the event is not INITIALIZATION, step 1605 is executed (step 1603).

The code generation unit 105 creates a code that declares a variable that is initialized by the acquired INITIALIZATION event (step 1604). In the example of FIGS. 6A and 6B, since variables p, q, and r are initialized by the INITIALIZATION event, these variables are declared by code 1101 as shown in FIG.

The code generation unit 105 converts the acquired action of the event into a code of the programming language. An example of the conversion rule is as shown in FIG. (Step 1605). Taking the event inc of FIGS. 6A and 6B as an example, a code 1102 is created as shown in FIG.

If there is an unprocessed line in the scheduler, the code generation unit 105 returns to Step 1601. If all the rows have been processed, the processing ends (step 1606). The code generation unit 105 creates an if statement code having the acquired if branch condition as a branch condition and a process start point bracket ({) (step 1607). In the example of the if branch condition 801 in FIG. 8, a code 1103 is created as shown in FIG.

The code generation unit 105 describes a while statement code having the acquired do loop condition as a loop condition and a process start point bracket ({) (step 1608). In the example of the do loop condition 802 in FIG. 8, the code 1104 is created as shown in FIG.

The code generation unit 105 describes the end bracket (}) of the if statement code corresponding to the acquired fi (step 1609). In the example of fi805 in FIG. 8, the code 1105 in FIG. 11 is created.

The code generation unit 105 describes the end bracket (}) of the while statement code for the acquired od (step 1610). In the example of od806 in FIG. 8, the code 1106 in FIG. 11 is created.

The code generation unit 105 describes the end bracket (}) of the if statement code, the else statement code, and the start bracket ({) of the else statement code for the acquired else (step 1611). In the example of else 807 in FIG. 8, the code 1107 in FIG. 11 is created.

FIG. 17 is a flowchart showing an example of the procedure of the model detailing certification unit. The processing shown below is realized by a program executed by the memory 203 by the CPU 202 included in the source code generation device 201. And this program is comprised from the code | cord | chord for performing the various operation | movement demonstrated below.

The CPU 202 acquires the Restricted model from the Restricted model holding unit by executing the model detailing certification unit 109. Furthermore, the Scheduled model generated from the Restricted model by the intermediate generation unit 118 is acquired from the Scheduled model holding unit 106. Then, the Scheduled model machine is set as the Restricted model detail machine. Specifically, the most detailed machine name of the Restricted model is set in REFINES of the Scheduled model machine (step 1701).

The model detailing certification unit 109 makes it possible to refer to the context referred to by the Restricted model from the Scheduled model. Specifically, the name of the context referenced by the most detailed machine of the Restricted model (SEES) is set in the SEES of the Scheduled model machine (step 1702).

The model detailing proof unit 109 generates a proof obligation regarding refinement from the Restricted model and the Scheduled model. Non-patent document 2 pp. Describes how to create a proof obligation for refinement. 192-197 and the like (step 1703).

The model detailing proof unit 109 proves the proof duty using an inference rule. The proof of the proof obligation is pp of Non-Patent Document 2. 306-352 and the like. The certification result is registered in the detailed certification result holding unit 110 (step 1704).

18A and 18B are flowcharts showing an example of the procedure of the intermediate equivalence equivalence proving unit. The processing shown below is realized by a program executed by the memory 203 by the CPU 202 included in the source code generation device 201. And this program is comprised from the code | cord | chord for performing the various operation | movement demonstrated below.

The CPU 202 executes the intermediate equivalence proof unit 114 to acquire the Scheduled model from the Scheduled model holding unit 106, and acquires the INITIALIZATION event (Step 1801).

The intermediate equivalence proof unit 114 acquires an event having the smallest counter variable value restricted by the guard among unprocessed events of the Scheduled model. There may be a plurality of events having the smallest counter variable value (step 1802).

The intermediate equivalence proof unit 114 determines whether the event acquired in Step 1802 includes a guard other than the guard that restricts the counter variable. If yes, go to Step 1804. If not included, the process proceeds to step 1805 (step 1803).

The intermediate equivalence proof unit 114 extracts a false event that is an event having a negative guard from the event acquired in Step 1802 (Step 1804). In the example of FIGS. 9A to 9C, there are two events, loop1_true and loop1_false, as events for which the counter variable pc is constrained to 1. Of these, the event loop1_false having a negative guard 912 is extracted.

The intermediate equivalence proof unit 114 confirms whether the action for updating the counter variable among the actions included in the event acquired in Step 1802 is “pc: = pc + 1”. In the case of the above action, step 1809 is executed. If it is not the above action, step 1808 is executed (step 1805). For example, in the event inc of FIGS. 9A to 9C, the substitution action for the counter variable pc is “pc: = pc + 1” as shown in action 902. Therefore, step 1809 is executed. On the other hand, for the event if1_exit, the substitution action for pc is “pc: = 6”. Therefore, in this case, step 1808 is executed.

The intermediate equivalence proof unit 114 creates an if statement code having the false event guard as a branching condition (step 1806). For example, in the case of the event loop1_false in FIGS. 9A to 9C, a code corresponding to the code 1004 is generated.

The intermediate equivalence prover 114 creates a goto statement code that jumps to the label of the value assigned to the counter variable in the false event, and adds it as the processing of the if statement code (step 1807). For example, in the case of event loop1_false in FIGS. 9A to 9C, the value assigned to the counter variable pc is 7. In this case, a code corresponding to the goto statement of the code 1003 is generated.

The intermediate equivalence proof unit 114 creates a goto statement code that jumps to the label of the number assigned to the counter variable in the action of updating the counter variable of the acquired event (step 1808). In the case of the event if1_exit in FIGS. 9A to 9C, since the number assigned to the counter variable pc is 6, a code corresponding to the code 1005 is generated.

The intermediate equivalence proof unit 114 converts the action of the acquired event into a code of the programming language. An example of the conversion rule is as shown in FIG. 15 (step 1809).

The intermediate equivalence equivalence proving unit 114 assigns the value of the counter variable restricted by the event guard acquired in step 1802 as a label to the first line of the code created in the above step. However, in the case of the INITIALIZATION event, since no guard is included, 0 is assigned as a label (step 1810). For example, in the event inc of FIGS. 9A to 9C, the value of the counter variable pc restricted by the guard 901 is 3. Therefore, as shown in FIG. 10, the label 2 is given to the code 1002.

The intermediate equivalence proof unit 114 checks whether there is an unprocessed event among the events included in the Scheduled model. If there is an unprocessed event, the process returns to step 1802. If all events have been processed, step 1812 is executed (step 1811).

The intermediate equivalence proof unit 114 acquires the generated flattened code corresponding to the Scheduled model created by the procedure shown in FIGS. 14A to C from the flattened code holding unit 107, and the code created in the above step. Compare (step 1812).

If the generated Flattened code matches the generated code, the intermediate equivalence proof unit 114 executes Step 1814. If not, step 1815 is executed (step 1813).

The intermediate equivalence proof unit 114 outputs the equivalence proof success and registers it as a proof result in the intermediate proof result holding unit 115 (step 1814). The intermediate equivalence proof unit 114 outputs an equivalence proof failure and registers it as a proof result in the intermediate proof result holding unit 115 (step 1815).

FIG. 19 is a flowchart showing an example of the procedure of the code equivalence proof unit. The processing shown below is realized by a program executed by the memory 203 by the CPU 202 included in the source code generation device 201. And this program is comprised from the code | cord | chord for performing the various operation | movement demonstrated below.

The CPU 202 executes the code equivalence proving unit 116 to acquire the flattened code from the flattened code holding unit 107, and performs code conversion by the goto conversion process shown in FIGS. 20A and 20B (step 1901).

The code equivalence proving unit 116 acquires the generated Target code corresponding to the Flattened code created by the procedure shown in FIGS. 16A and B from the Target code holding unit 108, and the code created in Step 1901 Compare (step 1902)
If the generated Target code matches the created code, the code equivalence proving unit 116 executes Step 1904. If they do not match, step 1905 is executed (step 1903).

The code equivalence proof unit 116 outputs the equivalence proof success and registers it as a proof result in the code proof result holding unit 117 (step 1904). The code equivalence proof unit 116 outputs an equivalence proof failure and registers it as a proof result in the code proof result holding unit 117 (step 1905).

20A and 20B are flowcharts showing an example of the procedure of goto conversion processing. The processing shown below is realized by a program executed by the memory 203 by the CPU 202 included in the source code generation device 201. And this program is comprised from the code | cord | chord for performing the various operation | movement demonstrated below.

The CPU 202 executes the code equivalence proof unit 116 to acquire the first line among the unprocessed lines of the input Flattened code (Step 2001).

The code equivalence proving unit 116 executes the following procedure depending on the type of acquired line acquired in step 2001. If the acquisition line is an if statement code, step 2004 is executed. If the acquired line is an assignment statement code, step 2003 is executed (step 2002).

The code equivalence prover 116 describes the acquired line including the assignment statement code as the assignment statement code as it is (step 2003).

The code equivalence prover 116 confirms whether or not a goto statement code that jumps to the acquired if statement code exists in the flattened code. If the goto statement code as described above exists, step 2005 is executed. If not, step 2008 is executed (step 2004).

The code equivalence prover 116 creates a while statement code having as a loop condition a condition in which negation is removed from the branch condition of the acquired if statement code (step 2005). Taking FIG. 10 as an example, while statement code 1104 in FIG. 11 is created from if statement code 1003.

The code equivalence prover 116 recursively applies this goto conversion process to the code between the acquired if statement code and the goto statement code jumping to the if statement code in the flattened code (step 2006). ). In the example of FIG. 10, recursion is applied to the code between the if statement code 1003 and the goto statement code 1006.

The code equivalence prover 116 describes the code created by the recursive application as the process of the while statement code created in step 2005 (step 2007).

The code equivalence proof unit 116 creates an if statement code having as a branch condition a condition from which negation is removed from the branch condition of the acquired if statement code (step 2008). In the example of FIG. 10, the if statement code 1103 of FIG. 11 is created from the if statement code 1004.

The code equivalence proving unit 116 in the Flattened code, the goto statement code in a line obtained by subtracting 1 from the previous line to be jumped by the goto statement code included in the processing of the if statement code from the acquired if statement code The goto conversion process is recursively applied to the code between the steps (step 2009). In the example of FIG. 10, recursion is applied to codes between the if statement code 1004 and the goto statement code 1005.

The code equivalence proving unit 116 describes the code created by the recursive application as the process of the if statement code created in step 2008 (step 2010).

The code equivalence proving unit 116 describes the goto statement code on the line obtained by subtracting 1 from the jump destination line by the goto statement code included in the processing of the acquired if statement code as the else statement code (step 2011). ). In the example of FIG. 10, the else statement code 1107 of FIG. 11 is created from the goto statement code 1005.

For the goto statement code converted into the else statement code in step 2011, the code equivalence proving unit 116 performs this goto statement on the code between the goto statement code and the line to which the jump is made in the goto statement. The conversion process is recursively applied (step 2012). In the example of FIG. 10, the code is recursively applied to the code between the goto statement code 1005 and the code 1006.

The code equivalence proving unit 116 describes the code created by the recursive application as processing of the else statement code created in step 2011 (step 2013).

As described above, in the present embodiment, the source code generation device and the source code certification device are separate devices, but each function may be realized by one device.

As described above, according to the source code generation device of the present embodiment, when generating source code from a formal model that formally proves the correctness of software specifications, a scheduled model that is a formal model including a control structure is generated. Generate Flattened code that is source code using goto statement instead of if branch and do loop. The Scheduled model and the Flattened code play a role of bridging the difference regarding the presence / absence of the control structure between the Restricted model and the Target code and the difference in language. In other words, the detailed relationship between the formal model of the generation source and the Scheduled model, the equivalence of the Scheduled model and the Flattened code, and the equivalence of the Flattened code and the generated source code It becomes possible to prove that the source code is the result of refining the specification expressed by the formal model of the generation source. Therefore, if there is an error in the generated source code, this can be detected. As described above, a reduction in software defects can be achieved.

DESCRIPTION OF SYMBOLS 101 Model edit part 102 Developed model holding part 103 Model conversion part 104 Restricted model holding part 105 Code generation part 106 Scheduled model holding part 107 Flattened code holding part 108 Target code holding part 109 Model refinement certification part 110 Detailed certification result holding part 111 Scheduler Holding Unit 112 Scheduler Editing Unit 113 Scheduler Checking Unit 114 Intermediate Equivalence Proof Unit 115 Intermediate Product Proof Result Holding Unit 116 Code Equivalence Proof Unit 117 Code Proof Result Holding Unit 118 Intermediate Product Generation Unit

Claims (7)

1. A source code generation device for generating a source code described in a programming language from a software specification described in a formal language,
   A scheduler editing means for editing a scheduler defining a control structure including at least an if conditional branch structure and a do loop structure for processing of the software specification not including a control structure;
   Source code generation means for generating source code including at least an if conditional branch structure or a do loop structure from the software specification and the edited scheduler;
   Scheduled model generation means for generating a Scheduled model including a control structure described in the formal language from the software specification and the edited scheduler;
   Flattened code generation means for generating a flattened code including the goto statement without including the if conditional branch structure and the do loop structure from the software specification and the edited scheduler;
   A source code generation device comprising:
2. A refinement proving means for proving a refinement relationship between the software specification and the Scheduled model;
   Intermediate equivalence proof means for proving equivalence between the Scheduled model and the Flattened code;
   Code equivalence proving means for proving equivalence between the flattened code and the source code;
   The source code generation device according to claim 1, comprising:
3. The software specification includes an event composed of a guard condition and an assignment action,
   The scheduler editing means describes an if condition branch element that is an if condition branch structure that processes the event, a do loop element that is a do loop structure that processes the event, and a sequential combination of the events, For the event, the if conditional branch element, and the do loop element, describe a pre-state and a post-state as conditions to be satisfied before and after the execution, respectively,
   A scheduler checking unit that checks the scheduler in which the if conditional branch element, the do loop element, the sequential combination, and the pre-state and post-state are described;
   The scheduler checking means confirms that the precondition and the postcondition are not inconsistent in the if condition branch element, the do loop element, and the sequential combination described in the scheduler,
   The source code generation apparatus according to claim 1, wherein the source code generation apparatus is a source code generation apparatus.
4. Generate another software specification written in a formal language that includes variables and constants with upper and lower limits from pre-constraint specifications that contain variables and constants that do not have upper or lower limits. And when the software specification includes an arithmetic expression, the upper limit value and the lower limit value of the constant are prevented from being assigned to the variable by the arithmetic expression above the upper limit value and the lower limit value. Software specification generation means to set,
   The source code generation device according to any one of claims 1 to 3, further comprising:
5. A software specification that is described in a formal language and does not include a control structure, and a process that defines the control structure that includes at least an if conditional branch structure and a do loop structure, and a programming language that describes the processing of the software specification that does not include a control structure Written in the programming language generated from the software specification and the edited scheduler, and including a control model described in the formal language generated from the software specification and the edited scheduler Accepting means for receiving the Flattened code including the goto statement without including the if conditional branch structure and the do loop structure as evidence proving the correctness of the source code with respect to the software specification from the source code generation device;
   Refinement proving means for proving the refinement relationship between the software specification and the Scheduled model;
   Intermediate equivalence proof means for proving equivalence between the Scheduled model and the Flattened code;
   Code equivalence proving means for proving equivalence between the flattened code and the source code;
   A source code proof device comprising:
6. A source code generation method for generating a source code described in a programming language from a software specification described in a formal language,
   A scheduler editing step for editing a scheduler that defines a control structure including at least an if conditional branch structure and a do loop structure for processing of the software specification that does not include a control structure;
   A source code generation step for generating a source code including at least an if conditional branch structure or a do loop structure from the software specification and the edited scheduler;
   A scheduled model generation step for generating a scheduled model including a control structure described in the formal language from the software specification and the edited scheduler;
   A flattened code generation step for generating a flattened code including the goto statement without including the if conditional branch structure and the do loop structure from the software specification and the edited scheduler;
   A source code generation method comprising:
7. On the computer,
   A scheduler editing step for editing a scheduler that defines a control structure including at least an if conditional branch structure and a do loop structure for processing of software specifications described in a formal language that does not include a control structure;
   A source code generation step of generating a source code described in a programming language including at least an if conditional branch structure or a do loop structure from the software specification and the edited scheduler;
   A scheduled model generation step for generating a scheduled model including a control structure described in the formal language from the software specification and the edited scheduler;
   A flattened code generation step for generating a flattened code including the goto statement without including the if conditional branch structure and the do loop structure from the software specification and the edited scheduler;
   A source code generation program characterized in that

Images