JP6363027B2 - Verification device, verification system, verification method, and program - Google Patents

Description

  Embodiments described herein relate generally to a verification apparatus, a verification system, a verification method, and a program.

  In software development, source code is created from specifications. At this time, there are a basic design document, a detailed design document, and the like as a document to be a software design drawing. Usually, these are created for each function (module). Therefore, when designing and manufacturing software, modules are manufactured from a design document for each function, and one software is manufactured by combining the modules. In order to extract software specifications, it is necessary to classify modules from the software source code and investigate the behavior of each module.

  As the above-mentioned software specifications, for example, there is a decision table (decision table) that defines the relationship between input conditions and output values. However, whether such software specifications precisely specify the behavior of the source code, or whether the behavior of the source code operates according to the software specifications. In order to verify equivalence, a separate verification tool is required.

  Here, for example, the behavior of the source code sets the verification range (value range of the variable in the function) and the expected value of the output variable in the verification range, and the behavior of the source code is set to the verification A technique for verifying whether an output variable is an expected value within a range has been proposed.

JP 2013-239008 A

  However, it is not clear whether the verification technology as described above can verify the combination of the verification range and the expected value as a whole. For example, a specification that summarizes the combination of the input condition and the output value as in a decision table. There was a problem that it was not suitable to verify the information.

  In addition, in order to verify the source code to be verified, the necessary verification code (code for recognition by the verification tool) must be described in advance in the C language comment format in the source code. There was also the problem of having to.

  The present invention has been made in view of the above, and it is not necessary to describe a comment or the like for a source code to be verified, and a verification device and a verification system that can verify equivalence with a decision table It is an object to provide a verification method and a program.

The verification apparatus according to the embodiment includes a table generation unit, a first generation unit, a second generation unit, a code generation unit, and a verification unit. The table generating means generates a decision table indicating values corresponding to the input conditions of the output variables included in the source code from the source code. The first generation means extracts a combination of true / false values of the input condition from a decision table indicating fluctuations in the value of the output variable according to the input condition, and generates a first code that defines the combination. The second generation unit extracts a value of the output variable corresponding to the combination extracted by the first generation unit from the decision table, and generates a second code that defines the value of the output variable. The code generation means generates the verification code by adding the first code to the preceding stage of the execution code for executing the source code and adding the second code to the succeeding stage of the execution code. The verification unit verifies the equivalence between the decision table and the source code by executing the verification code. The table generation unit includes a specifying unit, a first conversion unit, a creation unit, and a second conversion unit. The specifying unit specifies an output variable from the source code. The first conversion means executes an equivalent conversion process for replacing an expression included in the source code with an equivalent expression, and derives an equation for the output variable specified by the specifying means. The creating means extracts an input condition from the equation and creates a cause / result graph having the input condition as a node. The second conversion means converts the cause / result graph into a decision table indicating the correspondence between the combination of the true / false values of the input condition and the value of the output variable.

FIG. 1 is a diagram illustrating an example of a hardware configuration of the verification apparatus. FIG. 2 is a diagram illustrating an example of a functional block configuration of the verification apparatus. FIG. 3 is a diagram for explaining the operation of generating the value of the output variable from the input variable. FIG. 4 is a flowchart illustrating an example of the specification extraction operation. FIG. 5 is a diagram for explaining constant propagation processing. FIG. 6 is a diagram for explaining the input variable propagation process. FIG. 7 is a diagram for explaining the pruning process. FIG. 8 is a diagram for explaining conditional expression information propagation processing. FIG. 9 is a flowchart showing a part of the equivalent conversion process. FIG. 10 is a diagram showing a sample of the module source code. FIG. 11 is a diagram illustrating processing for specifying an output variable. FIG. 12 is a diagram for explaining constant propagation processing and input propagation processing. FIG. 13 is a diagram illustrating the pruning process. FIG. 14 is a diagram for explaining conditional expression information propagation processing. FIG. 15 is a diagram for explaining an operation for obtaining an equation by executing conditional expression information propagation processing. FIG. 16 is a diagram for explaining an operation of converting into an equation represented by a logical operator. FIG. 17 is a diagram illustrating an operation for setting an output variable as a temporary variable. FIG. 18 is a diagram for explaining an operation of deriving an intermediate cause / result graph. FIG. 19 is a diagram for explaining an operation of deriving a final cause / result graph. FIG. 20 is a diagram illustrating an operation for creating a decision table. FIG. 21 is a diagram for explaining the outline of the operation for creating the verification code. FIG. 22 is a flowchart showing an example of the equivalence checking operation. FIG. 23 is a diagram illustrating an example of setting a precondition and a postcondition code. FIG. 24 is a diagram illustrating another example in which codes for the precondition and the postcondition are set. FIG. 25 is a diagram for explaining the outline of the operation for creating the verification code.

  In the following drawings, the same portions are denoted by the same reference numerals. However, the drawings are schematic, and the relationship between the thickness and the planar dimensions, the ratio of the thickness of each layer, and the like may differ from the actual ones. Therefore, specific thicknesses and dimensions should be determined in consideration of the following description.

