JP2014126985A - Source code equivalence verification device, and source code equivalence verification method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To speedily perform equivalence verification on refactoring, performed by a person, through symbol execution without exploding computational complexity.SOLUTION: When equivalence of a source code is verified, two kinds of verification are carried out by structure comparison based upon a structure graph in which a source code is analyzed and symbol execution. When it is determined that a structure is coincident through structure comparison using the structure graph, the symbol execution is not performed. Before the verification by the structure comparison, the structure graph is normalized based upon normalization information in which respective source codes before and after refactoring are determined by refactoring patterns, and when the refactoring is formal, adjustments are made so that the structure is coincident. Further, structure graphs before and after the refactoring which are made abstract are verified through the symbol execution to limit a place where the symbol execution is performed.

Description

  The present invention relates to a source code equivalence verification device and a source code equivalence verification method, and in particular, in software refactoring, the behavior as a program is equivalent by a symbol execution technique in order to prevent the introduction of defects due to refactoring. The present invention relates to a source code equivalence verification apparatus and a source code equivalence verification method suitable for preventing explosive increase in the amount of calculation and quickly verifying the validity of refactoring.

  In recent years, with the development of an information processing society, software systems have penetrated the general society, and the reliability required for software has become extremely high. On the other hand, software is becoming increasingly complex and large-scale due to many years of differential / derivative development, and there is a problem of deterioration in maintainability such as ease of software expansion and ease of understanding.

Refactoring is a method disclosed in Non-Patent Document 1, and is a generic term for methods that improve the design quality of software by changing the internal structure without changing the behavior of the software, reducing complexity. This improves the maintainability.
This refactoring technique is a promising technique for ensuring the maintainability of software that is becoming increasingly complex and large-scale. However, there is a possibility that new defects may be introduced because the source code is changed. . Specifically, there are methods that can be categorized as multiple patterns in refactoring. Each source code change procedure and the conditions for the source code to ensure that the behavior of the software is not changed by the change. Are explicitly or implicitly defined. If the source code is changed without following this change procedure, or if the source code does not comply with such conditions, it is not guaranteed that the behavior of the target software will not change. There may be a bug in the software. Therefore, there is a possibility that the software developer may not perform refactoring because there is a fear that a defect may be mixed in software that has been operating correctly due to the refactoring in the software maintenance stage. Therefore, in order to actively perform refactoring in the software maintenance stage, a method for verifying that there is no problem due to refactoring is required.

  In Non-Patent Document 4, 72 types of refactoring patterns that are typically used (hereinafter simply referred to as “refactoring patterns”) are defined.

  In this specification, it is stated that each source code is “equivalent” that the two source codes have the same external behavior, that is, the same output can be obtained at the same time for the same input. It is defined that the source code before the refactoring is performed and the source code after the refactoring is verified as “equivalence verification”.

  As an equivalence verification method, a method for performing a test only on a portion in which a difference is caused by the source code comparison disclosed in Patent Document 1, and a source code disclosed in Non-Patent Document 2 are expressed in a graph and determined for each refactoring. There are a method for verifying whether the graph satisfies the preconditions, and a method for verifying that the behavior is retained using symbol execution disclosed in Non-Patent Document 3.

JP 2010-67188 A

W. F. Opdyke, “Refactoring: A Program Restructuring Aid in Designing Object-Oriented Application Frameworks”, Technical Report UIUC−DCS−R−92−1759, USA, University of Illinois at Urbana−Champaign, 1992 T. Mens, S. Demeyer, D. Janssens, “Formalising Behavior Preserving Program Transformations”, Proceedings of the First International Conference on Graph Transformation, USA, 2002 S. Person, M. B. Dwyer, S. Elbaum, C. S. Pasareanu, “Differential Symbolic Execution”, Proc. Of ACM SIGSOFT Symposium on the Foundations of Software Engineering 2008, USA, 2008 M. Fowler et al., “Refactoring: Improving the Design of Existing Code”, USA, Addison-Wesley Professional, 1 edition, July 8, 1999

  According to the method disclosed in Patent Document 1, a difference in source code before refactoring and after refactoring is detected. And the test regarding the detected difference part is produced | generated, the produced | generated test is implemented with respect to the source code before and after refactoring, and those results are verified. While this does not require a special process when performing refactoring, there are some problems. Depending on the refactoring location, the impact will spread widely, and the possibility remains that the equivalence cannot be verified by the generated test alone. Even if there is no influence spread and only the difference is verified, there is a possibility that a verification failure may occur due to the test coverage. Equivalence verification by testing is incomplete due to the possibility of verification failure.

  Non-Patent Document 2 discloses a method of expressing a method call relationship of a program in a graph and verifying whether or not a precondition defined for each refactoring is satisfied. In order to realize behavior verification by structural verification, this approach covers the conditions for not affecting the behavior after strictly defining the operation for each refactoring. For this reason, it is essential that the refactoring is automated by a tool, and there is a problem that the refactoring operation itself can be mistaken and cannot be used for verification of manual refactoring.

  Non-Patent Document 3 discloses a technique using symbol execution as a technique for performing equivalence verification on source code before and after refactoring.

  Symbol execution is a technique for comprehensively analyzing the behavior of a program by giving a symbol instead of giving a numerical value as an input of a target program.

