WO2018154657A1 - 等価性検証装置および等価性検証プログラム - Google Patents

等価性検証装置および等価性検証プログラム Download PDF

Info

Publication number
WO2018154657A1
WO2018154657A1 PCT/JP2017/006598 JP2017006598W WO2018154657A1 WO 2018154657 A1 WO2018154657 A1 WO 2018154657A1 JP 2017006598 W JP2017006598 W JP 2017006598W WO 2018154657 A1 WO2018154657 A1 WO 2018154657A1
Authority
WO
WIPO (PCT)
Prior art keywords
function
verification
equivalence
path
source code
Prior art date
Application number
PCT/JP2017/006598
Other languages
English (en)
French (fr)
Inventor
三喜也 吉田
誠 磯田
一樹 米持
伊藤　益夫
まどか 馬場
玲哉 野口
Original Assignee
三菱電機株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三菱電機株式会社 filed Critical 三菱電機株式会社
Priority to EP17897365.7A priority Critical patent/EP3570173B1/en
Priority to US16/475,865 priority patent/US10915427B2/en
Priority to PCT/JP2017/006598 priority patent/WO2018154657A1/ja
Priority to JP2019500911A priority patent/JP6567212B2/ja
Publication of WO2018154657A1 publication Critical patent/WO2018154657A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3608—Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3648—Software debugging using additional hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3624—Software debugging by performing operations on the source code, e.g. via a compiler
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/72—Code refactoring