(First embodiment)
FIG. 1 is a diagram illustrating an example of a hardware configuration of the verification apparatus according to the first embodiment. A hardware configuration of the PC 1 which is an example of the verification apparatus will be described with reference to FIG.

  As shown in FIG. 1, the PC 1, which is an example of a verification device, includes a communication unit 11, an operation unit 12, a display unit 13, a storage unit 14, an external storage device 15, a control unit 16, and a CD-ROM. And a drive 18. The above-described units are connected by a bus 19 and can transmit / receive data to / from each other.

  The communication unit 11 is a device that communicates with an external device. The communication part 11 is implement | achieved by communication apparatuses, such as NIC (Network Interface Card), for example. For example, TCP (Transmission Control Protocol) / IP (Internet Protocol) or UDP (User Datagram Protocol) / IP can be applied as the communication protocol of the communication unit 11.

  The operation unit 12 is a device that performs an operation input for causing the control unit 16 to execute a predetermined process by the user. The operation unit 12 is realized by, for example, an operation input function in a mouse, a keyboard, a numeric keypad, a touch pad, or a touch panel.

  The display unit 13 is a device that displays an application image or the like being executed by the control unit 16. The display unit 13 is realized by, for example, a CRT (Cathode Ray Tube) display, a liquid crystal display, a plasma display, an organic EL (Electroluminescence) display, or the like.

  The storage unit 14 is a device that stores various programs executed by the PC 1 and data used for various processes performed by the PC 1. The storage unit 14 is realized by a storage device such as a ROM (Read Only Memory) and a RAM (Random Access Memory), for example.

  The external storage device 15 is a storage device that accumulates and stores programs, source codes, various data, and the like. The external storage device 15 is realized, for example, by a storage device such as a hard disk drive (HDD), a solid state drive (SSD), an optical disk, or a magneto-optical disk (MO: Magneto-Optical Disk).

  The control unit 16 is a device that controls the operation of each unit of the PC 1. The control unit 16 is realized by, for example, a CPU (Central Processing Unit) and an ASIC (Application Specific Integrated Circuit).

  The CD-ROM drive 18 is a device that controls reading and writing of data with respect to a CD-ROM (Compact Disc Read Only Memory) 17 as an example of a removable storage medium. As another example of the removable storage medium described above, the program is stored in a computer-readable storage medium such as a CD-R (Compact Disc Recordable), a DVD (Digital Versatile Disk), or a Blu-ray disc. It may be configured.

  FIG. 2 is a diagram illustrating an example of a functional block configuration of the verification apparatus according to the first embodiment. The configuration of functional blocks of the PC 1 will be described with reference to FIG.

  As shown in FIG. 2, the PC 1 includes a specification extraction unit 100 (table generation unit), an equivalence verification unit 150, and a storage unit 160 as units for realizing each function.

  The specification extraction unit 100 is a functional unit that generates a decision table (decision table) as specification information from the source code of a software module (target module) that is the target of the specification extraction operation. The specification extracting means 100 includes an output variable specifying means 101 (specifying means), an equivalent converting means 102 (first converting means), a graph generating means 103 (creating means), a table converting means 104 (second converting means), Have.

  The output variable specifying unit 101 is an output variable (for example, a global code) included in a source code (for example, a source code stored in a first storage unit 161 described later) of a software module (target module) that is a target of a specification extraction operation. This is a functional unit that extracts and identifies variables. Here, the global variable is a variable declared outside each module of the software, and can be referred to and updated in any module.

  The equivalent conversion means 102 is a functional unit that executes equivalent conversion processing on the module source code, reduces the source code, and derives an equation for the output variable. The equivalent conversion process includes a constant propagation process, an input variable propagation process, a pruning process, a conditional expression information propagation process, and the like. Details of each process will be described later.

  The graph creation unit 103 is a functional unit that creates a cause / result graph from the equation for the output variable derived by the equivalent conversion unit 102. Here, the cause / result graph is a graph for deriving an output value from a combination of input conditions by using one or a plurality of input conditions as nodes and connecting the nodes with logical symbols. Details of the operation for creating the cause-result graph will be described later.

  The table conversion unit 104 is a functional unit that converts the cause / result graph created by the graph creation unit 103 into a decision table. Here, the decision table is a table showing what value of the output variable (output value) takes from the combination of the input conditions, and expresses the behavior of the module, that is, determines the specification of the module. Is.

  The equivalence verification unit 150 is a functional unit that verifies the equivalence between the decision table generated by the specification extraction operation by the specification extraction unit 100 and the source code subjected to the specification extraction operation. Here, “having equivalence” refers to a case in which when the source code is executed, it operates according to the behavior defined by the specification information (for example, a decision table). The equivalence verification unit 150 includes a code generation unit 151, a verification unit 152, and a result output unit 153.

  The code generation unit 151 is a functional unit that generates a verification code for verifying the equivalence between the source code and the decision table. The code generation unit 151 includes a precondition setting unit 151a (first generation unit) and a post condition setting unit 151b (second generation unit).

  The precondition setting unit 151a is a code that defines the input condition of the decision table generated by the specification extraction unit 100 as the verification code for the source code (hereinafter referred to as the verification target source code) to be verified for equivalence. 1 code). The post-condition setting unit 151b adds the value (output value) of the output variable corresponding to the input condition set by the pre-condition setting unit 151a of the decision table generated by the specification extraction unit 100 to the verification code for the verification target source code. This is a functional unit for setting a code (second code) that defines.

  The verification unit 152 analyzes the verification code generated by the code generation unit 151 and executes the verification target source code. When the input condition set by the precondition setting unit 151a is satisfied, the post-condition setting unit It is a functional unit that verifies whether or not the output value set by 151b is obtained. The verification unit 152 can use an existing model checking tool (model checking software) such as CBMC (Bounded Model Checking for C / C ++).

  The result output unit 153 is a functional unit that outputs the verification result of the verification target source code verified by the verification unit 152. For example, the result output unit 153 may output the verification result as data, store it in the storage unit 14 and save it, or display the verification result on the display unit 13.

  Note that the “module” in this embodiment is a software component having a specific function, and the code of the program that is the entity is described as “source code”, but it is intended to clearly distinguish both of them. Not what you want.

  The storage unit 160 is a functional unit that stores various programs executed by the control unit 16 and data used for various processes performed by the PC 1. The storage unit 160 is realized by the storage unit 14 shown in FIG. The storage unit 160 includes a first storage unit 161 and a second storage unit 162.

  The first storage unit 161 is a functional unit that stores a source code that is a target of a specification extraction operation and a target of equivalence verification. The second storage unit 162 is a functional unit that stores the decision table generated by the specification extraction unit 100 as data.

  The above-described output variable specifying means 101, equivalent conversion means 102, graph creation means 103, table conversion means 104, code generation means 151, verification means 152, and result output means 153 are controlled by the control unit 16 of the PC 1 in the external storage device 15 or the like. This is realized by reading the stored program into the storage unit 14 and executing it. The output variable specifying means 101, equivalent conversion means 102, graph creation means 103, table conversion means 104, code generation means 151, verification means 152, and result output means 153 are all limited to being realized by executing a program. However, at least one of them may be realized by a hardware circuit.

  Further, the functional block configuration shown in FIG. 2 conceptually shows functions, and is not limited to such a configuration. For example, a plurality of functional units illustrated as independent functional units in FIG. 2 may be configured as one functional unit. On the other hand, the function of one functional unit in FIG. 2 may be divided into a plurality of parts and configured as a plurality of functional parts.

  FIG. 3 is a diagram for explaining the operation in which the module generates the value of the output variable from the input variable. With reference to FIG. 3, an outline of the operation of the target module 20 as a module will be described.

  As illustrated in FIG. 3, the target module 20 has a function of executing a predetermined process based on a value (input value) stored in an input variable, storing an output value in an output variable, and outputting the output value. The value of the input variable of the target module 20 is data input from the outside of the target module 20, and is stored in, for example, an argument and a global variable. The value of the output variable of the target module 20 is data transmitted to the outside of the target module 20 and is, for example, the value of a global variable updated in the target module 20. Extracting such operation specifications based on the input / output relationship of the target module 20 corresponds to obtaining the above-described decision table.

  FIG. 4 is a flowchart illustrating an example of the specification extraction operation of the verification apparatus according to the first embodiment. FIG. 5 is a diagram for explaining constant propagation processing. FIG. 6 is a diagram for explaining the input variable propagation process. FIG. 7 is a diagram for explaining the pruning process. FIG. 8 is a diagram for explaining conditional expression information propagation processing. FIG. 9 is a flowchart showing loop processing of constant propagation processing, input variable propagation processing, and pruning processing in the equivalent conversion processing. With reference to FIGS. 4 to 9, the flow of the specification extraction operation of the PC 1 as the verification device will be described.

(Step S10)
The output variable specifying unit 101 reads and inputs the source code of the target module stored in the first storage unit 161. The output variable specifying unit 101 specifies an output variable in a function included in the source code. Specifically, the output variable specifying unit 101 specifies an updated global variable in a function included in the source code as an output variable. Then, the process proceeds to step S11.

  The output variable specifying unit 101 specifies the global variable to be updated in the function included in the source code as the output variable, but is not limited to this. For example, the output variable specifying unit 101 may specify the return value of the function, not the global variable of the target module, as the output variable.

  The output variable specifying unit 101 reads the source code from the first storage unit 161 and inputs it. However, the present invention is not limited to this, and the source directly input by the user via the operation unit 12 is not limited thereto. It is good also as what inputs a code.