Hereinafter, an example of symbol execution will be described with reference to FIG.
FIG. 17 is a diagram showing a source code and a data structure derived therefrom in order to explain an example of symbol execution.

  In symbol execution, the value of an input variable is expressed using a symbol called a symbol variable, and analysis is performed on how the symbol variable is referenced and updated in a program. Here, it is assumed that symbol execution is performed on the function foo described in the source code E001 described in the C language. When performing symbol execution on the source code E001 to be subjected to symbol execution, first, lexical analysis and syntax analysis are performed in the same manner as when compiling normal source code. As a result, a structure graph E002 obtained by extracting a control flow, a control dependency graph, a data dependency graph, and the like from the source code E001 is obtained. In symbol execution, an execution tree E020 is generated using the structure graph E002. Each node in the execution tree E020 is composed of a path constraint expressed by a symbol variable for reaching the node and a variable state in which the value of each variable at that node is expressed by a symbol variable. In the execution tree E020 of FIG. 17, a path constraint is expressed above each node and a variable state is expressed below.

  Details of the generation process of the execution tree E020 will be described below.

  At the start stage of symbol execution, symbol variables are assigned to variables serving as program inputs in the source code E001. In the example of the source code E001, since the global variables a, b, and c are input variables, symbol variables α, β, and γ are assigned to each. On the structure graph E002, in the start state corresponding to the node E003, the execution tree E020 is an execution tree including only a single node of the node E010. The path constraint E010a of the node E010 is true indicating that there is no constraint (the constraint is satisfied for an arbitrary variable state), and the variable state E010b indicates that each variable and the corresponding symbol variable are equal according to the symbol variable assignment. ing.

  On the structure graph E002, the node E004 is executed next to the node E003. Accordingly, a child node E011 of E010 is also generated in the execution tree. For the path constraint E011a and variable state E011b in the child node E011, the node E004 on the structure graph E002 is executed after the path constraint E010a and variable state E010b of the parent node E010 are copied.

  In the node E004, 0 is substituted for the variable a. Therefore, the state for the variable a in the variable state E011b of the node E011 of the execution tree is updated to a = 0.

  On the structure graph E002, the node next to the node E004 is E005. In the node E005, since the variable state is not updated, a new node in the execution tree is not generated. Node E005 is a conditional branch by an if statement. Therefore, the next node in the control flow of the structure graph E002 includes two nodes, a node E006 and a node E007. In the symbol execution, in order to cover all possible control flows, in the conditional branch, a child node corresponding to each branch is generated. That is, E012 is generated as a child node of the node E011 in the execution tree corresponding to the node E006, and E013 is generated as a child node of the node E011 in the execution tree corresponding to the node E007.

  The path constraint E012a of the node E012 of the execution tree is a logical product (AND, & in the figure) of the path constraint E011a of the parent node and the branch condition of the conditional branch. The branch condition at the node E005 is c <0, and since the variable c is expressed as a symbol variable from the variable state E011b, it becomes γ. Therefore, the condition for the conditional branch to be satisfied may be γ <0. I understand. Therefore, γ <0, which is the logical product of true and γ <0, becomes the path constraint E012a in the node E012.

  Next, since the path constraint E013a of the child node E013 corresponds to the case where E013 does not satisfy the branch condition of the conditional branch, the path constraint E011a of the parent node and the negation of the branch condition of the conditional branch (NOT, in the figure) ,!) That is, true! AND with (γ <0)! (Γ <0) is the path constraint E013a of the child node E013.

  The calculation of the variable state E012b of the child node E012 of the node E011 and the variable state E013b of the child node E013 is continued after the variable state E011b of the parent node E011 is copied. In the variable state E012b of the node E012, 0 is substituted for the variable c at the node E006, so the variable state for c is updated to c = 0. In the variable state E013b of the node E013, the value of the variable c is substituted for the variable a in the node E007. At this time, since the variable state of the variable c is the symbol variable γ, the variable state of the variable a is updated to a = γ in the variable state E013b.

  Thereafter, the execution tree is generated by the same procedure as described above. In the control flow, the node next to the node E006 is E008, and this E008 is a conditional branch. Therefore, in the execution tree, two child nodes E014 and E015 are generated for the node E012. The branch condition at the node E008 is (b <0), and this is expressed as a symbolic variable using a variable state (β <0). Therefore, the path constraints of the child nodes E014 and E015 are (β <0) and! Respectively for the path constraint E012a of the parent node E012. It is a logical product of (β <0). In the child node E014, the node E009a on the control flow is executed next. E009a assigns the value of ab to the variable a, and it can be seen from the variable state that the state of the variable a is 0 and the state of the variable b is β, so the state of the variable a is updated to -β. The In the child node E015, the node E009b on the control flow is executed next. E009b assigns the value of a + b to the variable a. Since the state of the variable a is 0 and the state of the variable b is β from the variable state, the state of the variable a is updated to β.

  In the control flow, the node next to the node E007 is E008, and this E008 is a conditional branch. Therefore, in the execution tree, two child nodes E016 and E017 are generated for the node E013. The branch condition at the node E008 is (b <0), and this is expressed as a symbolic variable using a variable state (β <0). Therefore, the path constraints of the child nodes E016 and E017 are (β <0) and! Respectively for the path constraint E013a of the parent node E013. It is a logical product of (β <0). In the child node E016, the node E009a on the control flow is executed next. E009a substitutes the value of a−b for the variable a, and it can be seen from the variable state that the state of the variable a is γ and the state of the variable b is β, so the state of the variable a is γ−β. Updated. In the child node E017, the node E009b on the control flow is executed next. E009b assigns the value of a + b to the variable a. Since the state of the variable a is γ and the state of the variable b is β from the variable state, the state of the variable a is updated to γ + β.

  When the control flow reaches the end of the function for all leaf nodes of the execution tree E020, execution tree generation ends. An execution tree E020 in FIG. 17 indicates an execution tree at the time when the symbol execution for the function foo is completed. The result of symbol execution is a collection of each leaf node of the execution tree at the time when symbol execution is completed (this is referred to as “symbol execution summary”). Any combination of the symbol variables α, β, γ satisfies any path constraint among the leaf nodes in the symbol execution summary. By using the variable state included in the node, the value of each variable after execution of the program can be known from the value of the symbol variable as an input. For example, if the values of variables a, b, and c before execution of function foo are 1, the symbol variable is α = β = γ = 1, which satisfies the path constraint of node E017. It can be seen from the variable state of the node E017 that the values of the variable a after execution of the function foo are a = γ + β = 2, b = β = 1, and c = γ = 1. As described above, symbol execution covers the control paths that a program can take, and the relationship between variable values before and after program execution is a set of input value conditions (path conditions) and output variable states (variable states). It can be said that this is a calculation for obtaining a symbol execution summary that is a set of.

  Symbol definition is executed for each source graph before and after refactoring, and a logically equivalent symbol execution summary is obtained, that is, when the same output is obtained for the same input, as defined above. In addition, it can be determined that the source code is equivalent. As described above, since symbol execution comprehensively analyzes an action sequence that can be taken by a target program, there is no problem of coverage in verification using a test or tool dependency in verification of a precondition. On the other hand, in a program having a repetitive statement or a recursive structure, the execution tree becomes complicated, the amount of calculation is diverged, and it tends to explode. In order to reduce the amount of calculation, it is necessary to limit the range of symbol execution and to limit execution based on preconditions, and the integrity of verification, which is an advantage of symbol execution, is lost.

  In Non-Patent Document 3, attention is paid to the fact that there is a common part between the source codes to be compared, and a contrivance is made to reduce the amount of calculation while maintaining completeness. By expressing the execution result of a common block that has not been changed as a function (uninterpreted function), the amount of computation on the execution tree is prevented from diverging. However, there still remains a case where the calculation amount on the execution tree of the difference portion diverges, and the possibility that the calculation amount explodes remains. In addition, there is no mention of handling programs that interact with the outside world, such as hardware.

  The present invention has been made to solve the above-mentioned problems, and its purpose is to quickly perform the verification of equivalence for manually performed refactoring by symbol execution without exploding the amount of calculation. It is to provide a source code equivalence verification method that can be performed.

  The source code equivalence verification apparatus of the present invention has a CPU and a storage device, and causes the CPU to execute a program stored in the storage device, thereby verifying equivalence before and after the change of the source code. A source code input means for inputting the source code before the change, the source code after the change, a change type pattern input means for inputting the change type pattern information of the change of the source code, and the pre-change For each of the source code and the changed source code, the source code information before the change, the source code information generating means for generating the changed source code information, and the normal defined for the source code change type pattern Normalization source code information before change and source code information after change are normalized, each source code is normalized Information, normalization means for generating post-change source code normalization information, pre-change source code normalization information, structure comparison means for comparing the structure of post-change source code normalization information, and pre-change source code normalization Information and symbol execution means for symbol-execution of the modified source code normalization information and symbol execution means for comparing the result of symbol execution to determine equivalence between the source code before change and the source code after change And abstraction means for abstracting and reducing the source code information.

  Then, the structure comparison means compares the structure of the source code normalization information before the change with the structure of the source code normalization information after the change, and when it is determined that the structures match, the symbol execution means Do not perform symbol execution on the information and the changed source code normalization information.

  On the other hand, when the structure comparison means compares the structure of the source code normalization information before the change with the structure of the source code normalization information after the change, and determines that the structures do not match, the abstraction means Normalization information and post-change source code normalization information are abstracted to generate pre-change source code abstraction information and post-change source code abstraction information. Symbol execution is performed on the abstraction information and the changed source code abstraction information.

  According to the source code equivalence verification apparatus of the present invention, the source code information normalization corresponding to the refactoring pattern information is applied to the source code information before refactoring and the source code information after refactoring, the structure is compared, Judge whether source code is equivalent or not by mismatch. Then, when it is determined that the structures match by comparing the structure, it is determined that the source code is equivalent without performing the symbol execution, so that there is an advantage that it is not necessary to execute the symbol which increases the amount of calculation. . In addition, if it is determined in the structure comparison that the structures do not match, the source code information is abstracted, the source code information is reduced, and the abstracted source code information is subjected to symbol execution. It is possible to verify equivalence. Therefore, according to the present invention, it is possible to verify source code equivalence without exploding the amount of calculation while maintaining integrity.

  According to the present invention, it is possible to provide a source code equivalence verification method that can be performed quickly without exploding the amount of computation when equivalence verification for refactoring performed manually is performed by symbol execution. .