Definitions

  • the present invention relates to a technique for verifying equivalence between functions.
  • Refactoring is a technique for improving the quality of software by changing the internal configuration of the software without changing the logical operation content of the software. Refactoring involves source code changes. Therefore, there is a possibility that a problem occurs due to the change of the source code, and the logical operation content is changed unintentionally. Therefore, in software differential derivation development, verification before and after software change is required.
  • Non-Patent Document 1 discloses a technique related to “equivalence verification” for a source code generated using legacy code and Simulink. “Equivalent” means that the logical operation contents of the two source codes match, that is, the same output value is obtained for the same input value. “Equivalence verification” is to verify whether two source codes are equivalent.
  • Non-Patent Document 1 a call graph is generated for two source codes in order to express a calling relationship of functions included in the source code. Then, a call graph is used to perform association between functions having the same function name and calling relationship and equivalence verification in units of functions. Equivalence checking is performed in order from the end function. The equivalent condition is that when two source codes are executed for the same input value, the same output value is obtained with the two source codes. In the equivalence verification, it is comprehensively analyzed for all input values that the output values corresponding to the input values match in the two source codes, and the equivalence is determined in units of functions.
  • Patent Document 1 a tag representing the behavior is embedded in the source code for the branch destination block from the branch sentence. Then, the behavior to be verified is specified, and the range of values of variables (or expressions) for passing through the block to be verified is specified based on the tag embedded in the block and the specified behavior. By setting the range of the specified value as the verification range, only the source code related to the specific behavior can be verified.
  • Non-Patent Document 1 it is a condition that output values corresponding to input values are the same for all input values. Therefore, even when equivalence differs depending on the path that passes through the function, it is determined that the function is unequal. Therefore, there is a wide range for analyzing the cause that the function is determined to be unequal, and the time required for manual failure analysis cannot be reduced. For example, the equivalence between the function A X and the function A Y is determined. If certain conditions are met, the function A X In function B X is called, the function A Y in function B X equivalent functions B Y is called. Therefore, the function A X and the function A Y are equivalent when the specific condition is satisfied.
  • Non-Patent Document 1 Even if the specific condition is satisfied, it is determined that the specific condition is not equivalent if the specific condition is not satisfied but is not equivalent if the specific condition is not satisfied. Therefore, it is determined that the function A X and the function A Y are not equivalent.
  • Patent Document 1 when there are a large number of variables or when an expression is complicated, a range of values for passing through a specific block may not be uniquely determined. Therefore, the application range of Patent Document 1 is limited.
  • the object of the present invention is to make it possible to determine whether functions are partially equivalent.
  • the equivalence checking device of the present invention is An equivalence verification unit that determines whether the functions included in the corresponding pair are equivalent for each corresponding pair that is a pair of the function included in the source code before the change and the function included in the source code after the change.
  • An equivalence verification unit that determines whether the functions included in the corresponding pair are equivalent for each corresponding pair that is a pair of the function included in the source code before the change and the function included in the source code after the change.
  • For each non-equivalent correspondence pair is the correspondence pair a partial validation pair that includes a function that includes both an inequality path where an inequality function is called and a non-equivalence path where a inequality function is called?
  • FIG. 1 is a configuration diagram of an equivalence checking apparatus 100 according to Embodiment 1.
  • FIG. 5 is a flowchart of an equivalence checking method according to Embodiment 1.
  • FIG. 3 shows a source code 210 before change in the first embodiment.
  • FIG. 3 is a diagram showing changed source code 220 in the first embodiment.
  • FIG. 5 shows a call graph 231 before change in the first embodiment.
  • FIG. 5 shows a post-change call graph 232 according to the first embodiment.
  • FIG. 6 shows a function correspondence table 233 according to the first embodiment.
  • FIG. 5 shows an equivalence determination table 240 in the first embodiment.
  • 5 is a flowchart of verification processing (S140) in the first embodiment.
  • FIG. 5 shows a verification file 250 in the first embodiment.
  • FIG. 5 shows an equivalence determination table 240 in the first embodiment.
  • FIG. 5 shows an equivalence determination table 240 in the first embodiment.
  • FIG. 5 is a flowchart of partial equivalence verification (S200) in the first embodiment.
  • 5 is a flowchart of partial verification determination (S210) in the first embodiment.
  • 5 is a flowchart of partial verification (S220) in the first embodiment.
  • FIG. The figure which shows the equivalence determination table 240 (after step S232) in Embodiment 1.
  • FIG. The figure which shows the source code 210 before a change (after step S143) in Embodiment 1.
  • FIG. The figure which shows the source code 220 after a change in Embodiment 1 (after step S143).
  • FIG. 4 is a configuration diagram of an equivalence checking apparatus 100 according to Embodiment 2.
  • 10 is a flowchart of a path verification method according to the second embodiment.
  • the call graph 270 in Embodiment 2 is a diagram showing.
  • FIG. 1 The figure which shows the path
  • FIG. The figure which shows the path
  • Embodiment 1 FIG. A mode for determining whether functions are partially equivalent will be described with reference to FIGS.
  • the equivalence checking device 100 is a computer including hardware such as a processor 901, a memory 902, an auxiliary storage device 903, and an input / output interface 904. These hardwares are connected to each other via signal lines.
  • the processor 901 is an IC (Integrated Circuit) that performs arithmetic processing, and controls other hardware.
  • the processor 901 is a CPU (Central Processing Unit), a DSP (Digital Signal Processor), or a GPU (Graphics Processing Unit).
  • the memory 902 is a volatile storage device.
  • the memory 902 is also called main memory or main memory.
  • the memory 902 is a RAM (Random Access Memory).
  • Data stored in the memory 902 is stored in the auxiliary storage device 903 as necessary.
  • the auxiliary storage device 903 is a nonvolatile storage device.
  • the auxiliary storage device 903 is a ROM (Read Only Memory), a HDD (Hard Disk Drive), or a flash memory. Data stored in the auxiliary storage device 903 is loaded into the memory 902 as necessary.
  • the input / output interface 904 is a port to which an input device and an output device are connected.
  • the input / output interface 904 is a USB terminal
  • the input device is a keyboard and a mouse
  • the output device is a display.
  • USB is an abbreviation for Universal Serial Bus.
  • the equivalence verification device 100 includes software elements such as a call graph generation unit 110, a control unit 120, an equivalence verification unit 130, an identifier setting unit 140, a partial verification determination unit 150, and a partial verification unit 160.
  • a software element is an element realized by software.
  • the auxiliary storage device 903 includes an equivalence verification program for causing a computer to function as the call graph generation unit 110, the control unit 120, the equivalence verification unit 130, the identifier setting unit 140, the partial verification determination unit 150, and the partial verification unit 160. It is remembered.
  • the equivalence verification program is loaded into the memory 902 and executed by the processor 901.
  • the auxiliary storage device 903 stores an OS (Operating System). At least a part of the OS is loaded into the memory 902 and executed by the processor 901. That is, the processor 901 executes the equivalence checking program while executing the OS.
  • Data obtained by executing the equivalence checking program is stored in a storage device such as the memory 902, the auxiliary storage device 903, a register in the processor 901, or a cache memory in the processor 901.
  • the memory 902 functions as a storage unit 191 that stores data. However, another storage device may function as the storage unit 191 instead of the memory 902 or together with the memory 902.
  • the input / output interface 904 functions as a reception unit 192 that receives input. Further, the input / output interface 904 functions as a display unit 193 that displays an image or the like.
  • the equivalence verification apparatus 100 may include a plurality of processors that replace the processor 901.
  • the plurality of processors share the role of the processor 901.
  • the equivalence verification program can be stored in a computer-readable manner on a nonvolatile storage medium such as a magnetic disk, an optical disk, or a flash memory.
  • a nonvolatile storage medium such as a magnetic disk, an optical disk, or a flash memory.
  • a non-volatile storage medium is a tangible medium that is not temporary.
  • the operation of the equivalence verification apparatus 100 corresponds to an equivalence verification method. Further, the procedure of the equivalence verification method corresponds to the procedure of the equivalence verification program.
  • the reception unit 192 receives the source code before change and the source code after change.
  • the storage unit 191 stores the received source code before change and source code after change.
  • the source code before change is source code in the software before change.
  • the source code before change is a source code created conventionally.
  • the changed source code is a source code in the changed software.
  • the post-change source code is a source code obtained by performing refactoring based on the pre-change source code.
  • FIG. 3 shows the source code 210 before change.
  • the pre-change source code 210 is a specific example of the pre-change source code.
  • the pre-change source code 210 includes six functions (Func_F_x, Func_E_x, Func_D_x, Func_C_x, Func_B_x, Func_A_x).
  • FIG. 4 shows the changed source code 220.
  • the changed source code 220 is a specific example of the changed source code.
  • the changed source code 220 includes five functions (Func_E_y, Func_D_y, Func_C_y, Func_B_y, Func_A_y).
  • the colon and the three-point reader mean omitted.
  • step S110 the call graph generation unit 110 generates a pre-change call graph and a post-change call graph by analyzing the pre-change source code and the post-change source code.
  • the storage unit 191 stores a pre-change call graph and a post-change call graph.
  • the call graph before change is a call graph of the source code before change.
  • the changed call graph is a call graph of the changed source code.
  • the call graph is data indicating a call relationship between functions, and can be generated by a conventional technique.
  • the call graph generation unit 110 generates an unchanged call graph by executing egpt with the unmodified source code as an input.
  • the call graph generation unit 110 generates an after-change call graph by executing egypt with the changed source code as an input.
  • egypt is an existing tool for generating a call graph.
  • FIG. 5 shows a pre-change call graph 231.
  • the pre-change call graph 231 is a pre-change call graph obtained by executing egypt with the pre-change source code 210 of FIG. 3 as an input.
  • the pre-change call graph 231 indicates that Func_A_x calls Func_B_x and Func_C_x, Func_B_x calls Func_D_x and Func_E_x, and Func_C_x calls Func_F_x.
  • FIG. 6 shows the post-change call graph 232.
  • the post-change call graph 232 is a post-change call graph obtained by executing egpt with the post-change source code 220 of FIG. 4 as an input.
  • the post-change call graph 232 indicates that Func_A_y calls Func_B_y and Func_C_y, and Func_B_y calls Func_D_y and Func_E_y.
  • step S120 the reception unit 192 receives a function correspondence table. Then, the storage unit 191 stores the accepted function correspondence table.
  • the function correspondence table is data indicating the correspondence between the pre-change function and the post-change function.
  • the pre-change function is a function included in the pre-change source code.
  • the post-change function is a function included in the post-change source code.
  • the function correspondence table shows a correspondence relationship between the function before change and the function after change in the reverse call order of the function before change or the function after change.
  • the reverse call order is the reverse order of the call order.
  • the calling order is the order from the upper level to the lower level in the calling relationship.
  • the higher order in the call relation is the caller function, and the lower order in the call relation is the call destination function.
  • the last function in the calling order, that is, the first function in the reverse calling order is called a terminal function.
  • the function correspondence table is accepted by the following procedure.
  • the display unit 193 displays the pre-change call graph on the display.
  • the verifier refers to the call graph before change and determines the reverse call order of the function before change.
  • the verifier refers to the pre-change specification and the post-change specification, and determines the post-change function corresponding to the pre-change function in the reverse call order of the pre-change function.
  • the verifier operates the input device to input the function correspondence table to the equivalence verification device 100.
  • the reception unit 192 receives the input function correspondence table.
  • FIG. 7 shows a function correspondence table 233.
  • the function correspondence table 233 is a function correspondence table corresponding to the source code 210 before change in FIG. 3 and the source code 220 after change in FIG.
  • the function correspondence table 233 associates functions included in the pre-change source code 210 and functions included in the post-change source code 220 with each other.
  • the pre-change function column indicates the name of the function included in the pre-change source code 210
  • the post-change function column indicates the name of the function included in the post-change source code 220.
  • a hyphen means that there is no corresponding function.
  • the names of the functions included in the pre-change source code 210 are arranged in reverse call order.
  • the first row of the function correspondence table 233 indicates that there is no changed function corresponding to Func_F_x.
  • the second to sixth lines of the function correspondence table 233 indicate that Func _ # _ x and Func _ # _ y correspond to each other.
  • “#” Represents A, B, C, D, or E.
  • the pre-change function at the end is Func_F_x.
  • step S131 the control unit 120 selects one unselected function before change. Specifically, the control unit 120 selects in order from the end function before change. For example, the control unit 120 selects one pre-change function in the order shown in the function correspondence table.
  • the pre-change function selected means the pre-change function selected in step S131.
  • step S132 the control unit 120 determines whether there is a post-change function corresponding to the selected pre-change function using the function correspondence table. Specifically, the control unit 120 selects a row including the name of the selected pre-change function from the function correspondence table 233, and determines whether the selected row has a post-change function name. If the name of the post-change function exists in the selected line, there is a post-change function corresponding to the selected pre-change function. When the selected pre-change function is Func_B_x, the control unit 120 selects the fifth row from the function correspondence table 233 in FIG. The name of the function after change (Func_B_y) is present in the selected fifth line.
  • the control unit 120 determines that there is a post-change function corresponding to the selected pre-change function.
  • the selected pre-change function is Func_F_x
  • the control unit 120 selects the first row from the function correspondence table 233 in FIG. The selected first line has no changed function name. Therefore, the control unit 120 determines that there is no post-change function corresponding to the selected pre-change function. If there is a post-change function corresponding to the selected pre-change function, the process proceeds to step S140. If there is no post-change function corresponding to the selected pre-change function, the process proceeds to step S133.
  • a pair of the selected pre-change function and the post-change function corresponding to the selected pre-change function is referred to as a corresponding pair.
  • a function included in the correspondence group is called a target function.
  • step S133 the control unit 120 registers the selected pre-change function as an inequality function in the equivalence determination table.
  • An inequality function is a function included in a correspondence pair that is inequality, that is, a target function that is inequality.
  • the equivalence determination table is data for managing the equivalence of the target function.
  • FIG. 8 shows an equivalence determination table 240.
  • the equivalence determination table 240 of FIG. 8 is an equivalence determination table when Func_F_x is registered as an inequality function.
  • the equivalence determination table 240 includes columns for the target function, counterexample, equivalence, source code before change, and source code after change.
  • the target function column indicates the target function.
  • Func_F identifies Func_F_x.
  • the equivalence column indicates equivalence between the target functions.
  • the diagonal lines in the counter-example column, the source code column before change, and the source code column after change indicate that there is no other target function corresponding to one target function. Each column of the counter example, the source code before change, and the source code after change will be described later.
  • step S140 will be described.
  • the equivalence verification apparatus 100 performs full equivalence verification and partial equivalence verification for the corresponding set.
  • Total equivalence verification is a process for determining whether two functions are completely equivalent.
  • Total equivalence means that the two functions are equivalent for all input values.
  • Equivalence means that when the same input value is given to two functions, the output value of one function matches the output value of the other function. In other words, the equivalent is that the logical operation contents of two source codes match, that is, the same output value is obtained when the source code is executed for the same input value.
  • Partial equivalence verification is a process for determining whether two functions are partially equivalent. Partial equivalence means that two functions are equivalent for some input values. In other words, partial equivalence is that the output values always match when the source code is executed with respect to some input values instead of all input values. Details of step S140 will be described later.
  • step S134 the control unit 120 determines that there is an unselected function before change. If there is an unselected function before change, the process proceeds to step S131. If there is no unselected function before change, the process ends the equivalence checking method.
  • Step S140 The procedure of the verification process (S140) will be described based on FIG. Steps S141 and S142 correspond to full equivalence verification.
  • step S141 the equivalence verification unit 130 generates a verification file.
  • the verification file is data serving as an input for equivalence verification.
  • Equivalence verification is a process for verifying the equivalence of two functions. That is, equivalence verification is a process for determining whether two functions are equivalent.
  • the equivalence verification unit 130 generates an input matching sentence, a calling sentence, and an output matching sentence, and describes each sentence in a file.
  • the file obtained by this is a verification file.
  • the input matching sentence is a sentence indicating a precondition that the input value of one target function matches the input value of the other target function.
  • the input match statement gives the same input value to both target functions.
  • the call statement is a statement for calling and executing the target function.
  • the output matching sentence is a sentence indicating a postcondition that the output value of one target function matches the output value of the other target function.
  • FIG. 10 shows the verification file 250.
  • the verification file 250 is a verification file when Func_B_x and Func_B_y are target functions.
  • the verification file 250 includes an input match statement 251, two call statements (252 and 253), and an output match statement 254.
  • the input matching statement 251 indicates a precondition that input_x matches input_y.
  • input_x is an input value of Func_B_x
  • input_y is an input value of Func_B_y.
  • the call statement 252 calls and executes Func_B_x with input_x as an input value.
  • the output value of Func_B_x is set to output_x.
  • the call statement 253 calls and executes Func_B_y with input_y as an input value.
  • the output value of Func_B_y is set to output_y.
  • the output match statement 254 indicates a postcondition that output_x matches output_y.
  • a double-slashed string is a comment.
  • the equivalence verification unit 130 performs equivalence verification using the verification file. Specifically, the equivalence verification unit 130 performs equivalence verification with the verification file, the source code before change, and the source code after change as inputs. Equivalence verification is a conventional technique. By equivalence verification, the source code before change and the source code after change are executed according to the description of the verification file, and the equivalence between the source code before change and the source code after change is verified based on the execution result. For example, the equivalence verification unit 130 performs equivalence verification by executing a tool called CBMC (Bounded Model Checking for C / C ++). Then, the equivalence verification unit 130 registers the equivalence verification result in the equivalence determination table.
  • CBMC Bounded Model Checking for C / C ++
  • FIG. 11 shows an equivalence determination table 240.
  • An equivalence determination table 240 in FIG. 11 is an equivalence determination table immediately before equivalence verification is performed on Func_B in step S142.
  • Func_B identifies Func_B_x and Func_B_y.
  • Func_E identifies Func_E_x and Func_E_y
  • Func_D identifies Func_D_x and Func_D_y
  • Func_C identifies Func_C_x and Func_C_y.
  • Func_F, Func_E, Func_D, and Func_C are subordinate functions of Func_B in the calling relationship, Func_F, Func_E, Func_D, and Func_C have been verified. Therefore, in the equivalence determination table 240, information regarding equivalence of Func_F, Func_E, Func_D, and Func_C is registered.
  • FIG. 12 shows an equivalence determination table 240.
  • the equivalence determination table 240 of FIG. 12 is an equivalence determination table when the equivalence verification for Func_B is performed in step S142.
  • 0 is registered in the counter example column as a result of equivalence verification for Func_B.
  • the counter example column shows input values when the output value of one target function does not match the output value of the other target function. However, both the input value and the output value or only the output value may be registered in the counter example column.
  • the three-point reader means omission of description, and the hyphen means that there is no corresponding value.
  • the equivalence column for Func_B, the source code column before change, and the source code column after change are still blank. However, inequality may be provisionally registered in the equivalence column for Func_B.
  • step S143 the identifier setting unit 140 sets a branch location identifier for each of the target function in the pre-change source code and the target function in the post-change source code.
  • the branch location identifier is an identifier for identifying a branch location.
  • the identifier setting unit 140 sets a branch location identifier for each of the source code before and after the change as follows. First, the identifier setting unit 140 selects a target function from the source code. Next, the identifier setting unit 140 finds a branch sentence from the target function. A branch sentence is a sentence for branching a path according to a condition. Specific branch statements are an if statement and an else statement. The path is a processing path in the source code. Next, the identifier setting unit 140 generates a branch location identifier for each branch location, using each of the head of the target function and the branch statement as a branch location. Next, the identifier setting unit 140 generates an update sentence for each branch location identifier. The update sentence is a sentence for updating the value of the branch location identifier. And the identifier setting part 140 adds an update sentence for every branch location.
  • FIG. 13 shows the source code 210 before change.
  • the pre-change source code 210 in FIG. 13 is the pre-change source code 210 immediately before step S143 is executed when Func_B_x is the target function.
  • Update statements (211 to 214) are added to Func_F_x, Func_E_x, Func_D_x, and Func_C_x, which are functions lower than Func_B_x in the calling relationship.
  • countN_x is a branch location identifier. N means an integer.
  • FIG. 14 shows the source code 210 before change.
  • the pre-change source code 210 in FIG. 14 is the pre-change source code 210 immediately after step S143 is executed when Func_B_x is the target function.
  • Three update statements (215 to 216) are added to Func_B_x.
  • FIG. 15 shows the changed source code 220.
  • the changed source code 220 in FIG. 15 is the changed source code 220 immediately before step S143 is executed when Func_B_y is the target function.
  • Update statements (221 to 223) are added to Func_E_y, Func_D_y, and Func_C_y, which are functions lower than Func_B_y in the calling relationship.
  • countN_y is a branch location identifier. N means an integer.
  • FIG. 16 shows the changed source code 220.
  • the changed source code 220 in FIG. 16 is the changed source code 220 immediately after step S143 is executed when Func_B_y is the target function.
  • Three update sentences (224 to 226) are added to Func_B_y.
  • step S144 the identifier setting unit 140 registers the branch location identifier in the identifier correspondence table in association with the call destination function for each call destination function in the target function.
  • the called function is a function to be called.
  • the callee function in the target function is a function called from the target function.
  • the identifier correspondence table is data for managing the correspondence between the callee function and the branch location identifier.
  • the identifier setting unit 140 registers the branch location identifier as follows. First, the identifier setting unit 140 extracts a call statement from the target function in the source code, and extracts a function name from the call statement. The function identified by the extracted function name is the callee function. Next, the identifier setting unit 140 refers to the source code from the calling statement toward the beginning of the target function, and extracts the branch location identifier that is found first. The extracted branch location identifier is a branch location identifier corresponding to the callee function. Then, the identifier setting unit 140 registers the function name of the call destination function and the branch location identifier corresponding to the call destination function in the identifier correspondence table.
  • FIG. 17 shows an identifier correspondence table 260.
  • the identifier correspondence table 260 in FIG. 17 is the identifier correspondence table 260 immediately before step S144 is executed when Func_B_x and Func_B_y are target functions.
  • the identifier correspondence table 260 includes columns for a target function, a source code before change, and a source code after change.
  • the respective fields of the source code before change and the source code after change include a branch location identifier field and a callee function field.
  • the call destination function in Func_C_x is Func_F_x.
  • Func_F_x is registered in the callee function column in the source code column before modification corresponding to Func_C.
  • the branch location identifier corresponding to Func_F_x is count4_x. Therefore, as shown in FIG. 17, count4_x is registered in the branch location identifier column in the source code before change corresponding to Func_F.
  • FIG. 18 shows an identifier correspondence table 260.
  • the identifier correspondence table 260 in FIG. 18 is the identifier correspondence table 260 immediately after step S144 is executed when Func_B_x and Func_B_y are target functions.
  • the call destination functions in Func_B_x are Func_D_x and Func_E_x. Therefore, as shown in FIG. 18, Func_D_x and Func_E_x are registered in the callee function column in the source code before change corresponding to Func_B.
  • the branch location identifier corresponding to Func_D_x is count6_x
  • the branch location identifier corresponding to Func_E_x is count7_x. Therefore, as shown in FIG.
  • count6_x is registered in the branch location identifier column in the source code before change corresponding to Func_D.
  • count7_x is registered in the branch location identifier column.
  • the call destination functions in Func_B_y are Func_D_y and Func_E_y. Therefore, as shown in FIG. 18, Func_D_y and Func_E_y are registered in the callee function column in the modified source code column corresponding to Func_B.
  • the branch location identifier corresponding to Func_D_y is count5_y
  • the branch location identifier corresponding to Func_E_y is count6_y.
  • count5_y is registered in the branch location identifier field in the modified source code field corresponding to Func_D. Furthermore, count6_y is registered in the branch location identifier field in the modified source code field corresponding to Func_E.
  • step S145 the equivalence checking unit 130 determines whether the result of the equivalence checking in step S142 is equivalent. If the equivalence verification results are equivalent, the process proceeds to step S146. If the equivalence verification result is not equivalent, the process proceeds to step S200.
  • step S146 the equivalence checking unit 130 registers the target function as an equivalent function in the equivalence determination table.
  • the equivalent function is a function included in a corresponding pair that is completely equivalent, that is, a target function that is completely equivalent.
  • step S200 the equivalence checking device 100 performs partial equivalence checking on the corresponding set. That is, the equivalence checking device 100 determines whether or not the target functions are partially equivalent.
  • step S210 the partial verification determination unit 150 determines whether both the inequality path and the inequality path are included in the target function.
  • the target function means a function before change or a function after change. That is, in step S210, it is determined whether at least one of the pre-change function and the post-change function includes both an inequality path and a non-equivalence path.
  • An inequality path is a path from which an inequality function is called.
  • a non-equivalent path is a path where a non-equivalent function is called.
  • a non-equivalent function is a function that is not an inequality function.
  • the non-equivalent functions are an equivalent function and a partial equivalent function.
  • the partial equivalent function is a function included in a corresponding pair that is partially equivalent, that is, a target function that is partially equivalent.
  • a correspondence set including a target function including both an inequality path and a inequality path is called a partial verification set. If both the inequality path and the inequality path are included in the target function, that is, if the corresponding pair is a partial verification pair, the process proceeds to step S220. If either the inequality path or the inequality path is not included in the target function, that is, if the corresponding pair is not a partial verification pair, the process proceeds to step S233.
  • step S211 the partial verification determination unit 150 determines whether the target function is a function that calls a plurality of call destination functions.
  • the partial verification determination unit 150 performs determination using the identifier correspondence table 260 as follows. First, the partial verification determination unit 150 refers to the identifier correspondence table 260 and counts the number of call destination functions associated with the target function. Then, the partial verification determination unit 150 determines whether the number of call destination functions associated with the target function is two or more. When the number of call destination functions associated with the target function is 2 or more, the target function is a function that calls a plurality of call destination functions.
  • step S212 If the target function is a function that calls a plurality of call destination functions, the process proceeds to step S212. If the target function is not a function that calls a plurality of call destination functions, the process proceeds to step S215.
  • the number of call destination functions (Func_D_x, Func_E_x) associated with the target function is 2 in the identifier correspondence table 260 of FIG.
  • the number of call destination functions (Func_D_y, Func_E_y) associated with the target function is 2 in the identifier correspondence table 260 of FIG. Therefore, when the corresponding pair is a pair of Func_B_x and Func_B_y, the process proceeds to step S212.
  • step S212 the partial verification determination unit 150 determines whether both the inequality function and the inequality function are included in the plurality of call destination functions.
  • the partial verification determination unit 150 performs determination as follows using the identifier correspondence table 260 and the equivalence determination table 240.
  • the partial verification determination unit 150 refers to the identifier correspondence table 260 and identifies a plurality of call destination functions associated with the target function.
  • the partial verification determination unit 150 refers to the equivalence determination table 240 and identifies a plurality of equivalences corresponding to a plurality of callee functions.
  • the partial verification determination unit 150 determines whether at least one of the plurality of equivalences is unequal and at least one of the plurality of equivalences is equivalent or partial equivalent. If at least one of the multiple equivalences is unequal and at least one of the multiple equivalences is equivalent or partial equivalent, both the inequality function and the non-equivalence function are the multiple callee functions. include.
  • the call destination functions associated with the target function are Func_D_x and Func_E_x.
  • the equivalence of Func_D_x is equivalent, and the equivalence of Func_E_x is unequal.
  • the target function is FuncB_y
  • the call destination functions associated with the target function are Func_D_y and Func_E_y.
  • step S213 the partial verification determination unit 150 determines whether the branch location identifier of the inequality function is different from the branch location identifier of the inequality function.
  • the branch location identifier of the inequality function is a branch location identifier corresponding to the location where the inequality function is called.
  • the branch location identifier of the inequality function is a branch location identifier corresponding to the location where the inequality function is called.
  • the partial verification determination unit 150 performs determination using the identifier correspondence table 260 as follows. First, the partial verification determination unit 150 extracts a branch location identifier associated with an inequality function from the identifier correspondence table 260 for each inequality function. The branch location identifier extracted is the branch location identifier of the inequality function. Further, the partial verification determination unit 150 extracts, from the identifier correspondence table 260, branch location identifiers associated with the inequality functions for each inequality function. The extracted branch location identifier is the branch location identifier of the inequality function. Then, the partial verification determination unit 150 compares the branch location identifier of the inequality function with the branch location identifier of the inequality function for each set of the inequality function and the inequality function. If the branch location identifier of the inequality function does not match the branch location identifier of the inequality function in at least one of the pairs, the branch location identifier corresponding to the inequality function is different from the branch location corresponding to the inequality function.
  • step S214 If the branch location identifier corresponding to the inequality function is different from the branch location corresponding to the inequality function, the process proceeds to step S214. If the branch location identifier corresponding to the inequality function matches the branch location corresponding to the inequality function, the process proceeds to step S215.
  • step S214 the partial verification determination unit 150 determines that both the inequality path and the inequality path are included in the target function.
  • step S215 the partial verification determination unit 150 determines that one of the inequality path and the inequality path is not included in the target function.
  • step S ⁇ b> 220 the partial verification unit 160 performs equivalence verification on the target group by excluding inequality paths. That is, the partial verification unit 160 determines whether or not the target functions are equivalent in the non-equivalence path.
  • step S221 the partial verification unit 160 adds the first exclusion control statement to the verification file.
  • the first exclusion control statement is a statement for excluding the first inequivalent path.
  • the first inequality path is an inequality path in the target function.
  • An inequality function called in the first inequality path is called a first inequality function.
  • the partial verification unit 160 adds the first exclusion control statement as follows. First, the partial verification unit 160 generates a first exclusion control statement.
  • the first exclusion control statement is a statement for determining whether the value of the first branch location identifier matches the value before updating (initial value). If the value of the first branch location identifier does not match the value before the update, the input that is a condition for passing through the first inequality path is excluded from the equivalence verification.
  • the first branch location identifier is a branch location identifier of the first inequality function, that is, a branch location identifier corresponding to a location where the first inequality function is called.
  • the partial verification unit 160 selects a call statement that calls the target function from the verification file. And the partial verification part 160 adds a 1st exclusion control sentence after the selected calling sentence.
  • FIG. 22 shows the verification file 250 after step S221.
  • the verification file 250 includes a first exclusion control statement 255 after the call statement 252. Further, the verification file 250 includes a first exclusion control statement 256 after the call statement 253.
  • the first exclusion control statement 255 determines whether the value of count7_x matches the value before update.
  • count7_x is a branch location identifier of Func_E_x (see FIG. 18).
  • Func_E_x is a call destination function of Func_B_x (see FIG. 18) and is an inequality function (see FIG. 12).
  • the first inequality function is called, the value of count7_x is updated from 0 to 1. At this time, the value of count7_x is outside the equivalence determination range (see FIG. 22).
  • the first exclusion control statement 256 determines whether the value of count6_y matches the value before update.
  • count6_y is a branch location identifier of Func_E_y (see FIG. 18).
  • Func_E_y is a call destination function of Func_B_y (see FIG. 18) and is an inequality function (see FIG. 12).
  • the first inequality function is called, the value of count6_y is updated from 0 to 1.
  • the value of count6_y is outside the equivalence determination range (see FIG. 22). That is, the determination result by the 1st exclusion control sentence 256 is inconsistent. Therefore, the input corresponding to count6_y is excluded from the equivalence verification.
  • step S222 the partial verification unit 160 determines whether the target function is a function that calls a partial equivalent function. That is, the partial verification unit 160 determines whether there is a partial equivalent function among a plurality of call destination functions called from the target function.
  • the partial verification unit 160 makes the determination using the identifier correspondence table 260 and the equivalence determination table 240 as follows. First, the partial verification unit 160 refers to the identifier correspondence table 260 and identifies a plurality of call destination functions associated with the target function. Next, the partial verification unit 160 refers to the equivalence determination table 240 and identifies a plurality of equivalences corresponding to a plurality of callee functions. Then, the partial verification unit 160 determines whether at least one of the plurality of equivalences is partial equivalent. When at least one of the plurality of equivalences is partial equivalent, the target function is a function that calls the partial equivalent function.
  • step S22 If the target function is a function that calls a partial equivalent function, the process proceeds to step S223. If the target function is not a function that calls a partial equivalent function, the process proceeds to step S224.
  • the call destination functions of Func_B_x are Func_D_x and Func_E_x (see FIG. 18). None of the equivalence between Func_D_x and Func_E_x is partially equivalent (see FIG. 12). Therefore, Func_B_x is not a function that calls a partial equivalent function.
  • the call destination functions of Func_B_y are Func_D_y and Func_E_y (see FIG. 18). None of the equivalence between Func_D_y and Func_E_y is partially equivalent (see FIG. 12). Therefore, Func_B_y is not a function that calls a partial equivalent function. Therefore, when the corresponding pair is a pair including Func_B_x and Func_B_y, the process proceeds to step S224.
  • step S223 the partial verification unit 160 adds the second exclusion control statement to the verification file.
  • the second exclusion control statement is a statement for excluding the second inequality path.
  • the second inequality path is an inequality path in the partial equivalent function called from the target function.
  • An inequality function called in the second inequality path is called a second inequality function.
  • the partial verification unit 160 adds the second exclusion control statement as follows. First, the partial verification unit 160 generates a second exclusion control statement.
  • the second exclusion control statement is a statement for determining whether the value of the second branch location identifier matches the value before updating (initial value). If the value of the second branch location identifier does not match the value before the update, the input that is a condition for passing through the second inequality path is excluded from the equivalence verification.
  • the second branch location identifier is a branch location identifier of the second inequality function, that is, a branch location identifier corresponding to the location where the second inequality function is called.
  • the partial verification unit 160 selects a call statement that calls the partial equivalent function from the verification file. Then, the partial verification unit 160 adds a second exclusion control statement after the selected call statement.
  • step S224 the partial verification unit 160 performs equivalence verification using the verification file, the source code before change, and the source code after change.
  • the method for performing equivalence verification is the same as the method in step S142 of FIG.
  • step S231 the partial verification unit 160 determines whether the equivalence verification results in step S220 are equivalent. If the equivalence verification results are equivalent, the process proceeds to step S232. If the equivalence verification result is not equivalent, the process proceeds to step S233.
  • step S232 the partial verification unit 160 registers the target function as a partial equivalent function in the equivalence determination table. Furthermore, the partial verification unit 160 registers the branch location identifier of the first inequality function and the branch location identifier of the second inequality function in the equivalence determination table.
  • FIG. 23 shows an equivalence determination table 240.
  • 23 is an equivalence determination table 240 when Func_B_x and Func_B_y are partial equivalent functions. Partial equivalence is registered in the equivalence column corresponding to Func_B.
  • the pre-change source code column is a column for the pre-change function that is the target function.
  • the post-change source code column is a column for the post-change function that is the target function.
  • Each column of the source code before change and the source code after change shows the branch location identifier of the first inequality function and the branch location identifier of the second inequality function.
  • the hyphen means that there is no first inequality function and no second inequality function.
  • the first inequality function of Func_B_x is Func_E_x (see FIGS. 18 and 12).
  • the branch location identifier of Func_E_x is count7_x (see FIG. 18). Therefore, count7_x is registered in the pre-change source code column corresponding to Func_B.
  • the first inequality function of Func_B_y is Func_E_y (see FIGS. 18 and 12).
  • the branch location identifier of Func_E_y is count6_y (see FIG. 18). Therefore, count6_y is registered in the column of the source code after change corresponding to Func_B.
  • step S233 the partial verification unit 160 registers the target function as an inequality function in the equivalence determination table.
  • step S223 (see FIG. 21) is executed because the target function is a function that calls a partial equivalent function will be described.
  • the target functions are Func_A_x and Func_A_y.
  • FIG. 24 shows the source code 210 before change.
  • the source code 210 before change in FIG. 24 is the source code 210 before change immediately after step S143 (see FIG. 9) is executed when Func_A_x is the target function.
  • Three update sentences (218, 219, 2110) are added to Func_A_x.
  • FIG. 25 shows the changed source code 220.
  • the modified source code 220 in FIG. 25 is the modified source code 220 immediately after step S143 (see FIG. 9) is executed when Func_A_y is the target function. Three update sentences (227 to 229) are added to Func_A_y.
  • FIG. 26 shows an identifier correspondence table 260.
  • the identifier correspondence table 260 in FIG. 26 is the identifier correspondence table 260 immediately after step S144 (see FIG. 9) is executed when Func_A_x and Func_A_y are target functions.
  • the call destination functions in Func_A_x are Func_B_x and Func_C_x. Therefore, as shown in FIG. 26, Func_B_x and Func_C_x are registered in the callee function column in the source code before change corresponding to Func_A.
  • the branch location identifier corresponding to Func_B_x is count9_x
  • the branch location identifier corresponding to Func_C_x is count10_x.
  • count9_x is registered in the branch location identifier column in the source code before change corresponding to Func_B. Furthermore, in the column of source code before change corresponding to Func_C, count10_x is registered in the column of branch location identifiers. As shown in FIG. 25, the call destination functions in Func_A_y are Func_B_y and Func_C_y. Therefore, as shown in FIG. 26, Func_B_y and Func_C_y are registered in the callee function column in the changed source code column corresponding to Func_A. As shown in FIG.
  • FIG. 27 shows the verification file 250 after step S221 (see FIG. 21).
  • the verification file 250 includes a first exclusion control statement 255 after the call statement 252. Further, the verification file 250 includes a first exclusion control statement 256 after the call statement 253.
  • the first exclusion control statement 255 determines whether the value of count10_x matches the value before update.
  • count10_x is a branch location identifier of Func_C_x (see FIG. 26).
  • Func_C_x is a call destination function of Func_A_x (see FIG. 26) and is an inequivalent function (see FIG. 23).
  • the first exclusion control statement 256 determines whether the value of count9_y matches the value before update.
  • count9_y is a branch location identifier of Func_C_y (see FIG. 26).
  • Func_C_y is a call destination function of Func_A_y (see FIG. 26) and an inequality function (see FIG. 23).
  • step S222 the partial verification unit 160 determines whether the target function is a function that calls a partial equivalent function.
  • the call destination functions of Func_A_x are Func_B_x and Func_C_x (see FIG. 26).
  • the equivalence of Func_B_x is partially equivalent (see FIG. 23). Therefore, Func_A_x is a function that calls a partial equivalent function.
  • the call destination functions of Func_A_y are Func_B_y and Func_C_y (see FIG. 26).
  • the equivalence of Func_B_y is also partially equivalent (see FIG. 23). Therefore, Func_A_y is a function that calls a partial equivalent function. Therefore, when the corresponding pair is a pair including Func_A_x and Func_A_y, the process proceeds to step S223.
  • step S223 the partial verification unit 160 adds the second exclusion control statement to the verification file.
  • FIG. 28 shows the verification file 250 after step S223 (see FIG. 21).
  • the verification file 250 includes a second exclusion control statement 257 after the call statement 252. Further, the verification file 250 includes a second exclusion control statement 258 after the call statement 253.
  • the second exclusion control statement 257 determines whether the value of count7_x matches the value before update.
  • count7_x is a branch location identifier of Func_E_x (see FIG. 26).
  • Func_E_x is a call destination function of Func_B_x (see FIG. 26) and is an inequality function (see FIG. 23).
  • Func_B_x is a call destination function of Func_A_x (see FIG. 26), and is a partial equivalent function (see FIG. 23).
  • count7_x is updated from 0 to 1.
  • the value of count7_x is outside the equivalence determination range (see FIG. 28). That is, the determination result by the second exclusion control statement 257 is inconsistent. Therefore, the input corresponding to count7_x is excluded from the equivalence verification.
  • the second exclusion control statement 258 determines whether the value of count6_y matches the value before update.
  • count6_y is a branch location identifier of Func_E_y (see FIG. 26).
  • Func_E_y is a call destination function of Func_B_y (see FIG. 26) and an inequality function (see FIG. 23).
  • Func_B_y is a call destination function of Func_A_y (see FIG. 26), and is a partial equivalent function (see FIG. 23).
  • the second inequality function is called, the value of count6_y is updated from 0 to 1.
  • the value of count6_y is outside the equivalence determination range (see FIG. 28). That is, the determination result by the second exclusion control statement 258 is inconsistent. Therefore, the input corresponding to count6_y is excluded from the equivalence verification.
  • FIG. 29 shows an equivalence determination table 240.
  • the equivalence determination table 240 of FIG. 29 is an equivalence determination table 240 when Func_A_x and Func_A_y are partial equivalent functions. Partial equivalence is registered in the equivalence column corresponding to Func_A.
  • the first inequality function of Func_A_x is Func_C_x (see FIGS. 26 and 23).
  • the branch location identifier of Func_C_x is count10_x (see FIG. 26). Therefore, count10_x is registered in the pre-change source code column corresponding to Func_A.
  • the second inequality function of Func_A_x is Func_E_x (see FIGS. 26 and 23).
  • the branch location identifier of Func_E_x is count7_x (see FIG. 26). Therefore, count7_x is registered in the pre-change source code column corresponding to Func_A.
  • count9_y and count6_y are registered in the column of changed source code corresponding to Func_A.
  • the equivalence verification apparatus 100 uses the equivalence result of the callee function in the target function to perform equivalence verification in a state in which paths that pass through the unequal callee function are excluded. Thereby, the range determined not to be unequal is expanded. As a result, the range for analyzing non-equivalent causes, that is, the causes of defects is narrowed, and the time required for manual analysis is shortened.
  • Embodiment 2 With respect to the mode for determining whether the calling path from the start point function to the end point function is an unequal path, differences from the first embodiment will be mainly described with reference to FIGS.
  • the equivalence verification device 100 includes a path verification unit 170 as a software element.
  • the equivalence verification program causes the computer to function as the call graph generation unit 110, the control unit 120, the equivalence verification unit 130, the identifier setting unit 140, the partial verification determination unit 150, the partial verification unit 160, and the path verification unit 170.
  • the reception unit 192 receives a start point function identifier and an end point function identifier.
  • the start point function identifier is an identifier of a function designated as the start point function.
  • the end point function identifier is an identifier of a function designated as the end point function.
  • the path from the start function to the end function is called a call path.
  • the call path indicates the calling order of functions from the start point function to the end point function.
  • the start point function identifier and the end point function identifier are received in the following procedure.
  • the path verification unit 170 generates a call graph by executing Graphviz with the changed call graph 232 as an input.
  • Graphviz is a tool for generating call graph diagrams.
  • the call graph diagram is a diagram showing the call relationship indicated by the call graph.
  • the display unit 193 displays the call graph diagram on the display.
  • the verifier refers to the call graph diagram, determines the start point function and the end point function, and inputs the start point function identifier and the end point function identifier to the equivalence verification apparatus 100.
  • the end function identifier is omitted, it is assumed that the end function identifier is input as the end function identifier.
  • the receiving unit 192 receives the input start point function identifier and end point function identifier.
  • FIG. 32 shows a call graph 270.
  • Call Graph FIG. 270 is a call graph corresponding to the post-change call graph 232 of FIG.
  • step S310 the path verification unit 170 extracts the third branch location identifier for each call path.
  • the third branch location identifier is a branch location identifier of the callee function included in the call path.
  • the branch location identifier of the call destination function is a branch location identifier corresponding to the location where the call destination function is called.
  • step S311 the path verification unit 170 selects one function in order from the start point function.
  • the target function means the function selected in step S311.
  • step S312 the path verification unit 170 determines whether the target function is a function that calls a plurality of call destination functions.
  • the path verification unit 170 uses the identifier correspondence table 260 to make a determination as follows. First, the path verification unit 170 refers to the identifier correspondence table 260 and counts the number of call destination functions associated with the target function. Then, the path verification unit 170 determines whether the number of call destination functions associated with the target function is 2 or more. When the number of call destination functions associated with the target function is 2 or more, the target function is a function that calls a plurality of call destination functions.
  • step S313 the path verification unit 170 determines whether the plurality of third branch location identifiers corresponding to the plurality of call destination functions are all the same.
  • the path verification unit 170 uses the identifier correspondence table 260 to make a determination as follows. First, the path verification unit 170 extracts a branch location identifier corresponding to the call destination function from the identifier correspondence table 260 for each call destination function. Then, the path verification unit 170 determines whether all the extracted branch location identifiers are the same.
  • step S316 If the plurality of branch location identifiers corresponding to the plurality of call destination functions are all the same, the process proceeds to step S316. If at least one of the plurality of branch location identifiers corresponding to the plurality of call destination functions is different from the other branch location identifiers, the process proceeds to step S314.
  • the branch location identifier of Func_B_y is count8_y
  • the branch location identifier of Func_C_y is count9_y. Therefore, when the plurality of call destination functions are Func_B_y and Func_C_y, the process proceeds to step S314.
  • step S314 the path verification unit 170 registers a plurality of call paths in the path determination table.
  • the path determination table is data for managing equivalence for each calling path and the third branch location identifier.
  • the path verification unit 170 registers a plurality of call paths as follows.
  • the path verification unit 170 determines whether a call path including the target function is registered in the path determination table.
  • the path verification unit 170 passes the same number of call paths as a plurality of call destination functions by duplicating the call path including the target function. Register in the judgment table. Then, the path verification unit 170 registers different call destination functions in the respective call paths.
  • the path verification unit 170 registers a call path indicating the target function and the call destination function for each call destination function in the path determination table. Then, the path verification unit 170 registers different call destination functions in the respective call paths.
  • step S315 the path verification unit 170 registers a plurality of branch location identifiers in the path determination table. Each of the plurality of registered branch location identifiers is a third branch location identifier. Specifically, the path verification unit 170 extracts the branch location identifier of the call destination function from the identifier correspondence table 260 for each call path registered in step S314, and sends the extracted branch location identifier to the path verification unit 170. sign up.
  • step S316 the path verification unit 170 determines whether there is an unselected function. If there is an unselected function, the process proceeds to step S311. If there is no unselected function, the extraction of the third branch location identifier (S310) ends.
  • FIG. 34 shows a path determination table 280.
  • a path determination table 280 in FIG. 34 is a path determination table corresponding to the call graph FIG. 270 in FIG. 32, and is a path determination table after step S310 (see FIG. 31).
  • the start point function is Func_A_y
  • the end point functions are Func_C_Y, Func_D_Y, and Func_E_Y.
  • Call destination functions in one call path are Func_B_y and Func_D_y.
  • the branch location identifier of Func_B_y is count8_y
  • the branch location identifier of FuncD_y is count5_y (see FIG. 26). Therefore, no.
  • the third branch location identifier of one call path is count8_y and count5_y.
  • the call destination functions in the second call path are Func_B_y and Func_E_y.
  • the branch location identifier of Func_B_y is count8_y
  • the branch location identifier of FuncE_y is count6_y (see FIG. 26). Therefore, no.
  • the third branch location identifiers of the second call path are count8_y and count6_y.
  • the call destination function in call path 3 is Func_C_y.
  • the branch location identifier of Func_C_y is count9_y (see FIG. 26). Therefore, no.
  • the third branch location identifier of the call path of 3 is count9_y.
  • step S321 the path verification unit 170 selects one unselected call path.
  • the call path means the call path selected in step S321.
  • step S322 the path verification unit 170 determines whether at least one of the third branch location identifiers of the call path matches either the first branch location identifier of the start point function or the second branch location identifier of the start point function. .
  • the path verification unit 170 performs the determination as follows. First, the path verification unit 170 extracts the third branch location identifier of the calling path from the branch location identifier field in the path determination table 280. Next, the path verification unit 170 extracts the first branch location identifier of the start point function and the second branch location identifier of the start point function from the changed source code column in the equivalence determination table 240. Next, the path verification unit 170 compares the third branch location identifier with the first branch location identifier of the start point function and the second branch location identifier of the start point function for each third branch location identifier of the call path.
  • the path verification unit 170 matches at least one of the third branch location identifiers of the call path with either the first branch location identifier of the start function or the second branch location identifier of the start function. Judge whether to do.
  • step S323 If at least one of the third branch location identifiers of the call path matches either the first branch location identifier of the start point function or the second branch location identifier of the start point function, the process proceeds to step S323. If all the third branch location identifiers in the call path do not match either the first branch location identifier of the start point function or the second branch location identifier of the start point function, the process proceeds to step S324.
  • the third branch location identifier of one call path is count8_y and count5_y.
  • the first branch point identifier and the second branch point identifier of Func_A_y that is the start point function are count6_y and count9_y (see FIG. 29). In this case, since all the third branch location identifiers do not match either the first branch location identifier or the second branch location identifier, the process proceeds to step S324.
  • the third branch location identifiers of the second call path are count8_y and count6_y.
  • the first branch point identifier and the second branch point identifier of Func_A_y that is the start point function are count6_y and count9_y (see FIG. 29). In this case, since count6_y is common between the third branch location identifier and the first branch location identifier, the process proceeds to step S323.
  • the third branch location identifier of the call path of 3 is count9_y.
  • the first branch point identifier and the second branch point identifier of Func_A_y that is the start point function are count6_y and count9_y (see FIG. 29). In this case, since count9_y is common between the third branch location identifier and the second branch location identifier, the process proceeds to step S323.
  • step S323 the path verification unit 170 registers the calling path as an unequal path in the path determination table.
  • step S324 the path verification unit 170 registers the calling path as an equivalent path in the path determination table.
  • step S325 the path verification unit 170 determines whether there is an unselected call path. If there is an unselected call path, the process proceeds to step S321. If there is no unselected call path, the path verification method processing ends.
  • FIG. 35 shows a path determination table 280 obtained by the path verification method.
  • the call path 1 is an equivalent path in which an inequality function is not called.
  • No. 2 call path and No. 2 Call path 3 is an inequality path where an inequality function is called.
  • the function of the equivalence checking apparatus 100 may be realized by hardware.
  • FIG. 36 shows a configuration when the function of the equivalence checking device 100 is realized by hardware.
  • the equivalence verification apparatus 100 includes a processing circuit 990.
  • the processing circuit 990 is also called a processing circuit.
  • the processing circuit 990 is dedicated to realizing the call graph generation unit 110, the control unit 120, the equivalence verification unit 130, the identifier setting unit 140, the partial verification determination unit 150, the partial verification unit 160, the path verification unit 170, and the storage unit 191. This is an electronic circuit.
  • the processing circuit 990 is a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, a logic IC, GA, ASIC, FPGA, or a combination thereof.
  • GA is an abbreviation for Gate Array
  • ASIC is an abbreviation for Application Specific Integrated Circuit
  • FPGA is an abbreviation for Field Programmable Gate Array.
  • the equivalence verification apparatus 100 may include a plurality of processing circuits that replace the processing circuit 990.
  • the plurality of processing circuits share the role of the processing circuit 990.
  • the embodiment is an example of a preferred embodiment and is not intended to limit the technical scope of the present invention.
  • the embodiment may be implemented partially or in combination with other embodiments.
  • the procedure described using the flowchart and the like may be changed as appropriate.
  • 100 equivalence verification device 110 call graph generation unit, 120 control unit, 130 equivalence verification unit, 140 identifier setting unit, 150 partial verification determination unit, 160 partial verification unit, 170 path verification unit, 191 storage unit, 192 reception unit , 193 display section, 210 source code before change, 211-219 update text, 2110 update text, 220 source code after change, 221-229 update text, 231 call graph before change, 232 call graph after change, 233 function correspondence table, 240 equivalence judgment table, 250 verification file, 251 input match sentence, 252 call sentence, 253 call sentence, 254 output match sentence, 255 first exclusion control sentence, 256 first exclusion control sentence, 257 second exclusion control sentence, 258 Second exclusion control statement, 260 identifier correspondence table, 70 Call graph, 280 pass determination table 901 processor, 902 a memory, 903 an auxiliary storage device, 904 output interface, 990 processing circuits.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)