(Step S11)
The equivalent conversion means 102 performs an equivalent conversion process on the source code of the target module, and derives an equation for the output variable. Specifically, the equivalent conversion unit 102 performs constant propagation processing, input variable propagation processing, pruning processing, and conditional expression information propagation processing as equivalent conversion processing.

  Here, the content of the constant propagation process will be described with reference to FIG. The constant propagation process is a process of determining whether or not the source code is valid at the time of reading (referring to) the variable, starting from the position where the constant is assigned to the variable, and replacing it with a constant if valid. A code obtained as a result of executing constant propagation processing for the sample code 30 shown in FIG.

  First, since the constant “1” is assigned to the variable “A” in the code part 300 of the sample code 30, this assigned location is used as a starting point.

  Next, the variable “A” is referenced in the code portion 301 of the sample code 30. The constant “1” is assigned to the variable “A” in the code part 300, and the constant “1” can be obtained by referring to the variable “A” in the code part 301. Replace with the constant “1”. As a result, the code portion 301 (“B = A + 1;”) can be replaced with the constant propagation post-constant code portion 310 (“B = 2;”) of the post-constant propagation post-processing code 31.

  Next, similarly, as a result of replacing the code part 301 with the code part 310 after constant propagation processing, the code part 302 (“C = B;”) of the sample code 30 causes the constant propagation of the code 31 after constant propagation processing. The post-processing code part 311 (“C = 2;”) can be substituted.

  Then, from the assignment of the constant “1” to the variable “A” in the code part 300, the code part 303 (“Func (A);”) of the sample code 30 is the code after the constant propagation process of the code 31 after the constant propagation process. The unit 312 (“Func (1);”) can be replaced. This means that the variable “A” as an argument of the function “Func” has been replaced with the constant “1”.

  As described above, in the constant propagation process, the source code can be simplified and reduced by replacing the variables in the source code with constants.

  Next, the contents of the input variable propagation process will be described with reference to FIG. The input variable propagation process refers to a process of replacing a variable with an input variable in an expression that uses the variable downstream from the position of the variable calculated using the input variable that is a global variable. A code obtained as a result of executing the input variable propagation process on the sample code 30a shown in FIG.

  First, in the code part 300a in the sample code 30a, since the input variable “g1” is substituted into the variable “a1”, the place where the substitution calculation is performed is used as a starting point.

  Next, in the code portion 301a (“a2 = a1 + 1;”) of the sample code 30a, since the variable “a1” in the code portion 300a is used for the calculation, after the input variable propagation processing of the code 31a after the input variable propagation processing It can be replaced with the code part 310a (“a2 = g1 + 1;”).

  As described above, in the input variable propagation process, the source code can be simplified and reduced by replacing the variable in the source code with the input variable.

  Next, the contents of the pruning process will be described with reference to FIG. As a result of executing the constant propagation process and the input variable propagation process, the pruning process replaces a branch conditional expression with a constant (for example, a conditional expression for an if statement, a case value for a switch statement), etc. This is a process for deleting an option that will not be executed from among the branch options. A code obtained by executing the pruning process on the sample code 30b illustrated in FIG. 7 is referred to as a post-pruning code 31b.

  In the code part 300b of the sample code 30b, a constant “1” is input to the variable “A”. Therefore, since the condition (“A == 0”) in the code part 301b of the sample code 30b that is a conditional branch expression is not satisfied, “branch 1;”, which is one of the branching options, is executed. Absent. Therefore, by deleting the “branch 1;” that is not executed, the code unit 301b that is a conditional branching expression can generate the post-pruning code unit 310b (“branch 2;” of the post-pruning code 31b. ).

  As described above, the pruning process can reduce the description amount of the conditional branching expression described over several lines (one line in the example of FIG. 7), so the source code can be simplified and reduced. Can do.

  Next, the contents of the conditional expression information propagation process will be described with reference to FIG. The conditional expression information propagation process refers to a process of replacing a conditional branch expression (for example, an “if” sentence and “switch” sentence) with a ternary expression. A code obtained as a result of executing the conditional expression information propagation process on the sample code 30c shown in FIG.

  The code part 300c of the sample code 30c is a conditional branching expression represented by an “if” statement. This code part 300c is replaced with a ternary expression using a ternary operator, and the conditional expression information post-processing code part 310c of the post-conditional information propagation process code 31c ("b = (A? 0: 1)" ;)).

  As described above, the conditional expression information propagation process can replace a conditional branch expression written over several lines with a one-line ternary expression, so that the source code can be simplified and reduced.

  Next, with reference to FIG. 9, the operation of performing loop processing of constant propagation processing, input variable propagation processing, and pruning processing will be described. As described above, the pruning process is performed after the constant propagation process and the input variable propagation process are performed. Of these, it is a process of deleting options that will not be executed. The execution order of the constant propagation process, the input variable propagation process, and the pruning process may be arbitrary.

  In addition, by executing the pruning process, the conditional branch expression is simplified, and a specific option out of the branch options comes out of the conditional branch expression, that is, the specific option is always executed. There is a possibility that the options that are always executed by the pruning process can be newly reduced by the constant propagation process or the input variable propagation process.

  From the above, the constant propagation process, the input variable propagation process, and the pruning process are executed according to the procedure shown in FIG. First, the equivalent conversion means 102 performs constant propagation processing (step S110) and input variable propagation processing (step S111) on the source code. Next, the equivalent conversion unit 102 performs a pruning process on the source code reduced by the constant propagation process and the input variable propagation process (step S112). Then, the equivalence conversion means 102 determines whether or not the contraction of the source code has converged as a result of executing the constant propagation process, the input variable propagation process and the pruning process, that is, whether or not the source code can be further contracted. Determine. If the contraction has converged (step S113: Yes), the process ends. If the contraction has not converged (step S113: No), the process returns to step S110.

  As described above, by executing the loop process of the constant propagation process, the input variable propagation process, and the pruning process shown in FIG. 9, the source code can be reduced more reliably. Then, the equivalent conversion unit 102 executes the conditional propagation process, the loop process of the constant propagation process, the input variable propagation process, and the pruning process, and then executes the conditional expression information propagation process for the output variable represented by the ternary expression. The following equation can be derived. Then, the process proceeds to step S12.

(Step S12)
The graph creation unit 103 creates a cause / result graph from the equation for the output variable derived by the equivalent conversion unit 102. Specifically, the graph creating unit 103 uses each input condition of the equation for the output variable as a node, and combines the values of the output variable by combining the OR symbol part, the AND symbol part, and the NOT symbol part as will be described later. Create a cause-result graph to understand the behavior of (output value). However, the graph creating means 103 creates a cause / result graph in which the nodes of the input conditional expression are combined by the OR symbol part, the AND symbol part, and the NOT symbol part from the equation for the output variable as described above. Therefore, it is desirable that the equivalent conversion unit 102 converts an equation expressed using a ternary operator into an equation expressed using a logical operator. Details of the procedure for creating the cause-result graph from the equation for the output variable by the graph creating means 103 will be described later. Then, the process proceeds to step S13.