It is a hardware block diagram of the source code equivalence verification apparatus which concerns on one Embodiment of this invention. It is a software block diagram of the source code equivalence verification apparatus which concerns on one Embodiment of this invention. It is the figure which showed the function of the whole source code equivalence verification apparatus which concerns on one Embodiment of this invention, and a data flow. It is a flowchart which shows the process of the source code equivalence verification apparatus which concerns on one Embodiment of this invention. FIG. 5 is a diagram illustrating details of functions of an input unit 1100 and a data flow. It is the figure which showed the detail and data flow of the function of the normalization part 1200. FIG. 11 is a diagram showing details of functions and data flow of a structure comparison verification processing unit 1300. FIG. 10 is a diagram showing details of functions and a data flow of a symbol execution execution determination unit 1700. FIG. 11 is a diagram illustrating details of functions and a data flow of a symbol execution verification processing unit 1400. It is a figure which shows the example of the source code before and after refactoring (the 1). It is a figure which shows the example of the source code information corresponding to the source code before and after refactoring (the 1). It is a figure which shows the example of the normalization performed with respect to source code information. It is a figure which shows the example of the source code before and after refactoring (the 2). It is a figure which shows the example of the source code information corresponding to the source code before and after refactoring (the 2). It is a figure which shows the example of the abstracted source code information. It is the example which showed the execution tree when carrying out the symbol execution with respect to the source code before refactoring, and the source code after refactoring. In order to explain an example of symbol execution, it is a diagram showing a source code and a data structure derived therefrom.

  Hereinafter, an embodiment of the present invention will be described with reference to FIGS.

[Configuration and processing of source code equivalence verification device]
The configuration and processing of the source code equivalence verification apparatus according to an embodiment of the present invention will be described below with reference to FIGS.
First, the hardware configuration of the source code equivalence verification apparatus according to an embodiment of the present invention will be described with reference to FIG.
FIG. 1 is a hardware configuration diagram of a source code equivalence verification apparatus according to an embodiment of the present invention.

  The hardware configuration of the source code equivalence verification apparatus according to an embodiment of the present invention is realized by, for example, a general personal computer as shown in FIG.

  The source code equivalence verification apparatus 1000 includes a central processing unit (CPU) 101, a main storage device 102, a network I / F 103, a graphic I / F 104, an input / output I / F 105, and an auxiliary storage device I / F 106 connected by a bus. It has become a form.

  The CPU 101 controls each part of the source code equivalence verification apparatus 100, loads the source code equivalence verification program 200 to the main storage device 102, and executes it.

  The main storage device 102 is generally composed of a volatile memory such as a RAM, and stores a program executed by the CPU 101 and data to be referred to.

  The network I / F 103 is an interface for connecting to the external network 150.

  The graphic I / F 104 is an interface for connecting a display device 120 such as an LCD (Liquid Crystal Display).

  The input / output I / F 105 is an interface for connecting an input / output device. In the example of FIG. 1, a keyboard 131 and a mouse 132 of a pointing device are connected.

  The auxiliary storage device I / F 106 is an interface for connecting an auxiliary storage device such as an HDD (Hard Disk Drive) 141 and a DVD drive (Digital Versatile Disk) 142.

  The HDD 141 has a large storage capacity, and stores a source code equivalence verification program 200 for executing this embodiment.

  The DVD drive 142 is a device that writes data to or reads data from an optical disk such as a DVD or a CD. The source code equivalence verification program 200 is, for example, one provided by a CD-ROM. Can be installed.

  The source code equivalence verification apparatus 1000 according to the present embodiment installs the source code equivalence verification program 200 in the personal computer as described above and executes each function.

Next, the software configuration of the source code equivalence verification apparatus according to an embodiment of the present invention will be described with reference to FIG.
FIG. 2 is a software configuration diagram of the source code equivalence verification apparatus according to the embodiment of the present invention.

  As shown in FIG. 2, the software configuration of the source code equivalence verification apparatus includes a program equivalence verification program 200. The program equivalence verification program 200 includes a source code analysis module 201, which is a subroutine, and a structure graph generation / update. The module 202 includes a structural graph analysis module 203, an execution tree generation module 204, a symbol execution execution module 205, an input / output module 206, and a database module 207.

  Note that the program equivalence verification program 200 is application scene software that operates on an OS (Operating System), and includes the OS and library program as a software configuration of the source code equivalence verification device, but is omitted in the figure. .

  The program equivalence verification program 200 includes a source code analysis module 201, which is a subroutine, a structure graph generation / update module 202, a structure graph analysis module 203, an execution tree generation module 204, a symbol execution execution module 205, an input / output module 206, and a database module. 207.

  The source code analysis module 201 is a module that performs lexical analysis / syntactic analysis of the source code and extracts information necessary for generating the structure graph.

  The structure graph generation / update module 202 is a module that generates or updates a structure graph based on the analysis result of the source code analysis module 201.

  The structure graph analysis module 203 is a module that analyzes the graph structure of the structure graph.

  The execution tree generation module 204 is a module that generates an execution tree based on the analysis result of the structural graph analysis module 203.

  The symbol execution execution module 205 is a module that executes symbol execution on the execution tree generated by the execution tree generation module 204.

  The input / output module 206 is a module for inputting / outputting necessary data from the outside.

  The database module 207 is a module for accessing various databases.