Abstract

等価性検証部（１３０）は、変更前ソースコードに含まれる関数と変更後ソースコードに含まれる関数との組である対応組毎に、対応組に含まれる関数同士が等価であるか等価性検証によって判定する。部分検証判定部（１５０）は、不等価である対応組毎に、対応組が、不等価関数が呼び出される不等価パスと非不等価関数が呼び出される非不等価パスとの両方が含まれる関数を含んだ部分検証組であるか判定する。部分検証部（１６０）は、部分検証組毎に、不等価パスを除外して等価性検証を行うことによって、部分検証組に含まれる関数同士が部分等価であるか判定する。

Description

等価性検証装置および等価性検証プログラム
　本発明は、関数同士の等価性を検証する技術に関するものである。
　ソフトウェアの多機能化および電子化によって、ソフトウェアは複雑化および大規模化の一途をたどっている。このような状況下において、ソフトウェア開発の生産性の向上を図る必要がある。
　例えば、ソフトウェアの差分派生開発において、品質の維持および開発工数の削減を実現するソフトウェア開発ツールが適用される。
　ソフトウェアの差分派生開発において、リファクタリングと呼ばれる手法がある。リファクタリングは、ソフトウェアの論理的な演算内容を変更せずにソフトウェアの内部構成を変えることによって、ソフトウェアの品質を改善するための手法である。
　リファクタリングでは、ソースコードの変更が伴う。そのため、ソースコードの変更により不具合が発生し、論理的な演算内容が意図せずして変更される可能性がある。
　そのため、ソフトウェアの差分派生開発において、ソフトウェアの変更前後の検証が要求される。
　非特許文献１では、レガシーコードとＳｉｍｕｌｉｎｋとを用いて生成されたソースコードを対象として、「等価性検証」に関する手法が開示されている。
　「等価」は、２つのソースコードの論理的な演算内容が一致すること、つまり同じ入力値に対して同じ出力値が得られることを意味する。
　「等価性検証」は、２つのソースコードが等価であるか否かを検証することである。
　非特許文献１では、２つのソースコードに対して、ソースコードに含まれる関数の呼び出し関係を表現するためにコールグラフが生成される。そして、コールグラフが用いられて、関数名および呼出関係が一致している関数同士の関連付けと関数単位での等価性検証とが行われる。
　等価性検証は末端の関数から順に行われる。等価の条件は、２つのソースコードが同じ入力値に対して実行された場合に２つのソースコードで同じ出力値が得られることである。等価性検証では、入力値に対する出力値が２つのソースコードで一致することが全ての入力値について網羅的に解析され、関数単位で等価性が判定される。
　特許文献１では、ソースコードにおいて分岐文からの分岐先のブロックに対して振る舞いを表すタグが埋め込まれる。そして、検証対象とする振る舞いが指定され、検証すべきブロックを通過するための変数（または式）の値の範囲がブロックに埋め込まれたタグと指定された振る舞いとに基づいて特定される。特定された値の範囲を検証範囲とすることで、特定の振る舞いに関連したソースコードのみを検証することができる。
特開２０１０－２０４９５４号公報
Ｒｕｐａｋ　Ｍａｊｕｍｄａｒ，　"Ｃｏｍｐｏｓｉｔｉｏｎａｌ　Ｅｑｕｉｖａｌｅｎｃｅ　Ｃｈｅｃｋｉｎｇ　ｆｏｒ　Ｍｏｄｅｌｓ　ａｎｄ　Ｃｏｄｅ　ｏｆ　Ｃｏｎｔｒｏｌ　Ｓｙｓｔｅｍｓ，"　５２ｎｄ　ＩＥＥＥ　Ｃｏｎｆｅｒｅｎｃｅ　ｏｎ　Ｄｅｃｉｓｉｏｎ　ａｎｄ　Ｃｏｎｔｒｏｌ，　Ｄｅｃｅｍｂｅｒ　２０１３．
　非特許文献１では、全ての入力値において入力値に対する出力値が一致することが条件となる。そのため、関数内で通過するパスによって等価性が異なる場合においても、関数が不等価であると判定される。したがって、関数が不等価であると判定された原因を解析するための範囲が広く、人手による不具合解析にかかる時間を削減することができない。
　例えば、関数ＡＸと関数ＡＹとの等価性を判定する。特定条件が満たされる場合、関数ＡＸでは関数ＢＸが呼び出され、関数ＡＹでは関数ＢＸと等価な関数ＢＹが呼び出される。したがって、特定条件が満たされる場合に関しては、関数ＡＸと関数ＡＹとは等価である。特定条件が満たされない場合、関数ＡＸでは関数ＣＸが呼び出され、関数ＡＹでは関数ＣＸと等価でない関数ＢＹが呼び出される。したがって、特定条件が満たされない場合に関しては、関数ＡＸと関数ＡＹとは等価である。
　非特許文献１では、特定条件が満たされる場合に等価であっても特定条件が満たされない場合に等価でなければ、不等価と判定される。したがって、関数ＡＸと関数ＡＹとは不等価と判定される。
　特許文献１では、変数が多数ある場合または式が複雑な場合、特定のブロックを通過するための値の範囲が一意に定まらないことがある。そのため、特許文献１の適用範囲は限定される。
　本発明は、関数同士が部分等価であるか判定できるようにすることを目的とする。
　本発明の等価性検証装置は、
　変更前ソースコードに含まれる関数と変更後ソースコードに含まれる関数との組である対応組毎に、対応組に含まれる関数同士が等価であるか等価性検証によって判定する等価性検証部と、
　不等価である対応組毎に、対応組が、不等価関数が呼び出される不等価パスと非不等価関数が呼び出される非不等価パスとの両方が含まれる関数を含んだ部分検証組であるか判定する部分検証判定部と、
　部分検証組毎に、前記不等価パスを除外して前記等価性検証を行うことによって、部分検証組に含まれる関数同士が部分等価であるか判定する部分検証部とを備える。
　本発明によれば、関数同士が部分等価であるか判定することができる。
実施の形態１における等価性検証装置１００の構成図。 実施の形態１における等価性検証方法のフローチャート。 実施の形態１における変更前ソースコード２１０を示す図。 実施の形態１における変更後ソースコード２２０を示す図。 実施の形態１における変更前コールグラフ２３１を示す図。 実施の形態１における変更後コールグラフ２３２を示す図。 実施の形態１における関数対応表２３３を示す図。 実施の形態１における等価性判定表２４０を示す図。 実施の形態１における検証処理（Ｓ１４０）のフローチャート。 実施の形態１における検証ファイル２５０を示す図。 実施の形態１における等価性判定表２４０を示す図。 実施の形態１における等価性判定表２４０を示す図。 実施の形態１における変更前ソースコード２１０（ステップＳ１４３の前）を示す図。 実施の形態１における変更前ソースコード２１０（ステップＳ１４３の後）を示す図。 実施の形態１における変更後ソースコード２２０（ステップＳ１４３の前）を示す図。 実施の形態１における変更後ソースコード２２０（ステップＳ１４３の後）を示す図。 実施の形態１における識別子対応表２６０（ステップＳ１４４の前）を示す図。 実施の形態１における識別子対応表２６０（ステップＳ１４４の後）を示す図。 実施の形態１における部分等価検証（Ｓ２００）のフローチャート。 実施の形態１における部分検証判定（Ｓ２１０）のフローチャート。 実施の形態１における部分検証（Ｓ２２０）のフローチャート。 実施の形態１における検証ファイル２５０（ステップＳ２２１の後）を示す図。 実施の形態１における等価性判定表２４０（ステップＳ２３２の後）を示す図。 実施の形態１における変更前ソースコード２１０（ステップＳ１４３の後）を示す図。 実施の形態１における変更後ソースコード２２０（ステップＳ１４３の後）を示す図。 実施の形態１における識別子対応表２６０（ステップＳ１４４の後）を示す図。 実施の形態１における検証ファイル２５０（ステップＳ２２１の後）を示す図。 実施の形態１における検証ファイル２５０（ステップＳ２２３の後）を示す図。 実施の形態１における等価性判定表２４０（ステップＳ２３２の後）を示す図。 実施の形態２における等価性検証装置１００の構成図。 実施の形態２におけるパス検証方法のフローチャート。 実施の形態２におけるコールグラフ図２７０を示す図。 実施の形態２における第３分岐箇所識別子の抽出（Ｓ３１０）のフローチャート。 実施の形態２におけるパス判定表２８０（ステップＳ３１０の後）を示す図。 実施の形態２におけるパス判定表２８０（パス検証の後）を示す図。 実施の形態における等価性検証装置１００のハードウェア構成図。
　実施の形態および図面において、同じ要素および対応する要素には同じ符号を付している。同じ符号が付された要素の説明は適宜に省略または簡略化する。図中の矢印はデータの流れ又は処理の流れを主に示している。
　実施の形態１．
　関数同士が部分等価であるか判定するための形態について、図１から図２９に基づいて説明する。
＊＊＊構成の説明＊＊＊
　図１に基づいて、等価性検証装置１００の構成を説明する。
　等価性検証装置１００は、プロセッサ９０１とメモリ９０２と補助記憶装置９０３と入出力インタフェース９０４といったハードウェアを備えるコンピュータである。これらのハードウェアは、信号線を介して互いに接続されている。
　プロセッサ９０１は、演算処理を行うＩＣ（Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）であり、他のハードウェアを制御する。例えば、プロセッサ９０１は、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ　Ｓｉｇｎａｌ　Ｐｒｏｃｅｓｓｏｒ）、またはＧＰＵ（Ｇｒａｐｈｉｃｓ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）である。
　メモリ９０２は揮発性の記憶装置である。メモリ９０２は、主記憶装置またはメインメモリとも呼ばれる。例えば、メモリ９０２はＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）である。メモリ９０２に記憶されたデータは必要に応じて補助記憶装置９０３に保存される。
　補助記憶装置９０３は不揮発性の記憶装置である。例えば、補助記憶装置９０３は、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）、またはフラッシュメモリである。補助記憶装置９０３に記憶されたデータは必要に応じてメモリ９０２にロードされる。
　入出力インタフェース９０４は入力装置および出力装置が接続されるポートである。例えば、入出力インタフェース９０４はＵＳＢ端子であり、入力装置はキーボードおよびマウスであり、出力装置はディスプレイである。ＵＳＢはＵｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓの略称である。
　等価性検証装置１００は、コールグラフ生成部１１０と制御部１２０と等価性検証部１３０と識別子設定部１４０と部分検証判定部１５０と部分検証部１６０といったソフトウェア要素を備える。ソフトウェア要素はソフトウェアで実現される要素である。
　補助記憶装置９０３には、コールグラフ生成部１１０と制御部１２０と等価性検証部１３０と識別子設定部１４０と部分検証判定部１５０と部分検証部１６０としてコンピュータを機能させるための等価性検証プログラムが記憶されている。等価性検証プログラムは、メモリ９０２にロードされて、プロセッサ９０１によって実行される。
　さらに、補助記憶装置９０３にはＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）が記憶されている。ＯＳの少なくとも一部は、メモリ９０２にロードされて、プロセッサ９０１によって実行される。
　つまり、プロセッサ９０１は、ＯＳを実行しながら、等価性検証プログラムを実行する。
　等価性検証プログラムを実行して得られるデータは、メモリ９０２、補助記憶装置９０３、プロセッサ９０１内のレジスタまたはプロセッサ９０１内のキャッシュメモリといった記憶装置に記憶される。
　メモリ９０２はデータを記憶する記憶部１９１として機能する。但し、他の記憶装置が、メモリ９０２の代わりに、又は、メモリ９０２と共に、記憶部１９１として機能してもよい。
　入出力インタフェース９０４は、入力を受け付ける受付部１９２として機能する。さらに、入出力インタフェース９０４は、画像などを表示する表示部１９３として機能する。
　等価性検証装置１００は、プロセッサ９０１を代替する複数のプロセッサを備えてもよい。複数のプロセッサは、プロセッサ９０１の役割を分担する。
　等価性検証プログラムは、磁気ディスク、光ディスクまたはフラッシュメモリ等の不揮発性の記憶媒体にコンピュータ読み取り可能に記憶することができる。不揮発性の記憶媒体は、一時的でない有形の媒体である。
＊＊＊動作の説明＊＊＊
　等価性検証装置１００の動作は等価性検証方法に相当する。また、等価性検証方法の手順は等価性検証プログラムの手順に相当する。
　図２に基づいて、等価性検証方法を説明する。
　ステップＳ１０１において、受付部１９２は、変更前ソースコードと変更後ソースコードとを受け付ける。記憶部１９１は、受け付けられた変更前ソースコードと変更後ソースコードとを記憶する。
　変更前ソースコードは、変更前のソフトウェアにおけるソースコードである。例えば、変更前ソースコードは従来作成したソースコードである。
　変更後ソースコードは、変更後のソフトウェアにおけるソースコードである。例えば、変更後ソースコードは、変更前ソースコードを基にリファクタリングを実施することによって得られたソースコードである。
　図３に、変更前ソースコード２１０を示す。変更前ソースコード２１０は、変更前ソースコードの具体例である。
　変更前ソースコード２１０は、６つの関数（Ｆｕｎｃ＿Ｆ＿ｘ、Ｆｕｎｃ＿Ｅ＿ｘ、Ｆｕｎｃ＿Ｄ＿ｘ、Ｆｕｎｃ＿Ｃ＿ｘ、Ｆｕｎｃ＿Ｂ＿ｘ、Ｆｕｎｃ＿Ａ＿ｘ）を含んでいる。
　図４に、変更後ソースコード２２０を示す。変更後ソースコード２２０は、変更後ソースコードの具体例である。
　変更後ソースコード２２０は、５つの関数（Ｆｕｎｃ＿Ｅ＿ｙ、Ｆｕｎｃ＿Ｄ＿ｙ、Ｆｕｎｃ＿Ｃ＿ｙ、Ｆｕｎｃ＿Ｂ＿ｙ、Ｆｕｎｃ＿Ａ＿ｙ）を含んでいる。
　変更前ソースコード２１０および変更後ソースコード２２０において、コロンおよび三点リーダは記載の省略を意味する。
　図２に戻り、ステップＳ１１０から説明を続ける。
　ステップＳ１１０において、コールグラフ生成部１１０は、変更前ソースコードと変更後ソースコードとを解析することによって、変更前コールグラフと変更後コールグラフとを生成する。記憶部１９１は、変更前コールグラフと変更後コールグラフとを記憶する。
　変更前コールグラフは、変更前ソースコードのコールグラフである。
　変更後コールグラフは、変更後ソースコードのコールグラフである。
　コールグラフは、関数間の呼び出し関係を示すデータであり、従来技術によって生成することが可能である。
　例えば、コールグラフ生成部１１０は、変更前ソースコードを入力としてｅｇｙｐｔを実行することによって、変更前コールグラフを生成する。また、コールグラフ生成部１１０は、変更後ソースコードを入力としてｅｇｙｐｔを実行することによって、変更後コールグラフを生成する。ｅｇｙｐｔは、コールグラフを生成するための既存のツールである。
　図５に、変更前コールグラフ２３１を示す。変更前コールグラフ２３１は、図３の変更前ソースコード２１０を入力としてｅｇｙｐｔを実行することによって得られる変更前コールグラフである。
　変更前コールグラフ２３１は、Ｆｕｎｃ＿Ａ＿ｘからＦｕｎｃ＿Ｂ＿ｘとＦｕｎｃ＿Ｃ＿ｘとが呼ばれ、Ｆｕｎｃ＿Ｂ＿ｘからＦｕｎｃ＿Ｄ＿ｘとＦｕｎｃ＿Ｅ＿ｘとが呼ばれ、Ｆｕｎｃ＿Ｃ＿ｘからＦｕｎｃ＿Ｆ＿ｘが呼ばれることを示している。
　図６に、変更後コールグラフ２３２を示す。変更後コールグラフ２３２は、図４の変更後ソースコード２２０を入力としてｅｇｙｐｔを実行することによって得られる変更後コールグラフである。
　変更後コールグラフ２３２は、Ｆｕｎｃ＿Ａ＿ｙからＦｕｎｃ＿Ｂ＿ｙとＦｕｎｃ＿Ｃ＿ｙとが呼ばれ、Ｆｕｎｃ＿Ｂ＿ｙからＦｕｎｃ＿Ｄ＿ｙとＦｕｎｃ＿Ｅ＿ｙとが呼ばれることを示している。
　図２に戻り、ステップＳ１２０から説明を続ける。
　ステップＳ１２０において、受付部１９２は、関数対応表を受け付ける。そして、記憶部１９１は、受け付けられた関数対応表を記憶する。
　関数対応表は、変更前関数と変更後関数との対応関係を示すデータである。
　変更前関数は、変更前ソースコードに含まれる関数である。
　変更後関数は、変更後ソースコードに含まれる関数である。
　特に、関数対応表は、変更前関数または変更後関数の逆呼び出し順に、変更前関数と変更後関数との対応関係を示す。
　逆呼び出し順とは、呼び出し順の逆順である。
　呼び出し順とは、呼び出し関係において上位から下位への順である。呼び出し関係における上位は呼び出し元の関数であり、呼び出し関係における下位は呼び出し先の関数である。
　呼び出し順における最終の関数、つまり、逆呼び出し順における先頭の関数を、末端の関数という。
　例えば、関数対応表は以下のような手順で受け付けられる。
　まず、表示部１９３は、変更前コールグラフをディスプレイに表示する。
　次に、検証者は、変更前コールグラフを参照し、変更前関数の逆呼び出し順を判断する。
　次に、検証者は、変更前仕様書と変更後仕様書とを参照し、変更前関数の逆呼び出し順に変更前関数に対応する変更後関数を判断する。
　次に、検証者は、入力装置を操作して、関数対応表を等価性検証装置１００に入力する。
　そして、受付部１９２は、入力された関数対応表を受け付ける。
　図７に、関数対応表２３３を示す。関数対応表２３３は、図３の変更前ソースコード２１０と図４の変更後ソースコード２２０とに対応する関数対応表である。
　関数対応表２３３は、変更前ソースコード２１０に含まれる関数と変更後ソースコード２２０に含まれる関数とを互いに対応付けている。
　変更前関数の欄は変更前ソースコード２１０に含まれる関数の名称を示し、変更後関数の欄は変更後ソースコード２２０に含まれる関数の名称を示している。ハイフンは該当する関数が無いことを意味する。
　変更前関数の欄において、変更前ソースコード２１０に含まれる関数の名称は、逆呼び出し順に並べられている。
　関数対応表２３３の第１行は、Ｆｕｎｃ＿Ｆ＿ｘに対応する変更後関数が無いことを示している。また、関数対応表２３３の第２行から第６行は、Ｆｕｎｃ＿＃＿ｘとＦｕｎｃ＿＃＿ｙとが互いに対応することを示している。「＃」はＡ、Ｂ、Ｃ、ＤまたはＥを表す。
　末端の変更前関数はＦｕｎｃ＿Ｆ＿ｘである。
　図２に戻り、ステップＳ１３１から説明を続ける。
　ステップＳ１３１において、制御部１２０は未選択の変更前関数を１つ選択する。具体的には、制御部１２０は、末端の変更前関数から順に選択する。例えば、制御部１２０は、関数対応表に示される順に変更前関数を１つ選択する。
　ステップＳ１３２およびステップＳ１３３の説明において、選択された変更前関数は、ステップＳ１３１で選択された変更前関数を意味する。
　ステップＳ１３２において、制御部１２０は、関数対応表を用いて、選択された変更前関数に対応する変更後関数が有るか判定する。
　具体的には、制御部１２０は、選択された変更前関数の名称を含む行を関数対応表２３３から選択し、選択された行に変更後関数の名称が有るか判定する。選択された行に変更後関数の名称が有れば、選択された変更前関数に対応する変更後関数が有る。
　選択された変更前関数がＦｕｎｃ＿Ｂ＿ｘである場合、制御部１２０は、図７の関数対応表２３３から第５行を選択する。選択された第５行には変更後関数の名称（Ｆｕｎｃ＿Ｂ＿ｙ）が有る。したがって、制御部１２０は、選択された変更前関数に対応する変更後関数が有ると判定する。
　選択された変更前関数がＦｕｎｃ＿Ｆ＿ｘである場合、制御部１２０は、図７の関数対応表２３３から第１行を選択する。選択された第１行には変更後関数の名称が無い。したがって、制御部１２０は、選択された変更前関数に対応する変更後関数が無いと判定する。
　選択された変更前関数に対応する変更後関数が有る場合、処理はステップＳ１４０に進む。
　選択された変更前関数に対応する変更後関数が無い場合、処理はステップＳ１３３に進む。
　以降の説明において、選択された変更前関数と選択された変更前関数に対応する変更後関数との組を対応組という。また、対応組に含まれる関数を対象関数という。
　ステップＳ１３３において、制御部１２０は、選択された変更前関数を等価性判定表に不等価関数として登録する。
　不等価関数は、不等価である対応組に含まれる関数、つまり、不等価である対象関数である。
　等価性判定表は、対象関数の等価性などを管理するためのデータである。
　図８に、等価性判定表２４０を示す。
　図８の等価性判定表２４０は、Ｆｕｎｃ＿Ｆ＿ｘが不等価関数として登録されたときの等価性判定表である。
　等価性判定表２４０は、対象関数と反例と等価性と変更前ソースコードと変更後ソースコードとのそれぞれの欄を有している。
　対象関数の欄は、対象関数を示す。Ｆｕｎｃ＿ＦはＦｕｎｃ＿Ｆ＿ｘを識別する。
　等価性の欄は、対象関数同士の等価性を示す。
　反例の欄と変更前ソースコードの欄と変更後ソースコードの欄とのそれぞれに記された斜線は、一方の対象関数に対応する他方の対象関数が無いことを意味する。
　反例と変更前ソースコードと変更後ソースコードとのそれぞれの欄については後述する。
　図２に戻り、ステップＳ１４０を説明する。
　ステップＳ１４０において、等価性検証装置１００は、対応組に対する全等価検証および部分等価検証を行う。
　全等価検証は、２つの関数が全等価であるか否かを判定するための処理である。
　全等価は、全ての入力値において２つの関数が等価であることを意味する。
　等価は、２つの関数に同じ入力値が与えられた場合に一方の関数の出力値が他方の関数の出力値と一致することを意味する。言い換えると、等価は、２つのソースコードの論理的な演算内容が一致すること、つまり同じ入力値に対してソースコードを実行したときに同じ出力値が得られることである。
　部分等価検証は、２つの関数が部分等価であるか否かを判定するための処理である。
　部分等価は、一部の入力値において２つの関数が等価であることを意味する。言い換えると、部分等価は、全ての入力値ではなく、一部の入力値において、ソースコードを実行した際に出力値が常に一致することである。
　ステップＳ１４０の詳細については後述する。
　ステップＳ１３３またはステップＳ１４０の後、処理はステップＳ１３４に進む。
　ステップＳ１３４において、制御部１２０は、未選択の変更前関数が有るから判定する。
　未選択の変更前関数が有る場合、処理はステップＳ１３１に進む。
　未選択の変更前関数が無い場合、処理は等価性検証方法は終了する。
　図９に基づいて、検証処理（Ｓ１４０）の手順を説明する。
　ステップＳ１４１およびステップＳ１４２は全等価検証に相当する。
　ステップＳ１４１において、等価性検証部１３０は、検証ファイルを生成する。
　検証ファイルは、等価性検証の入力となるデータである。
　等価性検証は、２つの関数の等価性を検証するための処理である。つまり、等価性検証は、２つの関数が等価であるか否かを判定するための処理である。
　具体的には、等価性検証部１３０は、入力一致文と呼び出し文と出力一致文とを生成し、各々の文をファイルに記載する。これによって得られるファイルが検証ファイルである。
　入力一致文は、一方の対象関数の入力値が他方の対象関数の入力値と一致するという事前条件を示す文である。入力一致文によって、両方の対象関数に同じ入力値が与えられる。
　呼び出し文は、対象関数を呼び出して実行するための文である。
　出力一致文は、一方の対象関数の出力値が他方の対象関数の出力値と一致するという事後条件を示す文である。
　図１０に、検証ファイル２５０を示す。
　検証ファイル２５０は、Ｆｕｎｃ＿Ｂ＿ｘおよびＦｕｎｃ＿Ｂ＿ｙが対象関数である場合の検証ファイルである。
　検証ファイル２５０は、入力一致文２５１と２つの呼び出し文（２５２、２５３）と出力一致文２５４とを含んでいる。
　入力一致文２５１は、ｉｎｐｕｔ＿ｘがｉｎｐｕｔ＿ｙと一致するという事前条件を示している。ｉｎｐｕｔ＿ｘはＦｕｎｃ＿Ｂ＿ｘの入力値であり、ｉｎｐｕｔ＿ｙはＦｕｎｃ＿Ｂ＿ｙの入力値である。
　呼び出し文２５２によって、ｉｎｐｕｔ＿ｘを入力値としてＦｕｎｃ＿Ｂ＿ｘが呼び出されて実行される。Ｆｕｎｃ＿Ｂ＿ｘの出力値はｏｕｔｐｕｔ＿ｘに設定される。
　呼び出し文２５３によって、ｉｎｐｕｔ＿ｙを入力値としてＦｕｎｃ＿Ｂ＿ｙが呼び出されて実行される。Ｆｕｎｃ＿Ｂ＿ｙの出力値はｏｕｔｐｕｔ＿ｙに設定される。
　出力一致文２５４は、ｏｕｔｐｕｔ＿ｘがｏｕｔｐｕｔ＿ｙと一致するという事後条件を示している。
　二重斜線付きの文字列はコメントである。
　ステップＳ１４２において、等価性検証部１３０は、検証ファイルを用いて等価性検証を行う。
　具体的には、等価性検証部１３０は、検証ファイルと変更前ソースコードと変更後ソースコードとを入力として等価性検証を行う。等価性検証は従来の技術である。
　等価性検証によって、検証ファイルの記載に従って変更前ソースコードと変更後ソースコードとが実行され、実行結果に基づいて変更前ソースコートと変更後ソースコードとの等価性が検証される。
　例えば、等価性検証部１３０は、ＣＢＭＣ（Ｂｏｕｎｄｅｄ　Ｍｏｄｅｌ　Ｃｈｅｃｋｉｎｇ　ｆｏｒ　Ｃ／Ｃ＋＋）と呼ばれるツールを実行することによって、等価性検証を行う。
　そして、等価性検証部１３０は、等価性検証の結果を等価性判定表に登録する。
　図１１に、等価性判定表２４０を示す。
　図１１の等価性判定表２４０は、ステップＳ１４２においてＦｕｎｃ＿Ｂに対する等価性検証が行われる直前の等価性判定表である。Ｆｕｎｃ＿ＢはＦｕｎｃ＿Ｂ＿ｘおよびＦｕｎｃ＿Ｂ＿ｙを識別する。
　対象関数の欄において、Ｆｕｎｃ＿ＥはＦｕｎｃ＿Ｅ＿ｘおよびＦｕｎｃ＿Ｅ＿ｙを識別し、Ｆｕｎｃ＿ＤはＦｕｎｃ＿Ｄ＿ｘおよびＦｕｎｃ＿Ｄ＿ｙを識別し、Ｆｕｎｃ＿ＣはＦｕｎｃ＿Ｃ＿ｘおよびＦｕｎｃ＿Ｃ＿ｙを識別する。
　呼び出し関係においてＦｕｎｃ＿Ｆ、Ｆｕｎｃ＿Ｅ、Ｆｕｎｃ＿ＤおよびＦｕｎｃ＿ＣはＦｕｎｃ＿Ｂの下位の関数であるので、Ｆｕｎｃ＿Ｆ、Ｆｕｎｃ＿Ｅ、Ｆｕｎｃ＿ＤおよびＦｕｎｃ＿Ｃは検証済みである。そのため、等価性判定表２４０には、Ｆｕｎｃ＿Ｆ、Ｆｕｎｃ＿Ｅ、Ｆｕｎｃ＿ＤおよびＦｕｎｃ＿Ｃの等価性に関する情報が登録されている。
　図１２に、等価性判定表２４０を示す。
　図１２の等価性判定表２４０は、ステップＳ１４２においてＦｕｎｃ＿Ｂに対する等価性検証が行われた場合の等価性判定表である。
　等価性判定表２４０において、Ｆｕｎｃ＿Ｂに対する等価性検証の結果として、反例の欄に０が登録されている。
　反例の欄は、一方の対象関数の出力値が他方の対象関数の出力値と一致しない場合の入力値を示す。但し、反例の欄には、入力値と出力値との両方または出力値のみが登録されてもよい。
　反例の欄において、三点リーダは記載の省略を意味し、ハイフンは該当する値が無いことを意味する。
　Ｆｕｎｃ＿Ｂに対する等価性の欄、変更前ソースコードの欄および変更後ソースコードの欄は、まだ空欄である。但し、Ｆｕｎｃ＿Ｂに対する等価性の欄に、暫定的に不等価が登録されてもよい。
　図９に戻り、ステップＳ１４３から説明を続ける。
　ステップＳ１４３において、識別子設定部１４０は、変更前ソースコードの中の対象関数と変更後ソースコードの中の対象関数とのそれぞれに、分岐箇所識別子を設定する。
　分岐箇所識別子は、分岐箇所を識別する識別子である。
　具体的には、識別子設定部１４０は、変更前ソースコードと変更後ソースコードとのそれぞれのソースコードに対して以下のように分岐箇所識別子を設定する。
　まず、識別子設定部１４０は、ソースコードから対象関数を選択する。
　次に、識別子設定部１４０は、対象関数から分岐文を見つける。分岐文は、条件によってパスを分岐するための文である。具体的な分岐文はｉｆ文およびｅｌｓｅ文である。パスは、ソースコードにおける処理経路である。
　次に、識別子設定部１４０は、対象関数の先頭と分岐文とのそれぞれを分岐箇所として、分岐箇所毎に分岐箇所識別子を生成する。
　次に、識別子設定部１４０は、分岐箇所識別子毎に更新文を生成する。更新文は、分岐箇所識別子の値を更新する文である。
　そして、識別子設定部１４０は、分岐箇所毎に更新文を追加する。
　図１３に、変更前ソースコード２１０を示す。
　図１３の変更前ソースコード２１０は、Ｆｕｎｃ＿Ｂ＿ｘが対象関数である場合において、ステップＳ１４３が実行される直前の変更前ソースコード２１０である。
　呼び出し関係においてＦｕｎｃ＿Ｂ＿ｘよりも下位の関数であるＦｕｎｃ＿Ｆ＿ｘ、Ｆｕｎｃ＿Ｅ＿ｘ、Ｆｕｎｃ＿Ｄ＿ｘおよびＦｕｎｃ＿Ｃ＿ｘには、更新文（２１１～２１４）が追加されている。
　変更前ソースコード２１０において、ｃｏｕｎｔＮ＿ｘが分岐箇所識別子である。Ｎは整数を意味する。
　図１４に、変更前ソースコード２１０を示す。
　図１４の変更前ソースコード２１０は、Ｆｕｎｃ＿Ｂ＿ｘが対象関数である場合において、ステップＳ１４３が実行された直後の変更前ソースコード２１０である。
　Ｆｕｎｃ＿Ｂ＿ｘには、３つの更新文（２１５～２１６）が追加されている。
　図１５に、変更後ソースコード２２０を示す。
　図１５の変更後ソースコード２２０は、Ｆｕｎｃ＿Ｂ＿ｙが対象関数である場合において、ステップＳ１４３が実行される直前の変更後ソースコード２２０である。
　呼び出し関係においてＦｕｎｃ＿Ｂ＿ｙよりも下位の関数であるＦｕｎｃ＿Ｅ＿ｙ、Ｆｕｎｃ＿Ｄ＿ｙおよびＦｕｎｃ＿Ｃ＿ｙには、更新文（２２１～２２３）が追加されている。
　変更後ソースコード２２０において、ｃｏｕｎｔＮ＿ｙが分岐箇所識別子である。Ｎは整数を意味する。
　図１６に、変更後ソースコード２２０を示す。
　図１６の変更後ソースコード２２０は、Ｆｕｎｃ＿Ｂ＿ｙが対象関数である場合において、ステップＳ１４３が実行された直後の変更後ソースコード２２０である。
　Ｆｕｎｃ＿Ｂ＿ｙには、３つの更新文（２２４～２２６）が追加されている。
　図９に戻り、ステップＳ１４４から説明を続ける。
　ステップＳ１４４において、識別子設定部１４０は、対象関数の中の呼び出し先関数毎に呼び出し先関数に対応付けて分岐箇所識別子を識別子対応表に登録する。
　呼び出し先関数は、呼び出される関数である。対象関数の中の呼び出し先関数は、対象関数から呼び出される関数である。
　識別子対応表は、呼び出し先関数と分岐箇所識別子との対応関係を管理するためのデータである。
　具体的には、識別子設定部１４０は分岐箇所識別子を以下のように登録する。
　まず、識別子設定部１４０は、ソースコードの中の対象関数から呼び出し文を抽出し、呼び出し文から関数名を抽出する。抽出される関数名で識別される関数が呼び出し先関数である。
　次に、識別子設定部１４０は、呼び出し文から対象関数の先頭に向けてソースコードを参照し、最初に見つかる分岐箇所識別子を抽出する。抽出される分岐箇所識別子は、呼び出し先関数に対応する分岐箇所識別子である。
　そして、識別子設定部１４０は、呼び出し先関数の関数名と呼び出し先関数に対応する分岐箇所識別子とを識別子対応表に登録する。
　図１７に、識別子対応表２６０を示す。
　図１７の識別子対応表２６０は、Ｆｕｎｃ＿Ｂ＿ｘおよびＦｕｎｃ＿Ｂ＿ｙが対象関数である場合において、ステップＳ１４４が実行される直前の識別子対応表２６０である。
　識別子対応表２６０は、対象関数と変更前ソースコードと変更後ソースコードとのそれぞれの欄を有する。変更前ソースコードと変更後ソースコードとのそれぞれの欄には、分岐箇所識別子の欄と呼び出し先関数の欄とが含まれる。
　図１３に示すように、Ｆｕｎｃ＿Ｃ＿ｘの中の呼び出し先関数はＦｕｎｃ＿Ｆ＿ｘである。そのため、図１７に示すように、Ｆｕｎｃ＿Ｃに対応する変更前ソースコードの欄において、呼び出し先関数の欄にＦｕｎｃ＿Ｆ＿ｘが登録されている。
　図１３に示すように、Ｆｕｎｃ＿Ｆ＿ｘに対応する分岐箇所識別子はｃｏｕｎｔ４＿ｘである。そのため、図１７に示すように、Ｆｕｎｃ＿Ｆに対応する変更前ソースコードの欄において、分岐箇所識別子の欄にｃｏｕｎｔ４＿ｘが登録されている。
　図１８に、識別子対応表２６０を示す。
　図１８の識別子対応表２６０は、Ｆｕｎｃ＿Ｂ＿ｘおよびＦｕｎｃ＿Ｂ＿ｙが対象関数である場合において、ステップＳ１４４が実行された直後の識別子対応表２６０である。
　図１４に示すように、Ｆｕｎｃ＿Ｂ＿ｘの中の呼び出し先関数はＦｕｎｃ＿Ｄ＿ｘおよびＦｕｎｃ＿Ｅ＿ｘである。そのため、図１８に示すように、Ｆｕｎｃ＿Ｂに対応する変更前ソースコードの欄において、呼び出し先関数の欄にＦｕｎｃ＿Ｄ＿ｘおよびＦｕｎｃ＿Ｅ＿ｘが登録されている。
　図１４に示すように、Ｆｕｎｃ＿Ｄ＿ｘに対応する分岐箇所識別子はｃｏｕｎｔ６＿ｘであり、Ｆｕｎｃ＿Ｅ＿ｘに対応する分岐箇所識別子はｃｏｕｎｔ７＿ｘである。そのため、図１８に示すように、Ｆｕｎｃ＿Ｄに対応する変更前ソースコードの欄において、分岐箇所識別子の欄にｃｏｕｎｔ６＿ｘが登録されている。さらに、Ｆｕｎｃ＿Ｅに対応する変更前ソースコードの欄において、分岐箇所識別子の欄にｃｏｕｎｔ７＿ｘが登録されている。
　図１６に示すように、Ｆｕｎｃ＿Ｂ＿ｙの中の呼び出し先関数はＦｕｎｃ＿Ｄ＿ｙおよびＦｕｎｃ＿Ｅ＿ｙである。そのため、図１８に示すように、Ｆｕｎｃ＿Ｂに対応する変更後ソースコードの欄において、呼び出し先関数の欄にＦｕｎｃ＿Ｄ＿ｙおよびＦｕｎｃ＿Ｅ＿ｙが登録されている。
　図１６に示すように、Ｆｕｎｃ＿Ｄ＿ｙに対応する分岐箇所識別子はｃｏｕｎｔ５＿ｙであり、Ｆｕｎｃ＿Ｅ＿ｙに対応する分岐箇所識別子はｃｏｕｎｔ６＿ｙである。そのため、図１８に示すように、Ｆｕｎｃ＿Ｄに対応する変更後ソースコードの欄において、分岐箇所識別子の欄にｃｏｕｎｔ５＿ｙが登録されている。さらに、Ｆｕｎｃ＿Ｅに対応する変更後ソースコードの欄において、分岐箇所識別子の欄にｃｏｕｎｔ６＿ｙが登録されている。
　図９に戻り、ステップＳ１４５から説明を続ける。
　ステップＳ１４５において、等価性検証部１３０は、ステップＳ１４２での等価性検証の結果が等価であるか判定する。
　等価性検証の結果が等価である場合、処理はステップＳ１４６に進む。
　等価性検証の結果が等価でない場合、処理はステップＳ２００に進む。
　ステップＳ１４６において、等価性検証部１３０は、等価性判定表に対象関数を等価関数として登録する。
　等価関数は、全等価である対応組に含まれる関数、つまり、全等価である対象関数である。
　ステップＳ２００において、等価性検証装置１００は、対応組に対する部分等価検証を行う。つまり、等価性検証装置１００は、対象関数同士が部分等価であるか否かを判定する。
　図１９に基づいて、部分等価検証（Ｓ２００）の手順を説明する。
　ステップＳ２１０において、部分検証判定部１５０は、不等価パスと非不等価パスとの両方が対象関数に含まれるか判定する。
　但し、対象関数は変更前関数または変更後関数を意味する。つまり、ステップＳ２１０では、変更前関数と変更後関数との少なくとも一方に不等価パスと非不等価パスとの両方が含まれるか判定される。
　不等価パスは、不等価関数が呼び出されるパスである。
　非不等価パスは、非不等価関数が呼び出されるパスである。
　非不等価関数は、不等価関数ではない関数である。具体的には、非不等価関数は、等価関数および部分等価関数である。
　部分等価関数は、部分等価である対応組に含まれる関数、つまり、部分等価である対象関数である。
　不等価パスと非不等価パスとの両方が含まれる対象関数を含んだ対応組を部分検証組という。
　不等価パスと非不等価パスとの両方が対象関数に含まれる場合、つまり、対応組が部分検証組である場合、処理はステップＳ２２０に進む。
　不等価パスと非不等価パスとのいずれかが対象関数に含まれない場合、つまり、対応組が部分検証組でない場合、処理はステップＳ２３３に進む。
　図２０に基づいて、部分検証判定（Ｓ２１０）の手順を説明する。
　ステップＳ２１１において、部分検証判定部１５０は、対象関数が複数の呼び出し先関数を呼び出す関数であるか判定する。
　具体的には、部分検証判定部１５０は、識別子対応表２６０を用いて以下のように判定を行う。
　まず、部分検証判定部１５０は、識別子対応表２６０を参照し、対象関数に対応付けられた呼び出し先関数の数を数える。
　そして、部分検証判定部１５０は、対象関数に対応付けられた呼び出し先関数の数が２以上であるか判定する。
　対象関数に対応付けられた呼び出し先関数の数が２以上である場合、対象関数が複数の呼び出し先関数を呼び出す関数である。
　対象関数が複数の呼び出し先関数を呼び出す関数である場合、処理はステップＳ２１２に進む。
　対象関数が複数の呼び出し先関数を呼び出す関数ではない場合、処理はステップＳ２１５に進む。
　対象関数がＦｕｎｃＢ＿ｘである場合、図１８の識別子対応表２６０において、対象関数に対応付けられた呼び出し先関数（Ｆｕｎｃ＿Ｄ＿ｘ、Ｆｕｎｃ＿Ｅ＿ｘ）の数は２である。
　対象関数がＦｕｎｃＢ＿ｙである場合、図１８の識別子対応表２６０において、対象関数に対応付けられた呼び出し先関数（Ｆｕｎｃ＿Ｄ＿ｙ、Ｆｕｎｃ＿Ｅ＿ｙ）の数は２である。
　したがって、対応組がＦｕｎｃ＿Ｂ＿ｘとＦｕｎｃ＿Ｂ＿ｙとの組である場合、処理はステップＳ２１２に進む。
　ステップＳ２１２において、部分検証判定部１５０は、不等価関数と非不等価関数との両方が複数の呼び出し先関数に含まれるか判定する。
　具体的には、部分検証判定部１５０は、識別子対応表２６０と等価性判定表２４０とを用いて以下のように判定を行う。
　まず、部分検証判定部１５０は、識別子対応表２６０を参照し、対象関数に対応付けられた複数の呼び出し先関数を特定する。
　次に、部分検証判定部１５０は、等価性判定表２４０を参照し、複数の呼び出し先関数に対応する複数の等価性を特定する。
　そして、部分検証判定部１５０は、複数の等価性の少なくともいずれかが不等価であり、且つ、複数の等価性の少なくともいずれかが等価または部分等価であるか判定する。
　複数の等価性の少なくともいずれかが不等価であり、且つ、複数の等価性の少なくともいずれかが等価または部分等価である場合、不等価関数と非不等価関数との両方が複数の呼び出し先関数に含まれる。
　不等価関数と非不等価関数との両方が複数の呼び出し先関数に含まれる場合、処理はステップＳ２１３に進む。
　不等価関数と非不等価関数との一方が複数の呼び出し先関数に含まれない場合、処理はステップＳ２１５に進む。
　対象関数がＦｕｎｃＢ＿ｘである場合、図１８の識別子対応表２６０において、対象関数に対応付けられた呼び出し先関数はＦｕｎｃ＿Ｄ＿ｘおよびＦｕｎｃ＿Ｅ＿ｘである。図１２の等価性判定表２４０において、Ｆｕｎｃ＿Ｄ＿ｘの等価性は等価であり、Ｆｕｎｃ＿Ｅ＿ｘの等価性は不等価である。
　対象関数がＦｕｎｃＢ＿ｙである場合、図１８の識別子対応表２６０において、対象関数に対応付けられた呼び出し先関数はＦｕｎｃ＿Ｄ＿ｙおよびＦｕｎｃ＿Ｅ＿ｙである。図１２の等価性判定表２４０において、Ｆｕｎｃ＿Ｄ＿ｙの等価性は等価であり、Ｆｕｎｃ＿Ｅ＿ｙの等価性は不等価である。
　したがって、対応組がＦｕｎｃ＿Ｂ＿ｘとＦｕｎｃ＿Ｂ＿ｙとの組である場合、処理はステップＳ２１３に進む。
　ステップＳ２１３において、部分検証判定部１５０は、不等価関数の分岐箇所識別子が非不等価関数の分岐箇所識別子と異なるか判定する。
　不等価関数の分岐箇所識別子は、不等価関数が呼び出される箇所に対応する分岐箇所識別子である。
　非不等価関数の分岐箇所識別子は、非不等価関数が呼び出される箇所に対応する分岐箇所識別子である。
　具体的には、部分検証判定部１５０は、識別子対応表２６０を用いて以下のように判定を行う。
　まず、部分検証判定部１５０は、不等価関数毎に不等価関数に対応付けられた分岐箇所識別子を識別子対応表２６０から抽出する。抽出される分岐箇所識別子が不等価関数の分岐箇所識別子である。
　さらに、部分検証判定部１５０、非不等価関数毎に非不等価関数に対応付けられた分岐箇所識別子を識別子対応表２６０から抽出する。抽出される分岐箇所識別子が非不等価関数の分岐箇所識別子である。
　そして、部分検証判定部１５０は、不等価関数と非不等価関数との組毎に不等価関数の分岐箇所識別子を非不等価関数の分岐箇所識別子と比較する。
　少なくともいずれかの組で不等価関数の分岐箇所識別子が非不等価関数の分岐箇所識別子と一致しない場合、不等価関数に対応する分岐箇所識別子が非不等価関数に対応する分岐箇所と異なる。
　不等価関数に対応する分岐箇所識別子が非不等価関数に対応する分岐箇所と異なる場合、処理はステップＳ２１４に進む。
　不等価関数に対応する分岐箇所識別子が非不等価関数に対応する分岐箇所と一致する場合、処理はステップＳ２１５に進む。
　ステップＳ２１４において、部分検証判定部１５０は、不等価パスと非不等価パスとの両方が対象関数に含まれると判定する。
　ステップＳ２１５において、部分検証判定部１５０は、不等価パスと非不等価パスとの一方が対象関数に含まれないと判定する。
　図１９に戻り、ステップＳ２２０から説明を続ける。
　ステップＳ２２０において、部分検証部１６０は、不等価パスを除外して対象組に対する等価性検証を行う。つまり、部分検証部１６０は、非不等価パスにおいて対象関数同士が等価であるか否かを判定する。
　図２１に基づいて、部分検証（Ｓ２２０）の手順を説明する。
　ステップＳ２２１において、部分検証部１６０は、第１除外制御文を検証ファイルに追加する。
　第１除外制御文は、第１不等価パスを除外するための文である。
　第１不等価パスは、対象関数の中の不等価パスである。
　第１不等価パスで呼び出される不等価関数を第１不等価関数という。
　具体的には、部分検証部１６０は第１除外制御文を以下のように追加する。
　まず、部分検証部１６０は第１除外制御文を生成する。
　第１除外制御文は、第１分岐箇所識別子の値が更新前の値（初期値）と一致するか判定する文である。第１分岐箇所識別子の値が更新前の値と一致しない場合、第１不等価パスを通る条件となる入力は等価検証から除外される。
　第１分岐箇所識別子は、第１不等価関数の分岐箇所識別子、つまり、第１不等価関数が呼び出される箇所に対応する分岐箇所識別子である。
　次に、部分検証部１６０は、対象関数を呼び出す呼び出し文を検証ファイルから選択する。
　そして、部分検証部１６０は、選択された呼び出し文の後に第１除外制御文を追加する。
　図２２に、ステップＳ２２１の後の検証ファイル２５０を示す。
　検証ファイル２５０は、呼び出し文２５２の後に第１除外制御文２５５を含んでいる。さらに、検証ファイル２５０は、呼び出し文２５３の後に第１除外制御文２５６を含んでいる。
　第１除外制御文２５５により、ｃｏｕｎｔ７＿ｘの値が更新前の値と一致するか判定される。ｃｏｕｎｔ７＿ｘは、Ｆｕｎｃ＿Ｅ＿ｘの分岐箇所識別子である（図１８参照）。Ｆｕｎｃ＿Ｅ＿ｘは、Ｆｕｎｃ＿Ｂ＿ｘの呼び出し先関数であり（図１８参照）、不等価関数である（図１２参照）。第１不等価関数が呼ばれていた場合、ｃｏｕｎｔ７＿ｘの値は０から１に更新されている。このとき、ｃｏｕｎｔ７＿ｘの値は等価性判定範囲外（図２２参照）である。つまり、第１除外制御文２５５による判定結果は不一致である。そのため、ｃｏｕｎｔ７＿ｘに対応する入力は等価検証から除外される。
　第１除外制御文２５６により、ｃｏｕｎｔ６＿ｙの値が更新前の値と一致するか判定される。ｃｏｕｎｔ６＿ｙは、Ｆｕｎｃ＿Ｅ＿ｙの分岐箇所識別子である（図１８参照）。Ｆｕｎｃ＿Ｅ＿ｙは、Ｆｕｎｃ＿Ｂ＿ｙの呼び出し先関数であり（図１８参照）、不等価関数である（図１２参照）。第１不等価関数が呼ばれていた場合、ｃｏｕｎｔ６＿ｙの値は０から１に更新されている。このとき、ｃｏｕｎｔ６＿ｙの値は等価性判定範囲外（図２２参照）である。つまり、第１除外制御文２５６による判定結果は不一致である。そのため、ｃｏｕｎｔ６＿ｙに対応する入力は等価検証から除外される。
　図２１に戻り、ステップＳ２２２から説明を続ける。
　ステップＳ２２２において、部分検証部１６０は、対象関数が部分等価関数を呼び出す関数であるか判定する。
　つまり、部分検証部１６０は、対象関数から呼び出される複数の呼び出し先関数の中に部分等価関数が有るか判定する。
　具体的には、部分検証部１６０は、識別子対応表２６０と等価性判定表２４０とを用いて以下のように判定を行う。
　まず、部分検証部１６０は、識別子対応表２６０を参照し、対象関数に対応付けられた複数の呼び出し先関数を特定する。
　次に、部分検証部１６０は、等価性判定表２４０を参照し、複数の呼び出し先関数に対応する複数の等価性を特定する。
　そして、部分検証部１６０は、複数の等価性の少なくともいずれかが部分等価であるか判定する。
　複数の等価性の少なくともいずれかが部分等価である場合、対象関数が部分等価関数を呼び出す関数である。
　対象関数が部分等価関数を呼び出す関数である場合、処理はステップＳ２２３に進む。
　対象関数が部分等価関数を呼び出す関数でない場合、処理はステップＳ２２４に進む。
　Ｆｕｎｃ＿Ｂ＿ｘの呼び出し先関数はＦｕｎｃ＿Ｄ＿ｘおよびＦｕｎｃ＿Ｅ＿ｘである（図１８参照）。Ｆｕｎｃ＿Ｄ＿ｘとＦｕｎｃ＿Ｅ＿ｘとのいずれの等価性も部分等価でない（図１２参照）。そのため、Ｆｕｎｃ＿Ｂ＿ｘは部分等価関数を呼び出す関数ではない。
　Ｆｕｎｃ＿Ｂ＿ｙの呼び出し先関数はＦｕｎｃ＿Ｄ＿ｙおよびＦｕｎｃ＿Ｅ＿ｙである（図１８参照）。Ｆｕｎｃ＿Ｄ＿ｙとＦｕｎｃ＿Ｅ＿ｙとのいずれの等価性も部分等価でない（図１２参照）。そのため、Ｆｕｎｃ＿Ｂ＿ｙは部分等価関数を呼び出す関数ではない。
　したがって、対応組がＦｕｎｃ＿Ｂ＿ｘとＦｕｎｃ＿Ｂ＿ｙとを含んだ組である場合、処理はステップＳ２２４に進む。
　ステップＳ２２３において、部分検証部１６０は、第２除外制御文を検証ファイルに追加する。
　第２除外制御文は、第２不等価パスを除外するための文である。
　第２不等価パスは、対象関数から呼び出される部分等価関数の中の不等価パスである。
　第２不等価パスで呼び出される不等価関数を第２不等価関数という。
　具体的には、部分検証部１６０は第２除外制御文を以下のように追加する。
　まず、部分検証部１６０は第２除外制御文を生成する。
　第２除外制御文は、第２分岐箇所識別子の値が更新前の値（初期値）と一致するか判定する文である。第２分岐箇所識別子の値が更新前の値と一致しない場合、第２不等価パスを通る条件となる入力は等価検証から除外される。
　第２分岐箇所識別子は、第２不等価関数の分岐箇所識別子、つまり、第２不等価関数が呼び出される箇所に対応する分岐箇所識別子である。
　次に、部分検証部１６０は、部分等価関数を呼び出す呼び出し文を検証ファイルから選択する。
　そして、部分検証部１６０は、選択された呼び出し文の後に第２除外制御文を追加する。
　ステップＳ２２４において、部分検証部１６０は、検証ファイルと変更前ソースコードと変更後ソースコードとを用いて等価性検証を行う。
　等価性検証を行う方法は、図９のステップＳ１４２における方法と同じである。
　図１９に戻り、ステップＳ２３１から説明を続ける。
　ステップＳ２３１において、部分検証部１６０は、ステップＳ２２０での等価性検証の結果が等価であるか判定する。
　等価性検証の結果が等価である場合、処理はステップＳ２３２に進む。
　等価性検証の結果が等価でない場合、処理はステップＳ２３３に進む。
　ステップＳ２３２において、部分検証部１６０は、等価性判定表に対象関数を部分等価関数として登録する。
　さらに、部分検証部１６０は、第１不等価関数の分岐箇所識別子と第２不等価関数の分岐箇所識別子とを等価性判定表に登録する。
　図２３に、等価性判定表２４０を示す。
　図２３の等価性判定表２４０は、Ｆｕｎｃ＿Ｂ＿ｘおよびＦｕｎｃ＿Ｂ＿ｙが部分等価関数である場合の等価性判定表２４０である。
　Ｆｕｎｃ＿Ｂに対応する等価性の欄には部分等価が登録されている。
　変更前ソースコードの欄は、対象関数である変更前関数用の欄である。
　変更後ソースコードの欄は、対象関数である変更後関数用の欄である。
　変更前ソースコードと変更後ソースコードとのそれぞれの欄は、第１不等価関数の分岐箇所識別子および第２不等価関数の分岐箇所識別子を示す。ハイフンは第１不等価関数および第２不等価関数が無いことを意味する。
　Ｆｕｎｃ＿Ｂ＿ｘの第１不等価関数はＦｕｎｃ＿Ｅ＿ｘである（図１８および図１２参照）。Ｆｕｎｃ＿Ｅ＿ｘの分岐箇所識別子はｃｏｕｎｔ７＿ｘである（図１８参照）。そのため、Ｆｕｎｃ＿Ｂに対応する変更前ソースコードの欄にはｃｏｕｎｔ７＿ｘが登録されている。
　Ｆｕｎｃ＿Ｂ＿ｙの第１不等価関数はＦｕｎｃ＿Ｅ＿ｙである（図１８および図１２参照）。Ｆｕｎｃ＿Ｅ＿ｙの分岐箇所識別子はｃｏｕｎｔ６＿ｙである（図１８参照）。そのため、Ｆｕｎｃ＿Ｂに対応する変更後ソースコードの欄にはｃｏｕｎｔ６＿ｙが登録されている。
　ステップＳ２３３において、部分検証部１６０は、等価性判定表に対象関数を不等価関数として登録する。
　以下に、対象関数が部分等価関数を呼び出す関数であるためステップＳ２２３（図２１参照）が実行される具体例を説明する。
　対象関数は、Ｆｕｎｃ＿Ａ＿ｘおよびＦｕｎｃ＿Ａ＿ｙである。
　図２４に、変更前ソースコード２１０を示す。
　図２４の変更前ソースコード２１０は、Ｆｕｎｃ＿Ａ＿ｘが対象関数である場合において、ステップＳ１４３（図９参照）が実行された直後の変更前ソースコード２１０である。
　Ｆｕｎｃ＿Ａ＿ｘには、３つの更新文（２１８、２１９、２１１０）が追加されている。
　図２５に、変更後ソースコード２２０を示す。
　図２５の変更後ソースコード２２０は、Ｆｕｎｃ＿Ａ＿ｙが対象関数である場合において、ステップＳ１４３（図９参照）が実行された直後の変更後ソースコード２２０である。
　Ｆｕｎｃ＿Ａ＿ｙには、３つの更新文（２２７～２２９）が追加されている。
　図２６に、識別子対応表２６０を示す。
　図２６の識別子対応表２６０は、Ｆｕｎｃ＿Ａ＿ｘおよびＦｕｎｃ＿Ａ＿ｙが対象関数である場合において、ステップＳ１４４（図９参照）が実行された直後の識別子対応表２６０である。
　図２４に示すように、Ｆｕｎｃ＿Ａ＿ｘの中の呼び出し先関数はＦｕｎｃ＿Ｂ＿ｘおよびＦｕｎｃ＿Ｃ＿ｘである。そのため、図２６に示すように、Ｆｕｎｃ＿Ａに対応する変更前ソースコードの欄において、呼び出し先関数の欄にＦｕｎｃ＿Ｂ＿ｘおよびＦｕｎｃ＿Ｃ＿ｘが登録されている。
　図２４に示すように、Ｆｕｎｃ＿Ｂ＿ｘに対応する分岐箇所識別子はｃｏｕｎｔ９＿ｘであり、Ｆｕｎｃ＿Ｃ＿ｘに対応する分岐箇所識別子はｃｏｕｎｔ１０＿ｘである。そのため、図２６に示すように、Ｆｕｎｃ＿Ｂに対応する変更前ソースコードの欄において、分岐箇所識別子の欄にｃｏｕｎｔ９＿ｘが登録されている。さらに、Ｆｕｎｃ＿Ｃに対応する変更前ソースコードの欄において、分岐箇所識別子の欄にｃｏｕｎｔ１０＿ｘが登録されている。
　図２５に示すように、Ｆｕｎｃ＿Ａ＿ｙの中の呼び出し先関数はＦｕｎｃ＿Ｂ＿ｙおよびＦｕｎｃ＿Ｃ＿ｙである。そのため、図２６に示すように、Ｆｕｎｃ＿Ａに対応する変更後ソースコードの欄において、呼び出し先関数の欄にＦｕｎｃ＿Ｂ＿ｙおよびＦｕｎｃ＿Ｃ＿ｙが登録されている。
　図２５に示すように、Ｆｕｎｃ＿Ｂ＿ｙに対応する分岐箇所識別子はｃｏｕｎｔ８＿ｙであり、Ｆｕｎｃ＿Ｃ＿ｙに対応する分岐箇所識別子はｃｏｕｎｔ９＿ｙである。そのため、図２６に示すように、Ｆｕｎｃ＿Ｂに対応する変更後ソースコードの欄において、分岐箇所識別子の欄にｃｏｕｎｔ８＿ｙが登録されている。さらに、Ｆｕｎｃ＿Ｃに対応する変更後ソースコードの欄において、分岐箇所識別子の欄にｃｏｕｎｔ９＿ｙが登録されている。
　図２７に、ステップＳ２２１（図２１参照）の後の検証ファイル２５０を示す。
　検証ファイル２５０は、呼び出し文２５２の後に第１除外制御文２５５を含んでいる。さらに、検証ファイル２５０は、呼び出し文２５３の後に第１除外制御文２５６を含んでいる。
　第１除外制御文２５５により、ｃｏｕｎｔ１０＿ｘの値が更新前の値と一致するか判定される。ｃｏｕｎｔ１０＿ｘは、Ｆｕｎｃ＿Ｃ＿ｘの分岐箇所識別子である（図２６参照）。Ｆｕｎｃ＿Ｃ＿ｘは、Ｆｕｎｃ＿Ａ＿ｘの呼び出し先関数であり（図２６参照）、不等価関数である（図２３参照）。
　第１除外制御文２５６により、ｃｏｕｎｔ９＿ｙの値が更新前の値と一致するか判定される。ｃｏｕｎｔ９＿ｙは、Ｆｕｎｃ＿Ｃ＿ｙの分岐箇所識別子である（図２６参照）。Ｆｕｎｃ＿Ｃ＿ｙは、Ｆｕｎｃ＿Ａ＿ｙの呼び出し先関数であり（図２６参照）、不等価関数である（図２３参照）。
　ステップＳ２２２（図２１参照）において、部分検証部１６０は、対象関数が部分等価関数を呼び出す関数であるか判定する。
　Ｆｕｎｃ＿Ａ＿ｘの呼び出し先関数はＦｕｎｃ＿Ｂ＿ｘおよびＦｕｎｃ＿Ｃ＿ｘである（図２６参照）。Ｆｕｎｃ＿Ｂ＿ｘの等価性は部分等価である（図２３参照）。そのため、Ｆｕｎｃ＿Ａ＿ｘは部分等価関数を呼び出す関数である。
　Ｆｕｎｃ＿Ａ＿ｙの呼び出し先関数はＦｕｎｃ＿Ｂ＿ｙおよびＦｕｎｃ＿Ｃ＿ｙである（図２６参照）。Ｆｕｎｃ＿Ｂ＿ｙの等価性も部分等価である（図２３参照）。そのため、Ｆｕｎｃ＿Ａ＿ｙは部分等価関数を呼び出す関数である。
　したがって、対応組がＦｕｎｃ＿Ａ＿ｘとＦｕｎｃ＿Ａ＿ｙとを含んだ組である場合、処理はステップＳ２２３に進む。
　ステップＳ２２３（図２１参照）において、部分検証部１６０は、第２除外制御文を検証ファイルに追加する。
　図２８に、ステップＳ２２３（図２１参照）の後の検証ファイル２５０を示す。
　検証ファイル２５０は、呼び出し文２５２の後に第２除外制御文２５７を含んでいる。さらに、検証ファイル２５０は、呼び出し文２５３の後に第２除外制御文２５８を含んでいる。
　第２除外制御文２５７により、ｃｏｕｎｔ７＿ｘの値が更新前の値と一致するか判定される。ｃｏｕｎｔ７＿ｘは、Ｆｕｎｃ＿Ｅ＿ｘの分岐箇所識別子である（図２６参照）。Ｆｕｎｃ＿Ｅ＿ｘは、Ｆｕｎｃ＿Ｂ＿ｘの呼び出し先関数であり（図２６参照）、不等価関数である（図２３参照）。Ｆｕｎｃ＿Ｂ＿ｘは、Ｆｕｎｃ＿Ａ＿ｘの呼び出し先関数であり（図２６参照）、部分等価関数である（図２３参照）。第２不等価関数が呼ばれていた場合、ｃｏｕｎｔ７＿ｘの値は０から１に更新されている。このとき、ｃｏｕｎｔ７＿ｘの値は等価性判定範囲外（図２８参照）である。つまり、第２除外制御文２５７による判定結果は不一致である。そのため、ｃｏｕｎｔ７＿ｘに対応する入力は等価検証から除外される。
　第２除外制御文２５８により、ｃｏｕｎｔ６＿ｙの値が更新前の値と一致するか判定される。ｃｏｕｎｔ６＿ｙは、Ｆｕｎｃ＿Ｅ＿ｙの分岐箇所識別子である（図２６参照）。Ｆｕｎｃ＿Ｅ＿ｙは、Ｆｕｎｃ＿Ｂ＿ｙの呼び出し先関数であり（図２６参照）、不等価関数である（図２３参照）。Ｆｕｎｃ＿Ｂ＿ｙは、Ｆｕｎｃ＿Ａ＿ｙの呼び出し先関数であり（図２６参照）、部分等価関数である（図２３参照）。第２不等価関数が呼ばれていた場合、ｃｏｕｎｔ６＿ｙの値は０から１に更新されている。このとき、ｃｏｕｎｔ６＿ｙの値は等価性判定範囲外（図２８参照）である。つまり、第２除外制御文２５８による判定結果は不一致である。そのため、ｃｏｕｎｔ６＿ｙに対応する入力は等価検証から除外される。
　図２９に、等価性判定表２４０を示す。
　図２９の等価性判定表２４０は、Ｆｕｎｃ＿Ａ＿ｘおよびＦｕｎｃ＿Ａ＿ｙが部分等価関数である場合の等価性判定表２４０である。
　Ｆｕｎｃ＿Ａに対応する等価性の欄には部分等価が登録されている。
　Ｆｕｎｃ＿Ａ＿ｘの第１不等価関数はＦｕｎｃ＿Ｃ＿ｘである（図２６および図２３参照）。Ｆｕｎｃ＿Ｃ＿ｘの分岐箇所識別子はｃｏｕｎｔ１０＿ｘである（図２６参照）。そのため、Ｆｕｎｃ＿Ａに対応する変更前ソースコードの欄にはｃｏｕｎｔ１０＿ｘが登録されている。
　Ｆｕｎｃ＿Ａ＿ｘの第２不等価関数はＦｕｎｃ＿Ｅ＿ｘである（図２６および図２３参照）。Ｆｕｎｃ＿Ｅ＿ｘの分岐箇所識別子はｃｏｕｎｔ７＿ｘである（図２６参照）。そのため、Ｆｕｎｃ＿Ａに対応する変更前ソースコードの欄にはｃｏｕｎｔ７＿ｘが登録されている。
　同様に、Ｆｕｎｃ＿Ａに対応する変更後ソースコードの欄には、ｃｏｕｎｔ９＿ｙおよびｃｏｕｎｔ６＿ｙが登録されている。
＊＊＊実施の形態１の効果＊＊＊
　等価性検証装置１００は、対象関数内の呼び出し先関数の等価性結果を利用して、不等価な呼び出し先関数を通過するパスを除外した状態で等価性検証を行う。これにより、不等価でないと判定される範囲が拡大される。その結果、不等価な原因、つまり、不具合の原因を解析するための範囲が狭まり、人手による解析時間が短縮される。
　実施の形態２．
　始点関数から終点関数までの呼び出しパスが不等価パスであるか判定するための形態について、主に実施の形態１と異なる点を図３０から図３４に基づいて説明する。
＊＊＊構成の説明＊＊＊
　図３０に基づいて、等価性検証装置１００の構成を説明する。
　等価性検証装置１００は、コールグラフ生成部１１０と制御部１２０と等価性検証部１３０と識別子設定部１４０と部分検証判定部１５０と部分検証部１６０との他に、パス検証部１７０をソフトウェア要素として備える。
　等価性検証プログラムは、コールグラフ生成部１１０と制御部１２０と等価性検証部１３０と識別子設定部１４０と部分検証判定部１５０と部分検証部１６０とパス検証部１７０としてコンピュータを機能させる。
＊＊＊動作の説明＊＊＊
　図３１に基づいて、パス検証方法を説明する。
　パス検証方法は、変更前ソースコードと変更後ソースコードとの一方を対象にして行われる。以下、変更後ソースコードを対象として、パス検証方法を説明する。
　ステップＳ３０１において、受付部１９２は、始点関数識別子と終点関数識別子とを受け付ける。
　始点関数識別子は、始点関数として指定された関数の識別子である。
　終点関数識別子は、終点関数として指定された関数の識別子である。
　始点関数から終点関数までのパスを呼び出しパスという。
　呼び出しパスは、始点関数から終点関数までの関数の呼び出し順を示す。
　例えば、始点関数識別子および終点関数識別子は以下のような手順で受け付けられる。
　まず、パス検証部１７０は、変更後コールグラフ２３２を入力としてＧｒａｐｈｖｉｚを実行することによって、コールグラフ図を生成する。
　Ｇｒａｐｈｖｉｚは、コールグラフ図を生成するためのツールである。
　コールグラフ図は、コールグラフが示す呼び出し関係を表す図である。
　次に、表示部１９３は、コールグラフ図をディスプレイに表示する。
　次に、検証者は、コールグラフ図を参照し、始点関数と終点関数とを決定し、始点関数識別子と終点関数識別子とを等価性検証装置１００に入力する。終点関数識別子の入力が省略された場合、末端の関数の識別子が終点関数識別子として入力されたものとする。
　そして、受付部１９２は、入力された始点関数識別子と終点関数識別子とを受け付ける。
　図３２に、コールグラフ図２７０を示す。
　コールグラフ図２７０は、図６の変更後コールグラフ２３２に対応するコールグラフ図である。
　図３１に戻り、ステップＳ３１０から説明を続ける。
　ステップＳ３１０において、パス検証部１７０は、呼び出しパス毎に第３分岐箇所識別子を抽出する。
　第３分岐箇所識別子は、呼び出しパスに含まれる呼び出し先関数の分岐箇所識別子である。呼び出し先関数の分岐箇所識別子は、呼び出し先関数が呼び出される箇所に対応する分岐箇所識別子である。
　図３３に基づいて、第３分岐箇所識別子の抽出（Ｓ３１０）を説明する。
　ステップＳ３１１において、パス検証部１７０は、始点関数から順に関数を１つ選択する。
　ステップＳ３１２からステップＳ３１５までの説明において、対象関数は、ステップＳ３１１で選択された関数を意味する。
　ステップＳ３１２において、パス検証部１７０は、対象関数が複数の呼び出し先関数を呼び出す関数であるか判定する。
　具体的には、パス検証部１７０は、識別子対応表２６０を用いて以下のように判定を行う。
　まず、パス検証部１７０は、識別子対応表２６０を参照し、対象関数に対応付けられた呼び出し先関数の数を数える。
　そして、パス検証部１７０は、対象関数に対応付けられた呼び出し先関数の数が２以上であるか判定する。
　対象関数に対応付けられた呼び出し先関数の数が２以上である場合、対象関数が複数の呼び出し先関数を呼び出す関数である。
　対象関数が複数の呼び出し先関数を呼び出す関数である場合、処理はステップＳ３１３に進む。
　対象関数が複数の呼び出し先関数を呼び出す関数ではない場合、処理はステップＳ３１６に進む。
　図２６の識別子対応表２６０において、Ｆｕｎｃ＿Ａ＿ｙに対応する呼び出し先関数は、Ｆｕｎｃ＿Ｂ＿ｙとＦｕｎｃ＿Ｃ＿ｙとの２つである。
　したがって、対象関数がＦｕｎｃ＿Ａ＿ｙである場合、処理はステップＳ３１３に進む。
　ステップＳ３１３において、パス検証部１７０は、複数の呼び出し先関数に対応する複数の第３分岐箇所識別子が全て同じであるか判定する。
　具体的には、パス検証部１７０は、識別子対応表２６０を用いて以下のように判定を行う。
　まず、パス検証部１７０は、呼び出し先関数毎に呼び出し先関数に対応する分岐箇所識別子を識別子対応表２６０から抽出する。
　そして、パス検証部１７０は、抽出された全ての分岐箇所識別子が同じであるか判定する。
　複数の呼び出し先関数に対応する複数の分岐箇所識別子が全て同じである場合、処理はステップＳ３１６に進む。
　複数の呼び出し先関数に対応する複数の分岐箇所識別子の少なくともいずれかが他の分岐箇所識別子と異なる場合、処理はステップＳ３１４に進む。
　図２６の識別子対応表２６０において、Ｆｕｎｃ＿Ｂ＿ｙの分岐箇所識別子はｃｏｕｎｔ８＿ｙであり、Ｆｕｎｃ＿Ｃ＿ｙの分岐箇所識別子はｃｏｕｎｔ９＿ｙである。
　したがって、複数の呼び出し先関数がＦｕｎｃ＿Ｂ＿ｙおよびＦｕｎｃ＿Ｃ＿ｙである場合、処理はステップＳ３１４に進む。
　ステップＳ３１４において、パス検証部１７０は、複数の呼び出しパスをパス判定表に登録する。
　パス判定表は、呼び出しパス毎の等価性および第３分岐箇所識別子を管理するためのデータである。
　具体的には、パス検証部１７０は複数の呼び出しパスを以下のように登録する。
　パス検証部１７０は、対象関数を含んだ呼び出しパスがパス判定表に登録されているか判定する。
　対象関数を含んだ呼び出しパスがパス判定表に登録されている場合、パス検証部１７０は、対象関数を含んだ呼び出しパスを複製することによって、複数の呼び出し先関数と同じ数の呼び出しパスをパス判定表に登録する。そして、パス検証部１７０は、それぞれの呼び出しパスに異なる呼び出し先関数を登録する。
　対象関数を含んだ呼び出しパスがパス判定表に登録されていない場合、パス検証部１７０は、呼び出し先関数毎に対象関数と呼び出し先関数とを示す呼び出しパスをパス判定表に登録する。そして、パス検証部１７０は、それぞれの呼び出しパスに異なる呼び出し先関数を登録する。
　ステップＳ３１５において、パス検証部１７０は、複数の分岐箇所識別子をパス判定表に登録する。登録される複数の分岐箇所識別子のそれぞれが第３分岐箇所識別子である。
　具体的には、パス検証部１７０は、ステップＳ３１４で登録された呼び出しパス毎に、呼び出し先関数の分岐箇所識別子を識別子対応表２６０から抽出し、抽出された分岐箇所識別子をパス検証部１７０に登録する。
　ステップＳ３１６において、パス検証部１７０は、未選択の関数が有るか判定する。
　未選択の関数が有る場合、処理はステップＳ３１１に進む。
　未選択の関数が無い場合、第３分岐箇所識別子の抽出（Ｓ３１０）は終了する。
　図３４に、パス判定表２８０を示す。
　図３４のパス判定表２８０は、図３２のコールグラフ図２７０に対応するパス判定表であり、ステップＳ３１０（図３１参照）の後のパス判定表である。
　始点関数は、Ｆｕｎｃ＿Ａ＿ｙであり、終点関数はＦｕｎｃ＿Ｃ＿Ｙ、Ｆｕｎｃ＿Ｄ＿ＹおよびＦｕｎｃ＿Ｅ＿Ｙである。
　Ｎｏ．１の呼び出しパスにおける呼び出し先関数はＦｕｎｃ＿Ｂ＿ｙおよびＦｕｎｃ＿Ｄ＿ｙである。Ｆｕｎｃ＿Ｂ＿ｙの分岐箇所識別子はｃｏｕｎｔ８＿ｙであり、ＦｕｎｃＤ＿ｙの分岐箇所識別子はｃｏｕｎｔ５＿ｙである（図２６参照）。したがって、Ｎｏ．１の呼び出しパスの第３分岐箇所識別子はｃｏｕｎｔ８＿ｙおよびｃｏｕｎｔ５＿ｙである。
　Ｎｏ．２の呼び出しパスにおける呼び出し先関数はＦｕｎｃ＿Ｂ＿ｙおよびＦｕｎｃ＿Ｅ＿ｙである。Ｆｕｎｃ＿Ｂ＿ｙの分岐箇所識別子はｃｏｕｎｔ８＿ｙであり、ＦｕｎｃＥ＿ｙの分岐箇所識別子はｃｏｕｎｔ６＿ｙである（図２６参照）。したがって、Ｎｏ．２の呼び出しパスの第３分岐箇所識別子はｃｏｕｎｔ８＿ｙおよびｃｏｕｎｔ６＿ｙである。
　Ｎｏ．３の呼び出しパスにおける呼び出し先関数はＦｕｎｃ＿Ｃ＿ｙである。Ｆｕｎｃ＿Ｃ＿ｙの分岐箇所識別子はｃｏｕｎｔ９＿ｙである（図２６参照）。したがって、Ｎｏ．３の呼び出しパスの第３分岐箇所識別子はｃｏｕｎｔ９＿ｙである。
　図３１に戻り、ステップＳ３２１から説明を続ける。
　ステップＳ３２１において、パス検証部１７０は、未選択の呼び出しパスを１つ選択する。
　ステップＳ３２２からステップＳ３２４までの説明において、呼び出しパスは、ステップＳ３２１で選択された呼び出しパスを意味する。
　ステップＳ３２２において、パス検証部１７０は、呼び出しパスの第３分岐箇所識別子の少なくともいずれかが、始点関数の第１分岐箇所識別子と始点関数の第２分岐箇所識別子とのいずれかと一致するか判定する。
　具体的には、パス検証部１７０は以下のように判定を行う。
　まず、パス検証部１７０は、呼び出しパスの第３分岐箇所識別子をパス判定表２８０の中の分岐箇所識別子の欄から抽出する。
　次に、パス検証部１７０は、始点関数の第１分岐箇所識別子と始点関数の第２分岐箇所識別子とを等価性判定表２４０の中の変更後ソースコードの欄から抽出する。
　次に、パス検証部１７０は、呼び出しパスの第３分岐箇所識別子毎に第３分岐箇所識別子を始点関数の第１分岐箇所識別子と始点関数の第２分岐箇所識別子とのそれぞれと比較する。
　そして、パス検証部１７０は、比較結果に基づいて、呼び出しパスの第３分岐箇所識別子の少なくともいずれかが、始点関数の第１分岐箇所識別子と始点関数の第２分岐箇所識別子とのいずれかと一致するか判定する。
　呼び出しパスの第３分岐箇所識別子の少なくともいずれかが、始点関数の第１分岐箇所識別子と始点関数の第２分岐箇所識別子とのいずれかと一致するか場合、処理はステップＳ３２３に進む。
　呼び出しパスの全ての第３分岐箇所識別子が、始点関数の第１分岐箇所識別子と始点関数の第２分岐箇所識別子とのいずれとも一致しない場合、処理はステップＳ３２４に進む。
　図３４のパス判定表２８０において、Ｎｏ．１の呼び出しパスの第３分岐箇所識別子はｃｏｕｎｔ８＿ｙおよびｃｏｕｎｔ５＿ｙである。
　始点関数であるＦｕｎｃ＿Ａ＿ｙの第１分岐箇所識別子および第２分岐箇所識別子は、ｃｏｕｎｔ６＿ｙおよびｃｏｕｎｔ９＿ｙである（図２９参照）。
　この場合、全ての第３分岐箇所識別子が第１分岐箇所識別子と第２分岐箇所識別子とのいずれとも一致しないため、処理はステップＳ３２４に進む。
　図３４のパス判定表２８０において、Ｎｏ．２の呼び出しパスの第３分岐箇所識別子はｃｏｕｎｔ８＿ｙおよびｃｏｕｎｔ６＿ｙである。
　始点関数であるＦｕｎｃ＿Ａ＿ｙの第１分岐箇所識別子および第２分岐箇所識別子は、ｃｏｕｎｔ６＿ｙおよびｃｏｕｎｔ９＿ｙである（図２９参照）。
　この場合、第３分岐箇所識別子と第１分岐箇所識別子との間でｃｏｕｎｔ６＿ｙが共通するため、処理はステップＳ３２３に進む。
　図３４のパス判定表２８０において、Ｎｏ．３の呼び出しパスの第３分岐箇所識別子はｃｏｕｎｔ９＿ｙである。
　始点関数であるＦｕｎｃ＿Ａ＿ｙの第１分岐箇所識別子および第２分岐箇所識別子は、ｃｏｕｎｔ６＿ｙおよびｃｏｕｎｔ９＿ｙである（図２９参照）。
　この場合、第３分岐箇所識別子と第２分岐箇所識別子との間でｃｏｕｎｔ９＿ｙが共通するため、処理はステップＳ３２３に進む。
　ステップＳ３２３において、パス検証部１７０は、呼び出しパスをパス判定表に不等価パスとして登録する。
　ステップＳ３２４において、パス検証部１７０は、呼び出しパスをパス判定表に等価パスとして登録する。
　ステップＳ３２５において、パス検証部１７０は、未選択の呼び出しパスが有るか判定する。
　未選択の呼び出しパスが有る場合、処理はステップＳ３２１に進む。
　未選択の呼び出しパスが無い場合、パス検証方法の処理は終了する。
　図３５に、パス検証方法によって得られるパス判定表２８０を示す。
　パス判定表２８０において、Ｎｏ．１の呼び出しパスは不等価関数が呼び出されない等価パスであり、Ｎｏ．２の呼び出しパスおよびＮｏ．３の呼び出しパスは不等価関数が呼び出される不等価パスである。
＊＊＊実施の形態２の効果＊＊＊
　実施の形態１の結果を利用して呼び出しパスの等価性を検証することができる。これにより、不等価でないと判定されるパス（等価パス）の範囲が拡大される。その結果、例えば、等価パスにおいて機能テストケースの生成および出力期待値の指定を省略することが可能となる。そして、検証に要する工数が削減される。
＊＊＊実施の形態の補足＊＊＊
　実施の形態において、等価性検証装置１００の機能はハードウェアで実現してもよい。
　図３６に、等価性検証装置１００の機能がハードウェアで実現される場合の構成を示す。
　等価性検証装置１００は処理回路９９０を備える。処理回路９９０はプロセッシングサーキットリともいう。
　処理回路９９０は、コールグラフ生成部１１０と制御部１２０と等価性検証部１３０と識別子設定部１４０と部分検証判定部１５０と部分検証部１６０とパス検証部１７０と記憶部１９１とを実現する専用の電子回路である。
　例えば、処理回路９９０は、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックＩＣ、ＧＡ、ＡＳＩＣ、ＦＰＧＡまたはこれらの組み合わせである。ＧＡはＧａｔｅ　Ａｒｒａｙの略称であり、ＡＳＩＣはＡｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔの略称であり、ＦＰＧＡはＦｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙの略称である。
　等価性検証装置１００は、処理回路９９０を代替する複数の処理回路を備えてもよい。複数の処理回路は、処理回路９９０の役割を分担する。
　実施の形態は、好ましい形態の例示であり、本発明の技術的範囲を制限することを意図するものではない。実施の形態は、部分的に実施してもよいし、他の形態と組み合わせて実施してもよい。フローチャート等を用いて説明した手順は、適宜に変更してもよい。
　１００　等価性検証装置、１１０　コールグラフ生成部、１２０　制御部、１３０　等価性検証部、１４０　識別子設定部、１５０　部分検証判定部、１６０　部分検証部、１７０　パス検証部、１９１　記憶部、１９２　受付部、１９３　表示部、２１０　変更前ソースコード、２１１～２１９　更新文、２１１０　更新文、２２０　変更後ソースコード、２２１～２２９　更新文、２３１　変更前コールグラフ、２３２　変更後コールグラフ、２３３　関数対応表、２４０　等価性判定表、２５０　検証ファイル、２５１　入力一致文、２５２　呼び出し文、２５３　呼び出し文、２５４　出力一致文、２５５　第１除外制御文、２５６　第１除外制御文、２５７　第２除外制御文、２５８　第２除外制御文、２６０　識別子対応表、２７０　コールグラフ図、２８０　パス判定表、９０１　プロセッサ、９０２　メモリ、９０３　補助記憶装置、９０４　入出力インタフェース、９９０　処理回路。