(Step S13)
The table conversion unit 104 converts the cause / result graph created by the graph creation unit 103 into a decision table. Specifically, the table conversion unit 104 determines how the value (output value) of the output variable is different for each combination of values of the input condition (node of the input condition in the cause / result graph) for the above-described output variable. Create a decision table that tabulates whether to take a value. Details of the conversion procedure from the cause / result graph to the decision table by the table conversion means 104 will be described later. Then, the specification extraction operation ends.

  FIG. 10 is a diagram illustrating a sample of source code of a module that is a target of the specification extraction operation. FIG. 11 is a diagram illustrating processing for specifying an output variable for a module. FIG. 12 is a diagram for explaining an operation of executing constant propagation processing and input propagation processing for a module. FIG. 13 is a diagram for explaining an operation of executing a pruning process on a module. FIG. 14 is a diagram for explaining an operation of executing conditional expression information propagation processing for a module. FIG. 15 is a diagram for explaining an operation of obtaining an equation by executing conditional expression information propagation processing for a module. FIG. 16 is a diagram for explaining an operation of converting an equation represented by a ternary operator into an equation represented by a logical operator. FIG. 17 is a diagram illustrating an operation of setting an output variable as a temporary variable before executing the equivalent conversion process. With reference to FIGS. 10 to 17, an equivalent conversion process performed by the equivalent conversion unit 102 for a specific module will be described.

  The target module 20 shown in FIG. 10 is a specific sample code before executing the following equivalent conversion process. In FIG. 10, the source code of the target module 20 is described in C language, but the present invention is not limited to this, and any program language that can execute the above-described equivalent conversion process may be used.

  First, as shown in FIG. 11, the output variable specifying unit 101 specifies the updated global variable, that is, the output variable in the target module 20. As shown in FIG. 11, in the target module 20, a global variable 200 (“Output_data”) and a global variable 201 (“Global_status”) are declared as global variables. Since the global variable 201 is only referred to among the global variables (“sample_status1 = Global_status;”), the output variable specifying unit 101 determines that it is not an output variable but an input variable. The output variable specifying unit 101 specifies that the global variable 200 is an output variable because the global variable 200 is rewritten (updated) (for example, “Output_data = status2;”).

  As will be described later, the input condition sections 202 to 204 in the target module 20 are code sections that serve as input conditions in the equations for the output variables derived by the equivalent conversion means 102.

  Next, as shown in FIG. 12, since the constant “0” is assigned to the variable “status1” in the code unit 205, “status2 = status1 + 1;” can be replaced with “status2 = 1;”. Therefore, the equivalent conversion means 102 can replace the code part 205 of the target module 20 with the code part 210 after the constant propagation process by the constant propagation process.

  Further, since the constant “1” is assigned to the variable “status2”, the code parts 207a to 207c (“Output_data = status2;”) can be replaced with “Output_data = 1;”. Therefore, the equivalent conversion means 102 can replace the code portions 207a to 207c of the target module 20 with the post-constant propagation processing code portions 212a to 212c, respectively, by constant propagation processing.

  Since the constant “1” is assigned to the variable “status2”, the code part 208 (“if ((status2 == 0))”) indicating the conditional expression of the If statement is “if ((1 == 0)) ”. Therefore, the equivalent conversion means 102 can replace the code portion 208 of the target module 20 with the post-constant propagation processing code portion 213 by constant propagation processing.

  Also, since the input variable “Global_status” is input to the variable “sample_status1” in the code unit 206, “sample_status2 = sample_status1 + 1;” can be replaced with “sample_status2 = Global_status + 1;”. Therefore, the equivalent conversion means 102 can replace the code part 206 of the target module 20 with the post-input variable propagation process code part 211 by the input variable propagation process.

  As described above, the equivalent conversion unit 102 converts the target module 20 into the post-processing module 21 by the constant propagation process and the input variable propagation process.

  Next, as shown in FIG. 13, in the code part 214 which is a branch condition expression, the condition part corresponding to the code part 213 after constant propagation processing shown in FIG. 12 is “1 == 0”, so “Output_data” = 1; "is never executed. Therefore, the equivalent conversion means 102 can replace the code part 214 of the post-processing module 21 with the post-pruning code part 220 (no code) by the pruning process.

  As described above, the equivalent conversion unit 102 converts the processed module 21 into the processed module 22 by the pruning process.

  Next, as shown in FIG. 14, the code part 221 which is a conditional branching expression can be replaced with a ternary expression using a ternary operator. That is, the equivalent conversion unit 102 converts the code part 221 of the post-processing module 22 into the post-conditional expression information post-processing code part 230 (“Output_data = (! (Sample_varialbe2 == 1) by the conditional expression information propagation process. ) && sample_flags == 1)? 1: 0; ”).

  As described above, the equivalent conversion unit 102 converts the post-processing module 22 into the post-processing module 23 by the conditional expression information propagation processing.

  Next, as shown in FIG. 15, the code part 231 which is a conditional branching expression can be replaced with a ternary expression using a ternary operator. That is, the equivalent conversion unit 102 converts the code part 231 of the post-processing module 23 into a post-conditional expression information propagation post-processing code part 240 (“Output_data = sample_variable1> 61? 1 :() by conditional expression information propagation processing. (! (Sample_variable2 == 1) && sample_flags == 1)? 1: 0); ").

  As described above, the equivalent conversion unit 102 converts the post-processing module 23 into the post-processing module 24 by the conditional expression information propagation processing. The converted equation of the post-condition information transmission processing code unit 240 of the post-processing module 24 becomes an equation for the output variable derived by the equivalent conversion means 102. However, as described above, the cause / result graph of the post-process is created by the graph creation unit 103 by combining the nodes of the input conditional expression by the OR symbol part, the AND symbol part, and the NOT symbol part. Therefore, as shown in FIG. 16, the equivalent conversion unit 102 expressed the expressed equation using the ternary operator shown in the derived conditional expression information propagation post-processing code unit 240 using the logical operator. The equation 241 (“Output_data = (sample_variable1> 61) ||! (Sample_variable1> 61) &&! (Sample_variable2 == 1) && sample_flags == 1”) is converted. That is, the equation 241 is an equation for the output variable finally derived by the equivalent conversion means 102.

  As described above, the module source code can be reduced by the equivalent conversion process (constant propagation process, input variable propagation process, pruning process, and conditional expression information propagation process) by the equivalent conversion unit 102, thereby reducing the module source code. An equation for the reduced output variable can be derived.

  If there is no expression to be calculated using the output variable in the module source code, the equation for the output variable may be deleted by the pruning process in the equivalent conversion process by the equivalent conversion means 102. is there. In this case, as shown in the temporary variable setting code section 250 of the target module 25 in FIG. 17, the output variables (“V1”, “V2” and “V3” in FIG. 17) specified by the output variable specifying unit 101 are Substitution processing may be executed for temporary variables (“tmp_V1”, “tmp_V2”, and “tmp_V3” in FIG. 17). As a result, when the equivalent conversion means 102 converts the target module 25 to the post-equivalent conversion module 26, the temporary variable setting code unit 250 converts into an equation code unit 260 that is an equation for the temporary variable (substantially an output variable). It is possible to prevent the equation from being deleted.

  FIG. 18 is a diagram for explaining the operation of deriving an intermediate cause / result graph from the logical expression of the input condition of the equation by the OR symbol part and the AND symbol part. FIG. 19 is a diagram for explaining an operation of deriving a final cause / result graph from the intermediate cause / result graph by integrating the NOT symbol part and the nodes of the same expression. The creation of the cause / result graph by the graph creation means 103 will be described with reference to FIGS.

  First, as shown in FIG. 18, the graph creating unit 103 extracts the right side of the equation 241 shown in FIG. 16 derived by the equivalent conversion unit 102 (an expression in which input conditions are combined with a logical operator). Since the priority of operations increases in the order of the OR operator (“||”), the AND operator (“&&”), and the NOT operator (“!”), The graph creating means 103 is coupled by the OR operator. Each input condition is extracted, and each node is connected by the OR symbol unit 60 shown in FIG. 18 with each input condition as a node. Specifically, the graph creating unit 103 inputs the input conditions “sample_variable1> 61” and “! (Sample_variable1> 61) &&! (Sample_variable2 == 1) && sample_flags == 1 ”are coupled by the OR symbol part 60 as nodes 40 and 41, respectively. The result of the OR operation between the node 40 and the node 41 becomes the output value, and the graph creating unit 103 couples the output side of the OR symbol part 60 and the output value node 70 indicating the output value.

  Next, the graph creation means 103 extracts the input conditions combined by the AND operator in the input conditions of each generated node, sets each input condition as a new node, and sets each node to the AND shown in FIG. The symbols 61 are combined. Specifically, the graph creating unit 103 includes input conditions “! (Sample_variable1> 61)”, “! (Sample_variable2 == 1)” and “sample_flags ==” which are combined with an AND operator among the input conditions of the node 41. 1 ”are coupled by the AND symbol part 61 as nodes 42 to 44, respectively. Then, the graph creating unit 103 couples the output side of the AND symbol part 61 with the OR symbol part 60.

  Next, as illustrated in FIG. 19, the graph creating unit 103 extracts the input condition including the NOT operator in the generated input condition of each node, and sets the input condition from which the NOT operator is removed as a new node. The node is combined with the NOT operator shown in FIG. Specifically, since the NOT operator is included in the input condition “! (Sample_variable1> 61)” of the node 42, the graph creating unit 103 sets the input condition “sample_variable1> 61” from which the NOT operator is removed as a new node. Is a node 42a. Then, the graph creating means 103 couples the node 42a to the AND symbol portion 61 via the NOT symbol portion 62a. Further, since the NOT condition is included in the input condition “! (Sample_variable2 == 1)” of the node 43, the graph creating unit 103 sets the input condition “sample_variable2 == 1” from which the NOT operator is removed as a new node. A node 43a is assumed. Then, the graph creating means 103 couples the node 43a to the AND symbol portion 61 via the NOT symbol portion 62b.

  Next, the graph creating unit 103 unifies the nodes having the same input condition into one node among the nodes generated so far. Specifically, the graph creating unit 103 unifies the node 40 and the node 42a into one node 45 because the input conditions of the node 40 and the node 42a are “sample_variable1> 61” and the same expression.

  As described above, the graph creating unit 103 combines the input conditions included in the right side from the equation 241 derived from the equivalent conversion unit 102 as nodes in the OR symbol part, the AND symbol part, and the NOT symbol part, and inputs the same expression. A cause / effect graph is created by unifying the conditions into one node.

  As described above, the graph creating unit 103 extracts the input condition in the equation of the output variable, and combines the extracted input condition as a node by using logical symbols (OR symbol part, AND symbol part, and NOT symbol part), A common node is integrated. As a result, a reduced cause-result graph can be created from the equation for the output variable derived by the equivalent conversion means 102.

  FIG. 20 is a diagram for explaining the operation of creating a decision table from the cause / result graph. The conversion from the cause / result graph to the decision table by the table conversion means 104 will be described with reference to FIG.

  As shown in FIG. 20, the table conversion unit 104 converts the cause / result graph created by the graph creation unit 103 into a decision table 50. There are various formats for the decision table. In this embodiment, as in the decision table 50 shown in FIG. 20, each column of “input” indicating an input condition and “output” indicating an output variable are provided. A table composed of However, the format of the decision table is not limited to the above.

  Specifically, the table conversion unit 104 first describes the input conditions of all the nodes in the cause / result graph created by the graph creation unit 103 in the “input” (input condition) column of the table. In FIG. 20, “sample_variable1> 61”, “sample_variable2 == 1”, and “sample_flags = 1” are described as input conditions. Then, the table conversion unit 104 describes the output variable in the “output” (output variable) column of the table. In FIG. 20, “Output_data” is described as an output variable.

  Next, based on the cause / result graph, the table conversion unit 104 determines whether each output condition is a true value “T” (true) or a false value “F” (false). The correspondence relationship between “1” and “0”, which are possible values, is described.

  If the input condition “sample_variable1> 61” is a true value “T”, the output value is “1” regardless of whether the input conditions “sample_variable2 == 1” and “sample_flags == 1”. It becomes. Accordingly, the table conversion unit 104 describes a correspondence relationship in which the output value is “1” when the input condition “sample_variable1> 61” is a true value “T”. At this time, the fields of the input conditions “sample_variable2 == 1” and “sample_flags == 1” in the table are blank.

  Further, from the cause / result graph, if the input condition “sample_variable1> 61” is a false value “F” and the input condition “sample_flags == 1” is a true value “T”, the truth / false of the input condition “sample_variable2 == 1”. Depending on the output value. That is, when the input condition “sample_variable2 == 1” is a false value “F”, the output value is “1”, and when the input condition is “T”, the output value is “0”. Therefore, the table conversion unit 104 includes a table in which the input condition “sample_variable1> 61” is the false value “F”, “sample_variable2 == 1” is the false value “F”, and “sample_flags == 1” is the true value “T”. In the case of “”, the correspondence relationship in which the output value is “1” is described. Further, the table conversion means 104 stores the input condition “sample_variable1> 61” in the table as a false value “F”, “sample_variable2 == 1” as a true value “T”, and “sample_flags == 1” as a true value “T”. ", A correspondence relationship in which the output value is" 0 "is described.

  In addition, if the input conditions “sample_variable1> 61” and “sample_flags = 1” are false values “F”, the output value is “regardless of whether the input conditions“ sample_variable2 == 1 ”are true or false. 0 ". Therefore, the table conversion unit 104 describes a correspondence relationship in which the output value is “0” when the input conditions “sample_variable1> 61” and “sample_flags == 1” are false values “F”. At this time, the column of the input condition “sample_variable2 == 1” in the table is blank.

  With the above operation, the table conversion unit 104 converts the cause / result graph created by the graph creation unit 103 into a decision table 50 shown in FIG. As described above, the table conversion unit 104 generates the cause / result graph reduced by the graph generation unit 103 from the reduced output variable equation derived by the equivalent conversion unit 102 and reduces the reduced result. Based on the cause / result graph, the decision table 50 is converted. As a result, a compact decision table composed of a combination of optimized input conditions can be obtained from the cause / result graph created by the graph creation means 103.

  Note that the above-described method for generating a decision table from the source code is an example, and the present invention is not limited to this. The decision table may be generated by other methods.

  FIG. 21 is a diagram for explaining an overview of an operation for creating a verification code from the decision table of the verification apparatus according to the first embodiment. With reference to FIG. 21, an outline of the flow of the equivalence checking operation of the PC 1, which is the verification device according to the present embodiment, will be described.

  As shown in FIG. 21, in the verification target source code 80, it is assumed that a decision table 81, which is specification information, is generated by the specification extraction unit 100 as described above. Next, the code generation unit 151 of the equivalence verification unit 150 extracts lines indicating the true / false values of the input conditions of the decision table 81 (hereinafter referred to as input condition lines), and the preceding stage of the verification target source code 80. On the side, a code (pre-condition unit 82) that defines the input condition of the input condition line is set. In addition, the code generation unit 151 extracts the value (output value) of the output variable corresponding to the input condition line extracted from the decision table 81, and the code (post facto) specifying the output value on the subsequent stage side of the verification target source code 80 The condition part 83) is set. As described above, the code generation unit 151 generates the verification code 84 including the precondition unit 82, the verification target source code 80, and the postcondition unit 83.

  Next, the code generation unit 151 outputs the generated verification code 84 to the verification tool 85 (corresponding to the verification unit 152 in FIG. 2). The verification tool 85 to which the verification code 84 has been input analyzes the verification code 84 and executes the verification target source code 80, and when the input condition set by the code generation unit 151 is satisfied, the set output It is verified whether it becomes a value. Then, the verification tool 85 outputs a verification result (OK / NG determination).

  FIG. 22 is a flowchart illustrating an example of the equivalence checking operation of the verification device according to the first embodiment. FIG. 23 is a diagram illustrating an example of setting the precondition and postcondition codes in the verification code. FIG. 24 is a diagram illustrating another example in which a precondition code and a postcondition code are set in the verification code. The details of the flow of the equivalence checking operation of the PC 1 that is the verification device will be described with reference to FIGS. In FIG. 22, the decision table is described as “DT” for simple description.