Next, functions and processing of the source code equivalence verification apparatus according to an embodiment of the present invention will be described with reference to FIGS.
FIG. 3 is a diagram showing the functions and data flow of the entire source code equivalence verification apparatus according to an embodiment of the present invention.
FIG. 4 is a flowchart showing processing of the source code equivalence checking apparatus according to the embodiment of the present invention.
FIG. 5 is a diagram illustrating details of functions of the input unit 1100 and a data flow.
FIG. 6 is a diagram showing details of functions of the normalization unit 1200 and a data flow.
FIG. 7 is a diagram showing details of the function and data flow of the structure comparison verification processing unit 1300.
FIG. 8 is a diagram showing details of functions and data flow of the symbol execution execution determination unit 1700.
FIG. 9 is a diagram showing details of functions and data flow of the symbol execution verification processing unit 1400.

  As shown in FIG. 3, the source code equivalence verification apparatus 1000 according to the present embodiment is applied to two source codes of a pre-refactoring source code 0001 and a post-refactoring source code 0002, and a source code 0001 before refactoring. Based on the input of refactoring pattern input information 0003, which is input information related to the refactoring pattern, the equivalence between the source code 0001 before refactoring and the source code 0002 after refactoring is verified. The processing of the source code equivalence verification apparatus 1000 according to the present embodiment is performed by the hardware such as the PC shown in FIG. 1 executing the source code equivalence verification program 200 shown in FIG.

  First, the input unit 1100 receives input of the input source code 0001 before refactoring (S101 in FIG. 4). In the post-refactoring source code input step S102, the input unit 1100 receives the post-refactoring source code 0002 (S102). Further, the input unit 1100 receives input of the refactoring pattern input information 0003 (S103).

  Hereinafter, the details of the function of the input unit 1100 and its processing will be described with reference to FIG.

  As shown in FIG. 5, the source code 0001 before refactoring is received by the source code input unit 1101 in the input unit 1100, lexical analysis and syntax analysis of the source code are performed, and converted into source code information 1001 before refactoring. The refactored source code 0002 is also received by the source code input unit 1101 in the input unit 1100, lexical analysis and syntax analysis of the source code is performed, converted into refactored source code information 1002, and stored in the storage unit 1600. The refactoring pattern input information 0003 is received by the refactoring pattern input unit 1102 in the input unit 1100, converted into refactoring pattern information 1003 representing the refactoring pattern type, and stored in the storage unit 1600.

  Next, the source code information 1001 before refactoring and the source code information 1002 after refactoring are compared, and a change place in the structure of the source code is specified (S1041).

  Then, the normalization unit 1200 uses the information stored in the storage unit 1600 to normalize the pre-refactoring source code information 1001 and the post-refactoring source code information 1002 (S1042).

  Here, normalization means that the source code information of the refactored source code is converted into source code information corresponding to the source code equivalent to the source code. This normalization is performed in a form suitable for the subsequent structure comparison step S1043 and symbol execution step S1045.

Hereinafter, details of the function of the normalization unit 1200 and its processing will be described with reference to FIG.
The pre-refactoring source code information 1001 and the post-refactoring source code information 1002 are input to the change location specifying unit 1201 of the normalization unit 1200. On the other hand, change location specifying information 1007b corresponding to the refactoring pattern information 1003 stored in the normalization DB 1601 is acquired. Then, the changed part specifying unit 1201 compares the source code information, refers to the changed part specifying information 1007b corresponding to the refactoring pattern information 1003, specifies the changed part on the structure of the source code, and generates the changed part information 1004. (S1041).

  Next, normalization information 1007a indicating a normalization method corresponding to the refactoring pattern input information 1003 is acquired from the normalization DB 1601 of the storage unit 1600 (S1042). The normalization DB 1601 stores normalization information 1007a corresponding to each refactoring pattern. The source code normalization unit of the normalization unit 1200 normalizes the pre-refactoring source code information 1001 based on the acquired normalization information 1007a to generate pre-refactoring normalization source code information 1005. Further, the source code normalization unit of the normalization unit 1200 normalizes the post-refactoring source code information 1002 based on the normalization information 1007a to generate post-refactoring normalization source code information 1006.

  Next, the structure comparison verification processing unit 1300 compares the structures of the pre-refactoring normalized source code information 1005 and the post-refactoring normalized source code information 1006 to verify whether the structures are the same (step S1042).

  Hereinafter, details of the function of the structure comparison verification processing unit 1300 and its processing will be described with reference to FIG.

  The structure comparison / verification processing unit 1300 receives the pre-refactored normalized source code information 1005 and the post-refactored normalized source code information 1006, and compares whether the structures of the two normalized source code information match. If they match, information that matches is generated as the structure comparison result 1008. If they do not match, information that does not match is generated as the structure comparison result 1008 (S1043).

  Next, the symbol execution execution determination unit 1700 determines whether or not symbol execution should be performed (S1047). Here, when it is determined as a result of the structure comparison step S1043 that the structures match, the process goes to the equivalent non-equivalent output step S105. When it is determined that the structures do not match, the source code abstraction step Go to S1044.

  Details of the function of the symbol execution execution determination unit 1700 and its processing will be described below with reference to FIG.

  The symbol execution execution determination unit 1700 receives the structure comparison result 1008. If the structure is “match” in the structure comparison result 1008, the symbol execution execution determination unit 1700 proceeds to an equivalent non-equivalent output step S105, and the output unit 1500 has an equivalent source code. As a result, the verification result 0004 is output.

  When the result that the source code is equivalent is output, the user can determine that the refactoring performed is valid.

  The symbol execution execution determination unit 1700 receives the structure comparison result 1008, and generates a symbol execution start instruction 1009 if the structure is “mismatched” in the structure comparison result 1008.

  Next, the source code information is abstracted (S1044).

  Here, the abstraction of source code information means that source code information is kept in a state where the same input is given to each source code information and the same result is obtained when symbol execution is performed. Means contraction.

  Next, symbol execution is performed on the abstracted source code information before refactoring and the abstracted source code information after refactoring (S1045).

  When the results of symbol execution are compared and the same output (symbol execution summary) is obtained for the same input, it is determined that the original source code is equivalent, and the output (symbol execution summary) is different. Then, it is determined that the original source code is not equivalent (S1046), and an equivalent non-equivalent result is output.

  Here, when the result that the source code is equivalent is output, the user can determine that the refactoring performed is valid, and when the result that the source code is non-equivalent is output, The user can determine that the refactoring performed is inappropriate. When the user determines that the refactoring that has been performed is inappropriate, the user can review the refactoring that has been performed and start work to correct it.

  The symbol execution verification processing unit 1400 receives the symbol execution start instruction 1008 and starts the source code abstraction step S1044. In the source code abstraction step 1044, the abstraction method information stored in the abstraction DB 1602 of the storage unit 1600 is used to receive the pre-refactoring normalized source code information and the changed part information 1004, perform the abstraction, and perform the pre-refactoring. Generate abstract source code information. Also, in the source code abstraction step 1044, using the abstraction method stored in the abstraction DB 1602 of the storage unit 1600, the refactored normalized source code information and the changed part information 1004 are received, abstracted, and refactored. Post-abstraction source code information is generated. Here, the abstraction method information stored in the abstraction DB replaces the part of the source code information after the normalization with the part not related to the changed part information 1004 and the part of the loop or recursive call, and thereafter. This is information relating to a method of converting the part not related to the changed part information 1004 and the part of the loop or recursive call so as not to execute the symbol at the symbol execution step S1045.

  In the symbol execution step S1045, the symbol execution unit 1402 performs symbol execution on the pre-refactoring abstracted source code information 1403 and the post-refactoring abstracted source code information 1404. Get results. In the symbol execution result comparison step S1046, the symbol execution result comparison unit 1407 compares and determines whether or not the refactoring sign execution result 1405 is the same as the post-refactoring symbol execution result. In the symbol execution result comparison unit 1407, when the refactoring execution result 1405 and the post-refactoring symbol execution result are the same, the process proceeds to the equivalent non-equivalent output step S105, and the output unit 1500 outputs the verification result 0004 as equivalent. . In the symbol execution result comparison unit 1407, when the refactoring execution result 1405 and the post-refactoring symbol execution result are different, the process proceeds to the equivalent non-equivalent output step S105, and the verification result 0004 is output to the output unit 1500 as non-equivalent. Let

  According to the source code equivalence verification apparatus of the present embodiment, before performing symbol execution that tends to explode, the structure comparison is performed after normalization for each source code information before and after each refactoring, When it is determined that the source code as the source is equivalent, symbol execution is not performed.

  Also, if the source code is determined to be non-equivalent in the structure comparison, the source code information is abstracted and the source code information is reduced before performing symbol execution. The amount can be reduced.