Claims (9)

  1. 　変更前ソースコードに含まれる関数と変更後ソースコードに含まれる関数との組である対応組毎に、対応組に含まれる関数同士が等価であるか等価性検証によって判定する等価性検証部と、
    　不等価である対応組毎に、対応組が、不等価関数が呼び出される不等価パスと非不等価関数が呼び出される非不等価パスとの両方が含まれる関数を含んだ部分検証組であるか判定する部分検証判定部と、
    　部分検証組毎に、前記不等価パスを除外して前記等価性検証を行うことによって、部分検証組に含まれる関数同士が部分等価であるか判定する部分検証部と
    を備える等価性検証装置。
  2. 　前記等価性検証装置は、前記変更前ソースコードと前記変更後ソースコードとに対してそれぞれのソースコードの中にある分岐箇所毎に分岐箇所識別子を生成する識別子設定部を備え、
    　前記部分検証判定部は、前記変更前ソースコードと前記変更後ソースコートとの少なくとも一方において前記不等価関数が呼び出される箇所に対応する分岐箇所識別子と前記不等価関数ではない関数が呼び出される箇所に対応する分岐箇所識別子とが一致しない場合に、前記対応組が前記部分検証組であると判定する
    請求項１に記載の等価性検証装置。
  3. 　前記等価性検証部は、前記等価性検証の入力となる検証ファイルを生成し、前記検証ファイルを用いて前記等価性検証を行い、
    　前記部分検証部は、前記対応組に含まれる関数の中の不等価パスである第１不等価パスを除外するための第１除外制御文を前記検証ファイルに追加し、前記第１除外制御文が追加された後の検証ファイルを用いて前記等価性検証を行う
    請求項１に記載の等価性検証装置。
  4. 　前記等価性検証装置は、前記変更前ソースコードと前記変更後ソースコードとに対してそれぞれのソースコードの中にある分岐箇所毎に分岐箇所識別子の値を更新する更新文を追加する識別子設定部を備え、
    　前記等価性検証部は、前記対応組に含まれる関数を呼び出す呼び出し文を含んだファイルを前記検証ファイルとして生成し、
    　前記部分検証部は、前記不等価関数が呼び出される箇所に対応する分岐箇所識別子の値が更新前の値と一致するか判定する文を前記呼び出し文の後に前記第１除外制御文として追加し、前記更新文が追加された後の変更前ソースコードと前記更新文が追加された後の変更後ソースコードと前記第１除外制御文が追加された後の検証ファイルとを用いて前記等価性検証を行う
    請求項３に記載の等価性検証装置。
  5. 　前記等価性検証部は、前記等価性検証の入力となる検証ファイルを生成し、前記検証ファイルを用いて前記等価性検証を行い、
    　前記部分検証部は、前記対応組に含まれる関数の中の不等価パスである第１不等価パスを除外するための第１除外制御文を前記検証ファイルに追加し、前記対応組が前記部分検証組であり且つ前記部分検証組に含まれる関数が部分等価関数を呼び出す関数である場合、前記部分等価関数の中の不等価パスである第２不等価パスを除外するための第２除外制御文を前記検証ファイルに追加し、前記検証ファイルを用いて前記等価性検証を行う
    請求項１に記載の等価性検証装置。
  6. 　前記等価性検証装置は、前記変更前ソースコードと前記変更後ソースコードとに対してそれぞれのソースコードの中にある分岐箇所毎に分岐箇所識別子の値を更新する更新文を追加する識別子設定部を備え、
    　前記等価性検証部は、前記対応組に含まれる関数を呼び出す呼び出し文を含んだファイルを前記検証ファイルとして生成し、
    　前記部分検証部は、前記第１不等価パスで呼び出される不等価関数である第１不等価関数が呼び出される箇所に対応する第１分岐箇所識別子の値が更新前の値と一致するか判定する文を前記呼び出し文の後に前記第１除外制御文として追加し、前記第２不等価パスで呼び出される不等価関数である第２不等価関数が呼び出される箇所に対応する第２分岐箇所識別子の値が更新前の値と一致するか判定する文を前記呼び出し文の後に前記第２除外制御文として追加し、前記変更前ソースコードと前記変更後ソースコードと前記検証ファイルとを用いて前記等価性検証を行う
    請求項５に記載の等価性検証装置。
  7. 　始点関数識別子と終点関数識別子とを受け付ける受付部と、
    　前記始点関数識別子で識別される始点関数から前記終点関数識別子で識別される終点関数までの呼び出しパスが不等価パスであるか判定するパス検証部を備える
    請求項６に記載の等価性検証装置。
  8. 　前記パス検証部は、前記呼び出しパスに含まれる呼び出し先関数毎に呼び出し先関数が呼び出される箇所に対応する分岐箇所識別子である第３分岐箇所識別子を抽出し、少なくともいずれかの第３分岐箇所識別子が前記始点関数の前記第１分岐箇所識別子と前記始点関数の前記第２分岐箇所識別子とのいずれかと一致するか判定し、少なくともいずれかの第３分岐箇所識別子が前記始点関数の前記第１分岐箇所識別子と前記始点関数の前記第２分岐箇所識別子とのいずれかと一致する場合に前記呼び出しパスが不等価パスであると判定する
    請求項７に記載の等価性検証装置。
  9. 　変更前ソースコードに含まれる関数と変更後ソースコードに含まれる関数との組である対応組毎に、対応組に含まれる関数同士が等価であるか等価性検証によって判定する等価性検証処理と、
    　不等価である対応組毎に、対応組が、不等価関数が呼び出される不等価パスと非不等価関数が呼び出される非不等価パスとの両方が含まれる関数を含んだ部分検証組であるか判定する部分検証判定処理と、
    　部分検証組毎に、前記不等価パスを除外して前記等価性検証を行うことによって、部分検証組に含まれる関数同士が部分等価であるか判定する部分検証処理と
    をコンピュータに実行させるための等価性検証プログラム。