(Step S21)
The code generation unit 151 of the equivalence verification unit 150 stores the source code (verification target source code) that is the target of the specification extraction operation and the verification target of the equivalence stored in the first storage unit 161 of the storage unit 160. Read and input. Further, the code generation unit 151 reads and inputs the decision table generated by the specification extraction operation for the verification target source code stored in the second storage unit 162 of the storage unit 160. 23, for example, the function “func01” of the verification target source code performs the verification operation of the equivalence with the decision table 90 that is the specification information. That is, the decision table 90 is a decision table for the output variable “z” included in the function “func01”.

  As illustrated in FIG. 23, the code generation unit 151 includes the header file “func01.h” for using the function “func01” in the verification code 91 in order to set the function “func01” as a verification target. Add the code for the third line. Next, the code generation unit 151 adds a code for making an “extern” declaration (prototype declaration) in order to call the function “func01” in which the source code is described in an external file in the verification code 91. Add to Then, the code generation unit 151 simply adds a function “cprover_main” (no argument / return value) for executing the function “func01” to the 13th line, and executes the function “func01” by executing the code “func01 ( ); ”(Hereinafter referred to as execution code) is added to the 19th line. The function name for simply executing the function “func01” is an example and may be an arbitrary function name.

  The code generation unit 151 reads the source code from the first storage unit 161 and inputs it. However, the present invention is not limited to this, and the source code directly input by the user via the operation unit 12 is not limited thereto. It is good also as what inputs.

(Step S22)
The pre-condition setting unit 151a of the code generation unit 151 extracts (extracts) input condition lines line by line from the decision table 90. Specifically, as shown in FIG. 23, for example, a line extracted by the precondition setting unit 151a is set as an input condition line 900.

  Further, the post-condition setting unit 151b of the code generation unit 151 extracts (extracts) the value (output value) of the output variable corresponding to the input condition line extracted by the pre-condition setting unit 151a from the decision table 90. Specifically, as shown in FIG. 23, for example, the value of the output variable extracted by the post-condition setting unit 151b is set as the output value 901. Then, the process proceeds to step S23.

(Step S23)
The precondition setting unit 151a generates, as a precondition, a code that defines the true / false value of the input condition in the extracted input condition line. For example, the input condition row 900 illustrated in FIG. 23 indicates that the input condition “g1> 100” is a true value (T) and the input condition “g2 == 0” is a false value (F). Therefore, the precondition setting unit 151a generates “__COVER_assume ((g1> 100) &&! (G2 == 0));” as a code that defines the truth value of the input condition in the input condition row. This code of “__COVER_assume ();” indicates that the input condition “g1> 100” is a true value and the input condition “g2 == 0” is a false value when the input condition is true or false. This is the code to specify.

  The post-condition setting unit 151b generates a code that defines the extracted output value as a post-condition. For example, when the output value 901 shown in FIG. 23 satisfies the true / false value of the input condition row 900, it indicates that the value of the output variable “z” is “0”. Therefore, the post-condition setting unit 151b generates “__COVER_assert (z == (0));” as a code that defines the output value. The code of “__COVER_assert (z == (0));” is the case of the truth value of the input condition indicated by the input condition line 900, and when the function “func01” is executed, the output variable (FIG. In 23, “z”) is a code for designating a value to be taken. Then, the process proceeds to step S24.