[Specific example of processing of source code equivalence verification device (example when it is determined that the structure matches)]
Hereinafter, a specific example of processing of the source code equivalence checking apparatus according to the embodiment of the present invention will be described with reference to FIG. 4 and FIGS. 10 to 12.
This example is an example in which it is determined in the symbol execution execution determination process of FIG. 4 that the structure of the structure graph as the source code information matches.
FIG. 10 is a diagram illustrating an example of source code before and after refactoring (part 1).
FIG. 11 is a diagram illustrating an example of source code information corresponding to source codes before and after refactoring (part 1).

  FIG. 12 is a diagram illustrating an example of normalization performed on source code information.

  In this example, a case where refactoring based on the refactoring pattern ExtractMethod is performed as refactoring for the source code will be described. In the refactoring pattern ExtractMethod, the same processing is extracted as a function in the source code that performs the same processing in a plurality of places, and the place where the same processing is performed in a plurality of places is replaced with a call to the extracted function. This is a refactoring pattern to share existing source code. This refactoring pattern ExtractMethod is also used as a refactoring that extracts a part of the source code in the function as another function in order to improve the readability of the function when the description amount of the source code is large in one function.

  Hereinafter, an example in which source code is refactored using a refactoring pattern ExtractMethod will be described with reference to FIG.

  The source code C001 is a source code before application of the refactoring pattern ExtractMethod, and is a program for substituting 10 in the main function for the global variable global_var. A source code obtained by applying a refactoring pattern ExtractMethod to the source code C001 is C002. In the source code C002, the assignment statement to the global variable “global_var = 10;” in the source code C001 is extracted as the function foo, and the portion that was the description part of the global_var = 10; is converted into a call to the function foo.

  First, steps of the source code input S101 before refactoring, the source code input S102 after refactoring, and the refactoring pattern S103 in FIG. 4 in the example of refactoring shown in FIG. 10 will be described.

  In the input unit 1100, the source code input unit 1101 accepts the source code 0001 before refactoring and the source code 0002 after refactoring, and generates corresponding source code information before refactoring 1001 and source code information after refactoring. Here, the source code 0001 before refactoring corresponds to the source code C001, and the source code 0002 after refactoring corresponds to the source code C002.

  The source code equivalence verifying apparatus 1000 has a structure in which the input source code 0001 before refactoring and the source code 0002 after refactoring are lexically analyzed and parsed by the source code input unit 1101 and handled internally as shown in the example of FIG. Converted to a graph. In the example of the refactoring pattern ExtractMethod, the source code C001 is converted into a structure graph M001, and the source code C002 is converted into a graph M002. Here, the source code information 1001 before refactoring corresponds to the structure graph M001, and the source code information 1002 after refactoring corresponds to the structure graph M002.

  In the input unit 1100, the refactoring pattern input unit 1102 receives the refactoring pattern input information 0003 and generates refactoring pattern information 1003. In this example, for example, when the refactoring pattern input information 0003 is a character string “ExtractMethod” representing the refactoring pattern ExtractMethod or a selection number in the menu on the screen, the refactoring pattern ExtractMethod is indicated internally as the refactoring pattern information 1003. Generate code.

Next, the step of change location identification S1041 in FIG. 4 will be described.
In the changed part specifying unit 1201 of the normalizing unit 1200, the corresponding changed part specifying information 1007b in the normalization DB 1601 is referred to from the source code information 1001 before refactoring, the source code information 1002 after refactoring, and the refactoring pattern information 1003. It identifies where the source code has been changed, and outputs changed part information 1004. In the example of the refactoring pattern ExtractMethod, the refactoring pattern ExtractMethod compares the declaration of the functions of the source code information 1001 before refactoring and the source code information 1002 after refactoring because of the feature that the function increases in the source code information 1002 after refactoring. A function that appears only in the post-source code information 1002 is specified as a changed part. In FIG. 11, in the structure graph M001 of the source code information 1001 before refactoring and the structure graph M002 of the source code information 1002 after refactoring, the entry indicating the function is compared and the foo function of the entry indicated by the node M003 is increased. Therefore, the node M003 and the node M004 that calls the foo function correspond to the changed part information 1004.

Next, the steps of source code normalization S1042 in FIG. 4 will be described.
In the source code normalization unit 1202 of the normalization unit 1200, normalization is performed using the corresponding normalization information 1007a in the normalization DB 1601 from the changed part information 1004 and the pre-refactoring source code information 1001, and the normalization before refactoring Source code information 1005 is generated. The post-refactoring source code information 1002 is similarly normalized to generate post-refactoring normalized source code information 1006. FIG. 12 shows an example of the source code normalization unit 1202 in the refactoring pattern ExtractMethod. First, normalization information 1007a corresponding to the refactoring pattern ExtractMethod, which is the refactoring pattern information 1003, is acquired from the normalization DB 1601. According to the normalization information 1007a corresponding to ExtractMethod of the refactoring pattern information 1003, the normalization method is the source code when the function of the changed portion 1004 in the extracted source code information 0002 after refactoring is returned to the base after inline expansion. It is to make the structure which represents.

  The changed part 1004 in FIG. 12 is a node M003 and a node M004 in the structure graph M002 of the source code information 1002 after refactoring. Since these nodes are the extracted function foo created by the refactoring, the function foo is changed. When normalized and restored, a structure graph M006 is obtained. This becomes normalized source code information 1006 after refactoring. Since the normalization source code information 1005 before refactoring is not normalized with respect to the refactoring pattern ExtractMethod, the structure graph M001 of the source code information 0001 before refactoring in FIG. M005.