PCT/JP2017/006598 2017-02-22 2017-02-22 等価性検証装置および等価性検証プログラム WO2018154657A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP17897365.7A EP3570173B1 (en) 2017-02-22 2017-02-22 Equivalence verification apparatus and equivalence verification program
US16/475,865 US10915427B2 (en) 2017-02-22 2017-02-22 Equivalence verification apparatus and computer readable medium
PCT/JP2017/006598 WO2018154657A1 (ja) 2017-02-22 2017-02-22 等価性検証装置および等価性検証プログラム
JP2019500911A JP6567212B2 (ja) 2017-02-22 2017-02-22 等価性検証装置および等価性検証プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/006598 WO2018154657A1 (ja) 2017-02-22 2017-02-22 等価性検証装置および等価性検証プログラム

Publications (1)

Publication Number Publication Date
WO2018154657A1 true WO2018154657A1 (ja) 2018-08-30

Family

ID=63253555

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/006598 WO2018154657A1 (ja) 2017-02-22 2017-02-22 等価性検証装置および等価性検証プログラム

Country Status (4)

Country Link
US (1) US10915427B2 (ja)
EP (1) EP3570173B1 (ja)
JP (1) JP6567212B2 (ja)
WO (1) WO2018154657A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113360182B (zh) * 2021-06-04 2022-12-09 建信金融科技有限责任公司 系统性能诊断的方法和装置
US20230315412A1 (en) * 2022-03-30 2023-10-05 Microsoft Technology Licensing, Llc Scalable behavioral interface specification checking
US11803371B1 (en) * 2022-10-21 2023-10-31 Aurora Labs Ltd. Symbol-matching between software versions

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010204954A (ja) 2009-03-03 2010-09-16 Nec Corp プログラム検証装置、プログラム検証方法、及び検証機能実行用プログラム
WO2015029154A1 (ja) * 2013-08-28 2015-03-05 株式会社日立製作所 ソースコード等価性検証装置、および、ソースコード等価性検証方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060041873A1 (en) * 2004-08-19 2006-02-23 Cisco Technology, Inc. Computer system and method for verifying functional equivalence
US8683441B2 (en) * 2006-01-11 2014-03-25 International Business Machines Corporation Software equivalence checking
US8612951B2 (en) * 2009-04-21 2013-12-17 Oracle International Corporation Method of determining which computer program functions are changed by an arbitrary source code modification
JP5464031B2 (ja) 2010-04-23 2014-04-09 日本電気株式会社 プログラム検証装置、方法及びプログラム
JP2011248561A (ja) 2010-05-26 2011-12-08 Hitachi Ltd 情報変換方法、プログラム、情報変換装置および情報変換システム
US9459986B2 (en) * 2013-08-28 2016-10-04 International Business Machines Corporation Automatic generation of analysis-equivalent application constructs
JP6248008B2 (ja) 2014-07-29 2017-12-13 日立オートモティブシステムズ株式会社 ソフトウェア検証システムおよび制御装置
WO2018193548A1 (ja) * 2017-04-19 2018-10-25 三菱電機株式会社 等価性検証装置および等価性検証プログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010204954A (ja) 2009-03-03 2010-09-16 Nec Corp プログラム検証装置、プログラム検証方法、及び検証機能実行用プログラム
WO2015029154A1 (ja) * 2013-08-28 2015-03-05 株式会社日立製作所 ソースコード等価性検証装置、および、ソースコード等価性検証方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
RUPAK MAJUMDAR: "Compositional Equivalence Checking for Models and Code of Control Systems", 52ND IEEE CONFERENCE ON DECISION AND CONTROL, December 2013 (2013-12-01)
See also references of EP3570173A4