(Step S24)
The precondition setting unit 151a uses the generated “__COVER_assume ((g1> 100) &&! (G2 == 0));” as the precondition setting code 910 in the preceding stage of the execution code in the verification code 91 (FIG. 23). Now add it to the 16th line). Further, the precondition setting unit 151a uses a code “for declaring a type using an undefined function“ nondet () ”in the verification code 91 in order to set the variables“ g1 ”and“ g2 ”to undefined values. int g1 = nondet (); "and" int g2 = nondet (): "are added respectively. This is based on the specification of the C language, and it is not necessary to add it if it is not necessary for other languages.

  The post-condition setting unit 151b uses the generated “__COVER_assert (z == (0));” as the post-condition setting code 911 on the rear side of the execution code in the verification code 91 (the 22nd line in FIG. 23). Append. Further, the post-condition setting unit 151b uses a code “intz1 = nondet” for performing type declaration using the undefined function “nondet ()” in the verification code 91 in order to set the output variable “z” to an indefinite value. (); "Is added. This is based on the specification of the C language, and it is not necessary to add it if it is not necessary for other languages.

  Note that although “nondet ()” is used as the undefined function, it is a tentative function, and any function may be used as long as it is an undefined function.

  That is, the code generation unit 151 is based on the verification target source code, the precondition setting code 910 generated by the precondition setting unit 151a, the postcondition setting code 911 generated by the postcondition setting unit 151b, and the like. Then, the verification code 91 is completed (generated). Then, the process proceeds to step S25.

(Step S25)
The verification unit 152 of the equivalence verification unit 150 inputs the verification code generated by the code generation unit 151 (the verification code 91 in FIG. 23). Then, the verification unit 152 executes the input verification code, thereby verifying the source code to be verified (specifically, the function “func01” shown in FIG. 23) and the decision table ( In FIG. 23, an operation for verifying equivalence with the decision table 90) is performed.

  In the example of FIG. 23, when executing the verification code 91, the verification unit 152 indicates that “g1> 100” is a true value by “_CPROVER_assume ((g1> 100) &&! (G2 == 0));”. In addition, assuming that “g2 == 0” is a false value, the function “func01” is executed. Then, when the function “func01” is executed, the verification unit 152 determines whether or not the output variable “z” is the output value “0” designated by “__COVER_assert (z == (0));”. Judgment is made. Then, the process proceeds to step S26.

(Step S26)
The result output unit 153 of the equivalence verification unit 150 outputs a verification result of the equivalence verification operation performed for each input condition line of the decision table to the verification target source code by the verification unit 152. For example, the result output unit 153 may output the verification result as data, store it in the storage unit 14 and save it, or display the verification result on the display unit 13.

  The processes in steps S22 to S26 described above are performed for all input condition rows in the decision table (in FIG. 23, decision table 90). Thereafter, the process proceeds to step S27.

(Step S27)
The verification unit 152 performs an operation of verifying the equivalence between the verification target source code and the decision table for all input condition rows in the decision table and the corresponding output values, and then inputs the verification result as a determination NG. It is determined whether or not there is even one conditional row. When there is no input condition line whose verification result is determined to be NG (step S27: No), the process proceeds to step S28, and when it exists (step S27: Yes), the process proceeds to step S29.

(Step S28)
The verification unit 152 determines that the decision table and the verification target source code are equivalent if there is no input condition line that is judged NG in the decision table as a result of the equivalence verification operation. The verification unit 152 sends this determination result (verification result) to the result output unit 153. Then, the process proceeds to step S30.

(Step S29)
The verification unit 152 determines that the decision table and the verification target source code are not equivalent when there is at least one input condition line that is judged NG in the decision table as a result of the equivalence verification operation. The verification unit 152 sends this determination result (verification result) to the result output unit 153. Then, the process proceeds to step S30.

(Step S30)
The result output unit 153 outputs the verification result of the equivalence verification operation for the verification target source code by the verification unit 152. For example, the result output unit 153 may output the verification result as data, store it in the storage unit 14 and save it, or display the verification result on the display unit 13. Then, the equivalence checking operation ends.

  In the above-described decision table 90 shown in FIG. 23, the output values are all assumed to have specific values. However, as in the decision table 90a shown in FIG. 24, the output value of the output variable “z” is an invariant value. (In this case, it is described as “z”). In this case, the precondition setting unit 151a extracts the input condition row 900a from the decision table 90a, and uses “__COVER_assume ((g1> 100) &&! (G2 == 0) as a code that defines the truth value of the input condition. )); ”Is generated, and this code is added to the verification code 91a as the precondition setting code 910a, and the operation is the same as the input condition line 900 and the precondition setting code 910 described above.

  On the other hand, when verifying whether or not the output variable “z” is an invariant value, that is, whether or not the value of the output variable “z” does not change before and after the execution of the function “func01”, the function “func01” It is necessary to acquire the value of the output variable “z” before the execution of. Therefore, the post-condition setting unit 151b stores 15 lines of the verification code 91a as shown in FIG. 24 in order to save the value of the output variable “z” before execution of the function “func01” in the temporary variable “z_tmp”. Add a code of “int z_tmp = z;” to the eyes. Then, the post-condition setting unit 151b extracts an output value 901a that is the value (invariant value) of the output variable corresponding to the input condition row 900a extracted by the pre-condition setting unit 151a. Then, the post-condition setting unit 151b generates “__COVER_assert (z == z_tmp);” as a code that defines the output value 901a of the invariant value. The code of “__COVER_assert (z == z_tmp);” is a case of the truth value of the input condition indicated by the input condition line 900a, and the output variable “z” is set when the function “func01” is executed. This code verifies whether or not it remains unchanged. Then, the post-condition setting unit 151b uses the generated “__COVER_assert (z == z_tmp);” as the post-condition setting code 911a on the subsequent stage side (the 24th line in FIG. 24) of the execution code in the verification code 91a. Append.

  As a result, even if an invariant value is included as the output value of the output variable, it is possible to verify whether or not the output variable is invariant even after execution of the verification target source code (function).

  In FIG. 23 described above, the source code to be verified is described in an external file, and an extern declaration is performed to call a function that is the target of the equivalence verification operation described in the external file. However, the present invention is not limited to this. For example, in the verification code 91 shown in FIG. 23, the code itself (execution code) in which the function of the verification target source code is described may be described instead of “func01 ();” on the 19th line.

  As described above, the verification apparatus (PC1) according to the present embodiment generates a decision table for the verification target source code by the specification extraction operation by the specification extraction unit 100, and the equivalence verification operation by the equivalence verification unit 150. Thus, whether or not the decision table and the verification target source code are equivalent is verified. Thereby, whether or not the decision table generated by the specification extracting operation by the specification extracting means 100 is equivalent to the original source code (verification target source code), that is, the generated decision table is used as the specification information of the source code. It is possible to verify whether the information is accurate.

  The code generation unit 151 generates the verification code based on the code generated from the input condition line and the output value of the decision table without editing the verification target source code. As a result, it is not necessary to write comments for generating verification code for the verification target source code, and verification code can be automatically generated, so the verification source code and the decision table are equivalent. Verification can be performed efficiently.

  The input information to the equivalence verification unit 150 is a decision table in which input conditions and output values are structured. Thus, the verification operation of the equivalence between the specification information (decision table) and the source code by the verification unit 152 can be performed efficiently.

  As shown in FIG. 2, the specification extracting unit 100 and the equivalence checking unit 150 are both included in the PC 1, but the present invention is not limited to this. For example, the apparatus having the specification extracting unit 100 and the apparatus having the equivalence verifying unit 150 may be separate devices, and these devices may constitute a verification system that implements the operation of the above-described embodiment as a whole. . In this case, the data of the decision table generated by the apparatus having the specification extracting means 100 is transmitted to the apparatus having the equivalence verifying means 150 by the communication means (whether wired or wireless), and the equivalence verifying means 150 is The apparatus having the above may execute the equivalence checking operation using the data of the received decision table. Furthermore, the specification extraction unit 100 and the equivalence verification unit 150 are not limited to the configurations provided in different devices, and each unit included therein may be provided in a further device. For example, it is assumed that only the verification unit 152 of the equivalence verification unit 150 is provided in another device, and the equivalence verification operation based on the verification code generated by the code generation unit 151 is entrusted to a device having the verification unit 152. It may be configured as follows.