Next, the step of the structure comparison S1043 in FIG. 4 will be described.
The structure comparison verification processing unit 1300 receives the pre-refactored normalized source code information 1005 and the post-refactored normalized source code information 1006, compares the structure of the source code information, and generates the result as the structure comparison result 1008. In the example shown in FIG. 10 in which refactoring is performed using the refactoring pattern ExtractMethod, the structure comparison verification processing unit 1300 includes two graphs: a graph M005 of the pre-refactoring normalized source code information 1005 and a graph M006 of the normalized refactoring source code information 1006. Since the nodes have the same structure and the same nodes, the source code C001 and the source code C002 are determined to be equivalent as the structure comparison result 1008.

Next, the step of the symbol execution execution determination S1047 in FIG. 4 will be described.
In the example according to FIG. 10 in which the refactoring pattern ExtractMethod has been refactored, the symbol execution determination unit 1700 determines that the sources before and after the refactoring are equivalent as the structure comparison result 1008, and thus the process proceeds to the equivalent non-equivalent output step S105. The output unit 1500 receives the result that the structure comparison verification processing unit 1300 determines to be equivalent, and outputs that the result is equivalent as the verification result 0004.

  In the example shown in FIG. 10 in which the symbol execution execution determination unit 1700 performs refactoring using the refactoring pattern ExtractMethod, the source code before and after the refactoring is equivalent to each other by the conversion by the normalization unit 1200 and the determination processing of the structure comparison verification processing unit 1300. Therefore, the symbol execution verification processing unit 1400 does not require calculation for symbol execution, and enables quick equivalence determination without unnecessarily increasing the amount of calculation.

[Specific example of processing of source code equivalence verification device (example when judged as structure mismatch)]
Hereinafter, a specific example of processing of the source code equivalence checking apparatus according to the embodiment of the present invention will be described with reference to FIG. 4 and FIG. 13 to FIG.
This example is an example in which it is determined in the symbol execution execution determination process of FIG. 4 that the structure of the structure graph as the source code information does not match.
FIG. 13 is a diagram illustrating an example of source code before and after refactoring (part 2).
FIG. 14 is a diagram illustrating an example of source code information corresponding to source codes before and after refactoring (part 2).
FIG. 15 is a diagram illustrating an example of abstracted source code information.
FIG. 16 is an example showing an execution tree when symbol execution is performed on the source code before refactoring and the source code after refactoring.

  In this example, a case will be described in which refactoring for organizing assignments to variables without changing a conditional expression in the source code is performed as refactoring for the source code.

  FIG. 13 shows the source code C003 before refactoring and the source code C004 after refactoring, and the assignment to variables is arranged between the source code C003 and the source code C004 without changing the conditional expression in the source code. Refactoring has been applied. Specifically, in the source code C003 before refactoring, a value is substituted for the variable a at the location indicated by the source code portion C005, and the value of the variable a (left side) is used at the location indicated by the source code portion C006. Is calculated and assigned to the variable a (right side). In the source code C004 after refactoring, a value is assigned to the variable b at the location indicated by the source code portion C007, and the value is calculated using the value of the variable b at the location indicated by the source code portion C008 and assigned to the variable a. ing. Before and after refactoring, the conditional expressions present at the location indicated by the source code portion C005 and the location indicated by the source code portion C007 match the conditional expressions present at the location indicated by the source code portion C006 and the location indicated by the source code portion C008. However, the variables used are changed, and the source code C004 has a smaller number of source code lines and higher readability. The refactoring shown in the example of FIG. 13 does not correspond to the 72 types of refactoring patterns described in Non-Patent Document 4, and is not registered in the database as a pattern even in the source code equivalence verification apparatus 1000 of this embodiment. To do.

  First, the pre-refactoring source code input S101 and the post-refactoring source code input S102 of FIG. 4 in the refactoring example shown in FIG. 13 will be described. In this refactoring example, source code 0001 before refactoring corresponds to source code C003, and source code 0002 after refactoring corresponds to source code C004. In the input unit 1100, the source code input unit 1101 accepts the source code 0001 before refactoring and the source code 0002 after refactoring, and generates corresponding source code information before refactoring 1001 and source code information after refactoring. In the refactoring example of FIG. 13, the source code input unit 1101 accepts the source code C003 as the source code 0001 before refactoring, performs lexical analysis and syntax analysis, and converts it into the structure graph M008 of FIG. 14 as source code information 1001 before refactoring. . The source code input unit 1101 accepts the source code C004 as the refactored source code 0002, performs lexical analysis and syntax analysis, and converts it into the structure graph M009 of FIG. Here, the source code information 1001 before refactoring corresponds to the structure graph M008, and the source code information 1002 after refactoring corresponds to the structure graph M009.

  Next, the step of S103 for inputting information related to the refactoring pattern will be described.

  In the input unit 1100, the refactoring pattern input unit 1102 receives the refactoring pattern input information 0003 and generates refactoring pattern information 1003. In this refactoring example, since it is assumed that the refactoring pattern is not registered, a character string indicating “not applicable” and a menu selection number are input to the refactoring pattern input unit 1102, and the refactoring pattern input unit is As the refactoring pattern information 1003, a code indicating “not applicable” is generated.

Next, the step of change location identification S1041 in FIG. 4 will be described.
In the change part specifying part 1201 of the normalization part 1200, the part on the source code is specified from the source code information 1001 before refactoring and the source code information 1002 after refactoring, and the change part information 1004 is output. In this refactoring example, the structure graph M008, which is the source code information 1001 before refactoring, is compared with the structure graph M009, which is the source code information 0002 after refactoring, and the function foo and the function var exist in both. Since there is no difference and there is a difference in the foo function, the changed part identifying unit 1201 outputs the inside of the foo function as the changed part information 1004. In this example, since the refactoring pattern is “not applicable”, the changed part specifying information 1007b in the normalization DB 1601 is not referred to, and the changed part is specified only by analyzing the structure of the structure graph.

  Next, the steps of source code normalization S1042 in FIG. 4 will be described.

  In the source code normalization unit 1202 of the normalization unit 1200, normalization is performed using the normalization method of the corresponding normalization information 1007a in the normalization DB 1601 from the changed portion information 1004 and the source code information 1001 before refactoring. , Normalization source code information 1005 before refactoring is generated. The post-refactoring source code information 1002 is similarly normalized, and post-refactoring normalized source code information 1006 is generated. In this refactoring example, normalization information corresponding to “not applicable” which is the refactoring pattern information 1003 is acquired from the normalization DB 1601. Here, since the normalization information corresponding to “N / A” which is the refactoring pattern information 1003 has no conversion, the source code normalization unit 1202 relates to the pre-refactoring source code information 1001 and the post-refactoring source code information 1002. Without changing anything, normalization source code information 1005 before refactoring and normalized source code information 1006 after refactoring are output. Since it has not been converted by the normalization unit 1202, the pre-refactoring normalized source code information 1005 is the structure graph M008 in FIG. 14, and the post-refactoring normalized source code information is the structure graph M009 in FIG.