Also Published As

Publication number Publication date
US20190370151A1 (en) 2019-12-05
EP3570173A1 (en) 2019-11-20
EP3570173B1 (en) 2021-10-06
EP3570173A4 (en) 2020-01-08
JP6567212B2 (ja) 2019-08-28
US10915427B2 (en) 2021-02-09
JPWO2018154657A1 (ja) 2019-06-27

Similar Documents

Publication Publication Date Title
US9389849B2 (en) Test case pattern matching
US8997065B2 (en) Automatic modularization of source code
Denti et al. ASGAL: aligning RNA-Seq data to a splicing graph to detect novel alternative splicing events
JP6567212B2 (ja) 等価性検証装置および等価性検証プログラム
US10248409B1 (en) Limiting the effects of source code patches on corresponding native-code patches
US20210049091A1 (en) Software visualization apparatus, software visualization method, and computer readable medium
JP2008191963A (ja) ソースコード検証システム、ソースコード検証方法、およびソースコード検証用プログラム
US20180004635A1 (en) Input discovery for unknown program binaries
JP6559376B2 (ja) テストケース選択装置およびテストケース選択プログラム
WO2019142266A1 (ja) テストケース生成装置、テストケース生成方法およびテストケース生成プログラム
CN111722863A (zh) 风控模型更新方法及装置
US20150082278A1 (en) Clone detection method and clone function commonalizing method
WO2020157795A1 (ja) 試験装置、試験方法および試験プログラム
US11740895B2 (en) Generation of software program repair explanations
WO2018116522A1 (ja) 判定装置、判定方法及び判定プログラム
WO2016189721A1 (ja) ソースコード評価装置及びソースコード評価方法及びソースコード評価プログラム
JP6116983B2 (ja) エントリーポイント抽出装置
EP1868099B1 (en) Bug management tool
WO2024195336A1 (ja) トレーサビリティ情報抽出装置およびトレーサビリティ情報検証装置
CN110709814A (zh) 程序代码生成装置和程序代码生成程序
JP2011034517A (ja) 等価性検証装置、そのデータ処理方法、およびプログラム
TWI730384B (zh) 影像測試方法、裝置、電腦裝置及可讀存儲介質
JPH11282722A (ja) プログラム検証方法
Malburg et al. Mutation based feature localization
JP2023108555A (ja) プログラム修正支援システム、プログラム修正支援方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17897365

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019500911

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017897365

Country of ref document: EP

Effective date: 20190816