(Second Embodiment)
The PC 1 of the present embodiment will be described focusing on differences from the PC 1 of the first embodiment. In the first embodiment, the operation of verifying whether or not it is equivalent to the verification target source code using the decision table generated by the specification extraction unit 100 has been described. In the present embodiment, for example, an operation for verifying whether or not a decision table created by the user for the verification target source code and the verification target source code are equivalent will be described. Note that the hardware configuration and functional block configuration of the PC 1 of this embodiment are the same as those shown in FIGS. 1 and 2, respectively. In the following, differences from the first embodiment will be described, particularly regarding the functional block configuration.

  For example, the equivalence verification unit 150 is configured to determine whether the decision table created by the user himself or herself for the verification target source code (that is, the decision table created outside independently of the PC 1) and the verification target source code are equivalent. It is a functional part that verifies the characteristics. The equivalence verification unit 150 includes a code generation unit 151, a verification unit 152, and a result output unit 153. The functions of the code generation unit 151, the verification unit 152, and the result output unit 153 are the same as those in the first embodiment.

  The storage unit 160 is a functional unit that stores various programs executed by the control unit 16 and data used for various processes performed by the PC 1. The storage unit 160 includes a first storage unit 161 and a second storage unit 162.

  The first storage unit 161 is a functional unit that stores source code to be verified for equivalence. The second storage unit 162 is a functional unit that stores, for example, a decision table created by the user for the verification target source code as data.

  As described above, the verification apparatus (PC1) according to the present embodiment is not the decision table generated by the specification extraction unit 100 as in the first embodiment, but is generated by the user himself for the verification target source code, for example. The equivalence between the decision table and the source code to be verified is verified. As a result, whether the decision table created by the user himself is equivalent to the verification target source code, that is, the decision table created by the user himself is the specification information that accurately indicates the behavior of the verification target source code. It can be verified whether or not there is.

  Note that the PC 1 according to the present embodiment does not include the specification extraction unit 100 as long as it is specialized only in the operation of verifying the equivalence between the decision table created by the user and the source code to be verified. Good.