Next, the step of the structure comparison S1043 in FIG. 4 will be described.
The structure comparison verification processing unit 1300 receives the pre-refactored normalized source code information 1005 and the post-refactored normalized source code information 1006, compares the structure of the source code information, and generates a structure comparison result 1008. In this refactoring example, the graph M008 of the pre-refactored normalization source code information 1005 and the structure graph M009 of the post-refactored normalization source code information 1006 are compared, and the graph structure is clearly different. Are determined to be inconsistent.

Next, the symbol execution execution determination step S1047 of FIG. 4 will be described.
In this refactoring example, the symbol execution execution determination unit 1700 generates a command for a symbol execution start instruction 1009 because the source code is determined to be non-equivalent as the structure comparison result 1008.

Next, the source code abstraction step S1044 of FIG. 4 will be described.
When the symbol execution verification processing unit 1400 receives the symbol execution start instruction 1009, the abstraction unit 1401 uses the change location information 1004 and the abstraction information 1010 in which the abstraction method of the abstraction DB 1602 is recorded, and normalizes before refactoring. The source code information 1005 and the refactored normalized source code information 1006 are abstracted. In the abstraction information 1603 of the abstraction DB 1601, an appropriate abstraction method is recorded corresponding to the changed part information 1004. In this refactoring example, the change location information 1004 is known to be inside the function foo, and therefore, in the source code excluding the function foo from the abstract DB 1601, functions that have no difference before and after the refactoring are used as variables. Abstraction information 1603 describing a method of abstraction by conversion is acquired. In the abstraction unit 1401, a method of abstracting a function that is not different between before and after refactoring by converting it into a variable is represented by a graph M008 of the pre-refactored normalized source code information 1005 and a graph M009 of the normalized source code information 1006 after refactoring. FIG. 15 shows the result of application to. In the structure graph M008 of the normalization source code information 1005 before refactoring in FIG. 14, the function var of the node M010 is not different due to the refactoring. Therefore, the abstraction is performed as the variable v together with the node M011 where the function var is called. , And converted as shown in the structure graph M014 of FIG. However, this abstraction requires that there is no Data Dependency (data dependency) between the node M010 and other nodes. The graph M009 of the post-refactoring normalized source code information 1006 in FIG. 14 is similarly abstracted and converted into a control flow graph M015. The abstraction unit 1401 outputs the control flow graph M014 as abstracted source code information 1403 before refactoring and the control flow graph M015 as abstracted source code information 1404 after refactoring. Here, it is noted that this abstraction reduces the amount of calculation when nodes are cut and each symbol is executed in each of the structure graphs M008 and M009.

Next, the step of symbol execution S1045 of FIG. 4 will be described.
In the symbol execution verification processing unit 1400, after abstraction is performed in the abstraction unit 1401, the symbol execution unit 1402 performs symbol processing on each of the pre-refactoring abstraction source code information 1403 and the post-refactoring abstraction source code information 1404. The execution is executed, and as a result, the refactoring sign execution result 1405 and the refactored symbol execution result 1406 are generated. In this refactoring example, the result of symbol execution of the pre-refactoring abstraction information 1403 and the post-refactoring abstraction information 1404 by the symbol execution unit 1402 is as shown in FIG. In this refactoring example, the pre-refactoring abstraction information 1403 corresponds to the structure graph M014 in FIG. 15, and when symbol execution is performed on the structure graph M014, an execution tree E100 in FIG. 16 is generated. Further, E101, E102, E103, and E104, which are symbol execution summaries in the execution tree E100 of FIG. 16, are the refactoring execution results 1405 for the pre-refactoring abstraction information 1403. The post-refactoring abstraction information 1404 corresponds to the structure graph M015 of FIG. 15 in the refactoring example of FIG. 4. When symbol execution is performed on the structure graph M015, an execution tree E200 in FIG. 16 is generated. Also, symbol execution summaries E201, E202, E203, and E204 in the execution tree E200 of FIG. 16 become the post-refactoring symbol execution result 1406 for the post-refactoring abstraction information 1404.

Next, the step of the symbol execution result comparison S1046 of FIG. 4 will be described.
The symbol execution result comparison unit 1407 of the symbol execution verification processing unit 1400 compares the refactoring sign execution result 1405 and the post-refactoring symbol execution result 1406 to determine whether the source code before and after the refactoring is equivalent or non-equivalent. In the refactoring example of FIG. 13, the refactoring previous execution results 1405 are E101, E102, E103, and E104, and the post-refactoring symbol execution results 1405 are E201, E202, E203, and E204. When these two symbol execution results are compared, the path constraints and variable states of the E101 and E201 pairs, the E102 and E202 pairs, the E103 and E203 pairs, and the E104 and E204 pairs match, respectively. The symbol execution result comparison unit 1407 determines that the source code is equivalent and sends it to the equivalent non-equivalent output unit. At this time, there is a structural difference between the symbol execution tree E100 before refactoring and the symbol execution tree E200 after refactoring, but the final symbol execution summaries of symbol execution match. Judge that the source code is equivalent.

Next, the steps of the equivalent non-equivalent output S105 in FIG. 4 will be described.
The output unit 1500 receives the result that the symbol execution comparison unit 1407 determines that the source code is equivalent, and outputs that the source code is equivalent as the verification result 0004. Thus, the user can determine that the refactoring is appropriate.

  In this example, the determination in S1047 causes a structural difference on the structure graph that is the source code information. Therefore, it is necessary to execute symbols to verify that the source code is equivalent. Since the abstraction is performed and the source code information is reduced, the amount of calculation in symbol execution can be reduced.

0001 ... Source code before refactoring 0002 ... Source code after refactoring 0003 ... Refactoring pattern 0004 ... Verification result 1000 ... Source code equivalence verification device 1100 ... Input unit 1200 ... Normalization unit 1300 ... Structural comparison verification processing unit 1400 ... Symbol execution verification processing Unit 1500 ... output unit 1600 ... storage unit 1700 ... symbol execution execution determination unit 1001 ... source code information 1002 before refactoring ... source code information 1003 after refactoring ... refactoring pattern information 1004 ... changed part information 1005 ... normalization source code information 1006 before refactoring ... Normalized source code information after refactoring 1007a ... Normalization information 1007b ... Change location specifying information 1008 ... Structure comparison result 1009 ... Symbol execution start instruction 1 10 ... abstraction information 1101 ... source code input unit 1102 ... refactoring pattern input unit 1201 ... change location specifying unit 1202 ... source code normalization unit 1401 ... abstraction unit 1402 ... symbol execution unit 1403 ... abstraction source code information 1404 before refactoring ... Refactoring abstracted source code information 1405 ... Refactoring previous execution result 1406 ... Refactored symbol execution result 1407 ... Symbol execution result comparison unit 1601 ... Normalization database 1602 ... Abstraction database S101 ... Source code input step S102 before refactoring ... Refactoring Post source code input step S103 ... Refactoring pattern input information input step S1041 ... Change location specifying step S1042 ... Source code normalization step S1043 ... Structure comparison step S1044 ... Source code abstraction step S1045 ... Symbol execution step S1046 ... Symbol execution result comparison step S1047 ... Symbol execution execution determination step S105 ... Equivalent non-equivalent output step C001 ... Source code C002 before refactoring application ... Refactoring Source code C003 after application ... Source code C004 before refactoring application ... Source code C005 ... after refactoring application ... First half of source code in function foo in C003 ... Second half of source code in function foo in C003 ... C004 The first half of the source code in the function foo at C008 ... C008 ... the second half of the source code in the function foo at C004 ... a source code for explaining symbol execution E002 ... Source code structure graph E003 ... Node E004 indicating entry of function foo in structure graph ... E003 transition destination node E005 in structure graph ... E004 transition destination node E006 in structure graph ... E005 in structure graph Branch destination node E007... E005 branch destination node E008 in the structure graph E006 and 7 transition destination node E009a in the structure graph E008 branch destination node E009b in the structure graph E008 branch destination node in the structure graph E010 ... E003 corresponding to E003 path constraint E010b of E010 ... E010 variable state E011 ... E004 corresponding to execution tree nodes E011a ... E011 path constraint E011b ... E011 change Execution tree nodes E012a to E006 corresponding to the state E012 to E006 Path constraints E012b to E012 variable states E013 to E007 Corresponding to the execution tree nodes E013a to E007 path constraints E013b to E013 variable states E014 to E006 This corresponds to E009a when passing through the execution tree node E017 ... E007 corresponding to E009 when passing through the execution tree node E016 ... E007 corresponding to E009a when passing through the execution tree node E015 ... E006 corresponding to E009. Execution tree node E020 ... symbol execution execution tree E100 ... symbol execution execution tree E101 of source code information before refactoring application included in symbol execution summary in E100 ... included in symbol execution summary in E100 Node E103 ... Node included in symbol execution summary in E100 ... Node included in symbol execution summary in E100 ... Node included in symbol execution summary in source code information after application of refactoring E201 ... Node included in symbol execution summary in E200 E202 ... Node included in symbol execution summary in E200 ... Node included in symbol execution summary in E200 ... Node included in symbol execution summary in E200 M001 ... Structure graph of source code before application of refactoring M002 ... After application of refactoring Source code structure graph M003... Node M004 indicating a function added by refactoring. Node M005 calling a function added by refactoring. Normalized structure graph M006 of source code information before application of tulling ... Normalized structure graph M007 of source code information after application of refactoring ... Link M008 as a result of function expansion by normalization ... Source before application of refactoring Code structure graph M009 ... Structure graph of source code after applying refactoring M010 ... Calling function var in M008 Node M011 ... Calling function var in M008 Node M012 ... Calling function var in node M013 ... M009 showing function var Node M014 ... abstracted structure graph of source code information before applying refactoring M015 ... abstracted structure graph of source code information after applying refactoring M016 ... M014 Node indicating a kick abstracted portion

Claims (4)

A source code equivalence verification device that has a CPU and a storage device and verifies equivalence before and after the change of the source code by causing the CPU to execute a program stored in the storage device,
Source code input means for inputting the source code before the change and the source code after the change,
Change type pattern input means for inputting the change type pattern information of the change of the source code;
Source code information generating means for generating source code information before change and source code information after change for each of the source code before change and the source code after change,
Reference is made to defined normalization information for the source code change type pattern, the source code information before change and the source code information after change are normalized, source code normalization information before change and source after change, respectively. Normalization means for generating code normalization information;
Structure comparison means for comparing the source code normalization information before change and the structure of the source code normalization information after change,
Symbol execution means for performing symbol execution of the source code normalization information before change and the source code normalization information after change,
A source code equivalence verification apparatus comprising: equivalence determination means for comparing the results of symbol execution by the symbol execution means to determine equivalence of the pre-change source code and the post-change source code.   When the structure comparison means compares the structure of the pre-change source code normalization information with the structure of the post-change source code normalization information and determines that the structures match, the symbol execution means The source code equivalence verification apparatus according to claim 1, wherein symbol execution is not performed on the code normalization information and the changed source code normalization information. Furthermore, it has an abstraction means for abstracting and reducing the source code information,
When the structure comparison means compares the structure of the source code normalization information before the change with the structure of the source code normalization information after the change and determines that the structures do not match, the abstraction means Performing abstraction of each of the previous source code normalization information and the changed source code normalized information, and generating the pre-change source code abstraction information and the changed source code abstraction information,
2. The source code equivalence verification apparatus according to claim 1, wherein the symbol execution means performs symbol execution on the pre-change source code abstraction information and the post-change source code abstraction information. Source code equivalence verification by a source code equivalence verification device that has a CPU and a storage device, and verifies equivalence before and after the change of the source code by causing the CPU to execute a program stored in the storage device A method,
A source code input step for inputting the source code before the change and the source code after the change,
A change type pattern input step of inputting change type pattern information of the source code change;
A source code information generating step for generating source code information before change and source code information after change for each of the source code before change and the source code after change;
Normalization information defined with respect to the source code change pattern is referred to, the source code information before change and the source code information after change are normalized, and source code normalization information before change and source code after change, respectively. A normalization step for generating normalization information;
A structure comparison step for comparing the structure of the source code normalization information before the change and the structure of the source code normalization information after the change;
A symbol execution step for performing symbol execution of the pre-change source code normalization information and the post-change source code normalization information;
An equivalence determination step of comparing the result of symbol execution by the symbol execution means to determine equivalence of the source code before change and the source code after change;
Abstraction for generating the pre-change source code abstraction information and the post-change source code abstraction information by abstracting each of the pre-change source code normalization information and the post-change source code normalization information And having steps
When the structure comparison step compares the structure of the pre-change source code normalization information with the structure of the post-change source code normalization information and determines that the structures match, the symbol execution step determines the source before change Do not perform symbol execution on the code normalization information and the source code normalization information after the change,
The structure comparison step compares the structure of the pre-change source code normalization information and the structure of the post-change source code normalization information, and when the structure is determined to be inconsistent, executes the abstraction step, For each of the source code normalization information before change and the source code normalization information after change, the source code abstraction information before change and the source code abstraction information after change are generated,
A source code equivalence verification method, wherein in the symbol execution step, symbol execution is performed on the pre-change source code abstraction information and the post-change source code abstraction information.

Images