(Third embodiment)
The PC 1 of the present embodiment will be described focusing on differences from the PC 1 of the first embodiment. In the first embodiment, the operation of verifying whether or not it is equivalent to the verification target source code using the decision table generated by the specification extraction unit 100 has been described. In this embodiment, a specification extraction unit 100 generates a decision table for source code (hereinafter also referred to as legacy source code) before version upgrade (hereinafter also referred to as derivative development), and this decision table, The operation for verifying equivalence with the source code after derivation development will be described. Note that the hardware configuration and functional block configuration of the PC 1 of this embodiment are the same as those shown in FIGS. 1 and 2, respectively. In the following, differences from the first embodiment will be described, particularly regarding the functional block configuration.

  The equivalence verification unit 150 is a functional unit that verifies the equivalence between the decision table generated by the specification extraction operation by the specification extraction unit 100 and the source code derived and developed from the source code subjected to the specification extraction operation. is there. In this case, the verification target source code is a source code derived and developed from the source code subjected to the specification extraction operation. The equivalence verification unit 150 includes a code generation unit 151, a verification unit 152, and a result output unit 153. The functions of the code generation unit 151, the verification unit 152, and the result output unit 153 are the same as those in the first embodiment.

  The storage unit 160 is a functional unit that stores various programs executed by the control unit 16 and data used for various processes performed by the PC 1. The storage unit 160 is realized by the storage unit 14 shown in FIG. The storage unit 160 includes a first storage unit 161 and a second storage unit 162.

  The first storage means 161 is a functional unit that stores the legacy source code that is the target of the specification extraction operation and the verification target source code that is derived and developed from the source code. The second storage unit 162 is a functional unit that stores, as data, the decision table generated by the specification extraction unit 100 for the legacy source code before the derivative development.

  FIG. 25 is a diagram for explaining the outline of the operation for creating the verification code from the decision table of the verification apparatus according to the third embodiment. With reference to FIG. 25, the flow of an equivalence verification operation of the PC 1 that is the verification apparatus according to the present embodiment will be described.

  As shown in FIG. 25, the verification target source code 80a is a source code derived and developed from the legacy source code 86. First, the specification extraction unit 100 generates a decision table 81 a that is specification information for the legacy source code 86. Next, the code generation unit 151 of the equivalence verification unit 150 extracts lines indicating the true / false values of the input conditions of the decision table 81a (hereinafter referred to as input condition lines), and the preceding stage of the verification target source code 80a. On the side, a code (precondition part 82a) that defines the input condition of the input condition line is set. In addition, the code generation unit 151 extracts the value (output value) of the output variable corresponding to the input condition line extracted from the decision table 81a, and the code (post facto) that defines the output value at the subsequent stage side of the verification target source code 80a. The condition part 83a) is set. As described above, the code generation unit 151 generates the verification code 84a including the precondition unit 82a, the verification target source code 80a, and the postcondition unit 83a.

  Next, the code generation unit 151 outputs the generated verification code 84a to the verification tool 85 (corresponding to the verification unit 152 in FIG. 2). The verification tool 85 to which the verification code 84a has been input analyzes the verification code 84a and executes the verification target source code 80a, and when the input condition set by the code generation means 151 is satisfied, the set output It is verified whether it becomes a value. Then, the verification tool 85 outputs a verification result (OK / NG determination). Note that the details of the above-described equivalence checking operation conform to the operation content described in FIGS. 22 to 24 in the first embodiment.

  As described above, the verification apparatus (PC1) according to the present embodiment causes the specification extraction unit 100 to generate a decision table for the legacy source code before the derivative development, and the decision table and the source after the derivative development It is assumed that the operation of verifying equivalence with code is performed. As a result, it is possible to grasp how the operation specifications of the legacy source code and the source code that is derived and developed differ from the verification result of the equivalence verification unit 150. In addition, there are some code parts that should not be changed as functions even if they are developed from legacy source code. In this case, according to the verification apparatus according to the present embodiment, a function that should not be changed is maintained by performing an operation for verifying equivalence between the decision table generated from the legacy source code and the source code that is derived and developed. It can be confirmed whether or not.

  Note that the decision table 81a generated from the legacy source code 86 is edited by the user for the verification target source code 80a, and the equivalence verification operation between the decision table and the verification target source code 80a is performed. Accordingly, it is possible to confirm whether or not the decision table created by the user is specification information that accurately defines the behavior of the verification target source code 80a. Conversely, the user himself / herself can check whether or not the verification target source code 80a operates according to the specification of the decision table obtained by editing the decision table 81a for the verification target source code 80a.

  The equivalence verification unit 150 verifies the equivalence between the decision table generated by the specification extraction operation by the specification extraction unit 100 and the source code derived and developed from the source code subjected to the specification extraction operation. However, the present invention is not limited to this. For example, the equivalence verification unit 150 includes a decision table generated by performing a specification extraction operation on the source code derived and developed by the specification extraction unit 100, and a source code (legacy source code) before the derivation development. The equivalence may be verified. Also according to this, it is possible to grasp how the operation specifications of the legacy source code and the source code derived and derived are different from the verification result of the equivalence verification unit 150.

  The program executed by the PC 1 according to each embodiment described above is provided by being incorporated in advance in a ROM or the like. The program executed by the PC 1 according to each of the above-described embodiments is a file in an installable format or an executable format, and is a CD-ROM (Compact Disk Read Only Memory), a flexible disk (FD), a CD-R ( It may be configured to be stored in a computer-readable storage medium such as a Compact Disk Recordable (DVD) or a DVD (Digital Versatile Disk) and provided as a computer program product.

  Furthermore, the program executed by the PC 1 according to each of the above-described embodiments may be provided by being stored on a computer connected to a network such as the Internet and downloaded via the network. The program executed on the PC 1 according to each of the above embodiments may be provided or distributed via a network such as the Internet.

  In addition, the program executed by the PC 1 of each of the above-described embodiments can cause a computer to function as each functional unit of the PC 1 described above. In this computer, the CPU (control unit 16) can read and execute a program from a computer-readable storage medium onto a main storage device.

  Although the embodiments of the present invention have been described, these embodiments are presented as examples, and are not intended to limit the scope of the invention. Each of the novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the spirit of the invention. These embodiments are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalents thereof.

1 PC
11 Communication Unit 12 Operation Unit 13 Display Unit 14 Storage Unit 15 External Storage Device 16 Control Unit 17 CD-ROM
18 CD-ROM drive 19 Bus 20 Target module 21-24 Module after processing 25 Target module 26 Module after equivalent conversion 30, 30a-30c Sample code 31 Code after constant propagation processing 31a Code after input variable propagation processing 31b Code after pruning processing 31c Code after conditional expression information propagation processing 40-45 Node 42a, 43a Node 50 Decision table 60 OR symbol part 61 AND symbol part 62a, 62b NOT symbol part 70 Output value node 80, 80a Verification target source code 81, 81a Decision table 82 , 82a Precondition section 83, 83a Postcondition section 84, 84a Verification code 85 Verification tool 86 Legacy source code 90, 90a Decision table 91, 91a Verification code 100 Specification extractor Stage 101 Output variable identification means 102 Equivalent conversion means 103 Graph creation means 104 Table conversion means 150 Equivalence verification means 151 Code generation means 151a Precondition setting means 151b Postcondition setting means 152 Verification means 153 Result output means 160 Storage means 161 First Storage unit 162 Second storage unit 200, 201 Global variable 202-204 Input condition part 205, 206, 207a-207c, 208 Code part 210 Code part after constant propagation process 211 Code part after input variable propagation process 212a-212c, 213 Constant Code part after propagation process 214 Code part 220 Code part after pruning process 221 Code part 230 Code part after conditional expression information propagation process 231 Code part 240 Code part after conditional expression information propagation process 241 Equation 250 Temporary variable setting code 260 code part 300a, 301a code part 300b, 301b code part 300c code part 310-312 code part after constant propagation process 310a code part after input variable propagation process 310b code part 310p after pruning process Code information post-processing part 900, 900a Input condition line 901, 901a Output value 910, 910a Precondition setting code 911, 911a Postcondition setting code

Claims (12)

Table generation means for generating a decision table indicating a value corresponding to an input condition of an output variable included in the source code from the source code;
From the decision table showing the value of the output variable in accordance with the input conditions, extracts the combination of the authenticity of the value of the input condition, a first generation means for generating a first code defining said combination,
Second generation means for extracting a value of the output variable corresponding to the combination extracted by the first generation means from the decision table and generating a second code defining the value of the output variable;
It said first code, added in the preceding stage of the execution code for executing the source code, the second code, and code generation means for generating a verification code by adding the subsequent stage of said execution code ,
A verification means for verifying equivalence between the decision table and the source code by executing the verification code;
Equipped with a,
The table generating means includes
Identifying means for identifying the output variable from the source code;
First conversion means for deriving an equation for the output variable specified by the specifying means by executing equivalent conversion processing for replacing an expression included in the source code with an equivalent expression;
Creating means for extracting the input condition from the equation and creating a cause-result graph having the input condition as a node;
Second conversion means for converting the cause / result graph into the decision table indicating a correspondence relationship between a combination of true / false values of the input condition and the value of the output variable;
A verification device having Table generation means for generating a decision table indicating a value corresponding to an input condition of an output variable included in the other source code from a source code different from the source code;
First generation means for extracting a combination of true and false values of the input condition from the decision table and generating a first code defining the combination;
Second generation means for extracting a value of the output variable corresponding to the combination extracted by the first generation means from the decision table and generating a second code defining the value of the output variable;
Code generating means for generating a verification code by adding the first code to a preceding stage of an execution code for executing the source code and adding the second code to a succeeding stage of the execution code; ,
A verification means for verifying equivalence between the decision table and the source code by executing the verification code;
With
The table generating means includes
Identifying means for identifying the output variable from the source code;
First conversion means for deriving an equation for the output variable specified by the specifying means by executing equivalent conversion processing for replacing an expression included in the source code with an equivalent expression;
Creating means for extracting the input condition from the equation and creating a cause-result graph having the input condition as a node;
Second conversion means for converting the cause / result graph into the decision table indicating a correspondence relationship between a combination of true / false values of the input condition and the value of the output variable;
A verification device having First generation means for extracting a combination of true and false values of the input condition from a decision table indicating values of output variables according to the input condition, and generating a first code defining the combination;
Second generation means for extracting a value of the output variable corresponding to the combination extracted by the first generation means from the decision table and generating a second code defining the value of the output variable;
Code generating means for generating a verification code by adding the first code to a preceding stage of an execution code for executing a source code, and adding the second code to a succeeding stage of the execution code;
A verification means for verifying equivalence between the decision table and the source code by executing the verification code;
With
The second generation means includes
If the extracted value of the output variable is an invariant value, a third code for storing the invariant value in a temporary variable is generated, and the third code is added to the preceding stage of the execution code included in the verification code And
The verification apparatus which produces | generates the said 2nd code which prescribes | regulates whether the value of the said output variable is the value of the said temporary variable. The first conversion means contracts the source code by executing loop processing of constant propagation processing, input variable propagation processing and pruning processing as the equivalent conversion processing, and the contraction of the source code has converged verification device according to claim 1 or 2 terminates the loop processing at this point. The verification apparatus according to claim 4 , wherein the first conversion unit executes conditional expression information propagation processing on the source code in which the contraction has converged. It said first converting means, as the equivalent transformation process, constant propagation process, the input variable propagation process, pruning process and condition information verification apparatus according to claim 1 or 2 executes the propagation process. The verification means determines whether or not the value of the output variable is output according to the input condition defined in the decision table when the source code is executed. The verification device according to any one of claims 1 to 3, wherein: The verification device according to any one of claims 1 to 3, wherein the decision table is created independently of the verification device. The second generation means includes
If the extracted value of the output variable is an invariant value, a third code for storing the invariant value in a temporary variable is generated, and the third code is added to the preceding stage of the execution code included in the verification code And
Verification device according to claim 1 or 2 to generate the second code value of the output variable defines whether the value of the temporary variable. Table generation means for generating a decision table indicating a value corresponding to an input condition of an output variable included in the source code from the source code;
First generation means for extracting a combination of true and false values of the input condition from the decision table indicating the value of the output variable according to the input condition, and generating a first code that defines the combination;
Second generation means for extracting a value of the output variable corresponding to the combination extracted by the first generation means from the decision table and generating a second code defining the value of the output variable;
Code generating means for generating a verification code by adding the first code to a preceding stage of an execution code for executing the source code and adding the second code to a succeeding stage of the execution code; ,
A verification means for verifying equivalence between the decision table and the source code by executing the verification code;
Equipped with a,
The table generating means includes
A specific means for identifying the output variable from the source code;
First conversion means for deriving an equation for the output variable specified by the specifying means by executing equivalent conversion processing for replacing an expression included in the source code with an equivalent expression;
Creating means for extracting an input condition from the equation and creating a causal result graph having the input condition as a node;
Second conversion means for converting the cause / result graph into a decision table indicating a correspondence relationship between a combination of true and false values of the input condition and the value of the output variable;
Having a verification system. A table generation step for generating a decision table indicating a value according to an input condition of an output variable included in the source code from the source code;
From the decision table showing the value of the output variable in accordance with the input conditions, it extracts the combination of the authenticity of the value of the input condition, a first generation step of generating a first code defining said combination,
A second generation step of extracting a value of the output variable corresponding to the extracted combination from the decision table and generating a second code defining the value of the output variable;
A code generation step of generating a verification code by adding the first code to a preceding stage of an execution code for executing a source code, and adding the second code to a succeeding stage of the execution code;
A verification step of verifying equivalence between the decision table and the source code by executing the verification code;
I have a,
The table generation step includes
A specifying step of specifying the output variable from the source code;
A first conversion step of performing an equivalent conversion process of replacing an expression included in the source code with an equivalent expression to derive an equation for the identified output variable;
A step of extracting the input condition from the equation and creating a cause-result graph having the input condition as a node;
A second conversion step of converting the cause / result graph into the decision table indicating a correspondence relationship between a combination of true / false values of the input condition and the value of the output variable;
A verification method comprising: Table generation means for generating a decision table indicating a value corresponding to an input condition of an output variable included in the source code from the source code;
From the decision table showing the value of the output variable in accordance with the input conditions, extracts the combination of the authenticity of the value of the input condition, a first generation means for generating a first code defining said combination,
Second generation means for extracting a value of the output variable corresponding to the combination extracted by the first generation means from the decision table and generating a second code defining the value of the output variable;
It said first code, added in the preceding stage of the execution code for executing the source code, the second code, and code generation means for generating a verification code by adding the subsequent stage of said execution code ,
A verification means for verifying equivalence between the decision table and the source code by executing the verification code;
Is realized on a computer ,
Further, as the table generating means,
Identifying means for identifying the output variable from the source code;
First conversion means for deriving an equation for the output variable specified by the specifying means by executing equivalent conversion processing for replacing an expression included in the source code with an equivalent expression;
Creating means for extracting the input condition from the equation and creating a cause-result graph having the input condition as a node;
Second conversion means for converting the cause / result graph into the decision table indicating a correspondence relationship between a combination of true / false values of the input condition and the value of the output variable;
A program for causing the computer to realize the above .

Images