JP2022119668A - Code change method and code change program - Google Patents

Abstract

A code modification method and program capable of determining a connection relationship between an AST node of a modification target program code and an AST node of a post-modification subgraph based on a pattern. A method for modifying code based on a code modification pattern extracted from a program dependency graph of a program before and after modification, comprising an abstract syntax tree (modified AST) of program code to be modified, and In each abstract syntax tree (post-change AST) of the program code, a map node having a node of a pre-change subgraph or a post-change subgraph and having a correspondence between the change target AST and the post-change AST is set as the root node or leaf node. Identify the modified derived subtree and the modified derived subtree, add the modified derived subtree to the modified AST from which the modified derived subtree is deleted, and add the boundary node in the modified derived subtree to the deleted modified AST node. [Selection drawing] Fig. 30

Description

The present invention relates to a code modification method and a code modification program.

A code change method and a code change program are one function included in a development support program that supports program development. During program development, similar changes may be made to multiple locations in the source code. For example, if there is an API (Application Programming Interface) version upgrade or change in the source code, you can change the location of the API usage all at once, or fix a bug in the source code. , and so on.

Making similar changes to different locations in the source code is called systematic edit. Systematic edits can occur at the same or different locations in different versions of the source code development history, or at different locations in the same version.

If there are many places to be changed in systematic editing, omission of changes will occur and the work cost of code rewriting will increase. In order to solve such problems, systematic editing patterns (hereinafter referred to as code change patterns, editing patterns, editing patterns, or simply patterns) are collected or extracted from the source code of the past development history, and the patterns are Use it to automate code change detection and code changes, as well as similar code change tasks. Such code changes can assist in program development.

The process flow of change support and automatic correction based on systematic editing is, for example, (1) mining code change patterns from a group of source code development histories, and (2) detecting the application points of the code change patterns in the program to be changed. and (3) changing the code of the detected application location based on the code change pattern.

The aforementioned code change pattern is represented by, for example, changes in PDG (Program Dependence Graph). Then, from a set of change graphs, which are graphs representing changes in the PDG, frequent subgraphs are mined as code change patterns. By using a change graph that expresses changes in PDG, it is possible to express code change patterns that consider the semantic connection of the program, for example, it is more flexible than using an AST (Abstract Syntax Tree) editing script. Can express code change patterns.

For example, the change graph of PDG is: (1) convert the source program before and after the code change into AST; Convert the code before and after to fgPDG (fine-grained PDG), express the fgPDG before and after the change side by side, and (4) based on the correspondence between AST nodes, the fgPDG before and after the change. It is generated by giving correspondence information between nodes.

Frequent subgraphs in multiple changegraphs generated from the development history are mined as code change patterns. A code change pattern has a pre-change subgraph, a post-change subgraph, and a correspondence (map) between nodes in both graphs. Then, from the fgPDG of the change target program code, a subgraph that matches the pre-change subgraph of the code change pattern is detected as a pattern application location. Then, the pattern application portion of the change target program code is changed to the post-change subgraph of the code change pattern. Code modification using this code modification pattern is pattern-based code modification processing.

The following patent documents describe methods for supporting program editing. In addition, non-patent literature describes expressing code change patterns as PDG changes.

Japanese translation of PCT publication No. 2011-513824 JP 2008-225932 A

Graph-based Mining of In-the-Wild, Fine-grained, Semantic Code Change Patterns, Hoan Nguyen, Tien N. Nguyen, Danny Dig, Son Nguyen, Hieu Tran, Michael Hilton, International Conference on Software Engineering, 2019

Code changes based on the above patterns are difficult to do at the node level of fgPDG. This is because, unlike AST nodes, fgPDG nodes do not have a one-to-one correspondence with source code. Therefore, if the code change processing based on the pattern is performed at the node level of fgPDG, it is difficult to connect the fgPDG node of the program code to be changed and the node of the post-change subgraph of the code change pattern.

Therefore, the pattern-based code modification process is done at the node level of the AST. However, even in the code change processing based on the pattern at the node level of the AST, there are cases where the connection relationship between the AST node of the program code to be changed and the AST node of the post-change subgraph of the code change pattern cannot be determined.

Therefore, the purpose of the first aspect of the present embodiment is a pattern-based code change process that can determine the connection relationship between the AST node of the program code to be changed and the AST node of the post-change subgraph of the code change pattern. An object of the present invention is to provide a code change method and a code change program.

A first aspect of the present embodiment is a code change pattern having pre-change sub-graphs and post-change sub-graphs extracted from pre-change program dependency graphs and post-change program dependency graphs of pre-change program code and post-change program code. A method of code-modifying program code to be modified based on
In each of the AST to be changed which is an abstract syntax tree (hereinafter referred to as AST) of the program code to be changed that matches the subgraph before change and the AST after change which is the AST of the program code after change having the subgraph after change ,
Identifying a modified derived subtree and a modified derived subtree having a node of the pre-modification subgraph or the post-modification subgraph and having, as a root node or a leaf node, a map node having a correspondence between the modification target AST and the post-modification AST. death,
deleting the modified derived subtree from the modified AST;
adding the modified derived subtree to the deleted modified AST;
A code modification method comprising a process of connecting boundary nodes in the modified derived subtree with nodes in the deleted modified AST.

According to the first aspect, in pattern-based code change processing, a code change method and a code change program capable of determining a connection relation between an AST node of a program code to be changed and an AST node of a post-change subgraph of a code change pattern can be provided.

FIG. 10 is a diagram showing an example of systematic editing; FIG. 10 is a diagram showing an example of a flowchart of code change support and automatic correction by systematic editing; FIG. 10 is a diagram showing a flowchart of processing for mining code change patterns from a change graph showing changes in PDG. FIG. 10 is a flowchart of detailed processing for mining code change patterns as changes in PDG; FIG. 4 is a diagram showing an example AST for an example source program; FIG. 4 is a diagram showing a specific example of the correspondence relationship between an AST before code change, an AST after code change, and both ASTs. FIG. 10 is a diagram showing an example of fgPDG converted from the code of the source program; FIG. 10 is a diagram showing an example of a change graph; FIG. FIG. 10 is a diagram showing an example of extracting subgraphs having a frequency equal to or higher than a predetermined frequency from a plurality of changegraphs as code change patterns; FIG. 10 is a diagram showing an example of detection of an application location of a code change pattern and code change; 1 is a diagram showing a configuration example of a development support device that changes code based on patterns according to the present embodiment; FIG. It is a figure which shows the schematic flowchart of the code|cord|chord change process in this Embodiment. FIG. 10 is a diagram illustrating pattern application location detection and code change processing in fgPDG; FIG. 10 is a diagram showing a specific example of pattern application location detection processing S2 in fgPDG; FIG. 10 is a diagram showing a specific example of a problem of the pattern-based code change processing S3 in the AST. FIG. 4 is a diagram showing a flowchart of code change processing by AST in this embodiment. FIG. 10 is a flowchart of pattern-based code change processing executed for a plurality of code change patterns, a plurality of pattern application locations, and a plurality of change graphs; Fig. 10 shows a flow chart of generating a minimal guided subtree MIDS; FIG. 10 is a diagram showing a flowchart of processing for obtaining A(M _H ) by pattern-based code modification. FIG. 11 is a diagram for explaining a specific example of deletion processing S51; FIG. 11 is a diagram for explaining a specific example of an addition process S52; (a) is a diagram showing the process of determining the connection relationship of boundary nodes when the root node is a mapped node. (a) is a diagram showing a specific example of determination processing of the connection relationship of boundary nodes when the root node is a mapped node. (a) is a diagram showing a specific example of determination processing of the connection relationship of boundary nodes when the root node is a mapped node. (b) is a diagram showing the process of determining the connection relationship of boundary nodes when the root node is an unmapped statement node. (b) is a diagram showing a specific example of determination processing of the connection relationship of boundary nodes when the root node is an unmapped statement node. (c) A diagram showing the process of determining the connection relationship of border nodes when the leaf node is a mapped node. (c) is a diagram showing a specific example of determination processing of the connection relationship of boundary nodes when the leaf node is a mapped node. (c) is a diagram showing a specific example of determination processing of the connection relationship of boundary nodes when the leaf node is a mapped node. (c) is a diagram showing a specific example of determination processing of the connection relationship of boundary nodes when the leaf node is a mapped node. FIG. 3 is a diagram showing an example of a user screen of the development support device 1 that performs systematic editing according to the present embodiment;

Hereinafter, the embodiments will be described using the Java language (Java is a registered trademark of Oracle and its affiliates) as an example, but the embodiments are not limited to the Java language, and can be applied to C language and other languages. Applicable. In the following, as a background, the technique of mining systematic edit and code change patterns will be described first, and then mining of code change patterns in the embodiment will be described.

[Code change support/automatic correction based on systematic edit]
FIG. 1 is a diagram showing an example of systematic editing. In the figure, the horizontal axis indicates the version numbers v1 to v3 of the development history, and the source programs SP1 to SP4 corresponding to the respective version numbers v1 to v3 are indicated.

As mentioned above, during program development, similar changes may be made to multiple locations in the source code. For example, if the version of API in the source code is upgraded or changed, change the location where the API is used all at once, or when fixing a bug in the source code, change the location of the same type of bug all at once. , etc. Adding similar changes to different locations in the source code is called systematic editing. A systematic edit may occur at the same or different place in different versions, or at different places in the same version, in the development history of the source code.

In FIG. 1, each of the source programs SP1 to SP4 includes sentences beginning with "-" to be deleted and sentences beginning with "+" to be inserted (both underlined). In this example, API method File.read() is changed to API method IO.read(). This code change is made at different locations in the different versions of the source programs SP1-SP3.

In the example of FIG. 1, a processor that executes a code change program based on a code change pattern selects API method Mine the systematic edit pattern (code change pattern) of changing from File.read() to API method IO.read(). Then, the processor performs similar code changes on the newly developed source program SP4 based on the mined code change patterns.

FIG. 2 is a diagram showing an example of a flowchart of code change support and automatic correction by systematic editing. Systematic editing (systematic code editing) has a process S1 of mining code change patterns 11 that occur more frequently than a predetermined frequency from a development history group 10 containing a plurality of developed source codes. An example of code change pattern 11 is a code change pattern that changes from the API method File.read( ) in the example of FIG. 1 to the API method IO.read( ). Here, a method is a function of JAVA (registered trademark). Use functions such as methods as code change units.

Furthermore, the systematic code change includes a process S2 of detecting a code change pattern application location 14 that matches the code change code change pattern 11 in the change target program 12, and a code change pattern application location 14 in the change target program 12. and a process S3 of changing the code based on the code change pattern. The present embodiment relates to improvement of the code change processing S3 based on the code change pattern.

Code change patterns are represented by line- or token-level changes in the source program, AST editing scripts, program dependency graph (PDG) changes, and so on. Here, a token is the minimum unit of a program that cannot be further decomposed, and programming statements are composed of a plurality of tokens. Also, the AST editing script expresses the difference between source codes as the difference between ASTs. In the present embodiment, code change patterns expressed by changes in PDG are targeted. Changes in PDG have the advantage of being able to express change patterns that consider the semantic connection of programs, and can express code change patterns that occur frequently in the code change history more flexibly than the other two representations. .

FIG. 3 is a diagram showing a flowchart of processing for mining code change patterns from a change graph showing changes in PDG. A change graph is a graph calculated from differences in methods of a program before code change and a program after code change. The code change pattern mining process is for each version in the development history (S10), for each changed method (S11), and for calculating the change graph CGm from the change difference of the changed method m (S12). repeat. Then, in the mining process, frequent subgraphs with a predetermined frequency or more are mined from the calculated changegraph group (S13). This frequent subgraph corresponds to the code change pattern.

[Detailed processing for mining code change patterns as PDG changes]
FIG. 4 is a flowchart of detailed processing for mining code change patterns as changes in PDG. The flowchart of FIG. 4 is a flowchart of the code change pattern mining process S1 of FIG. 2, and the processes S20 to S23 in FIG. 4 correspond to the process of calculating the change graph CGm from the change difference of the method m in FIG. . Hereinafter, the flowchart of FIG. 4 will be described while showing a specific example.

FIG. 4 , S20: In code change pattern mining processing, a plurality of source codes in the development history group 10 are each converted into ASTs and stored in the AST group 50 .

FIG. 5 is a diagram showing an example AST for an example source program. An example of the source program SP10 includes a method statement send(readLines(“a.csv”)) within the block { } of the main method m(). FIG. 5 shows an example of the AST of this source program SP10. The AST is obtained by analyzing the source code based on the syntax structure defined by the programming language and expressing it in a tree structure. In general, the AST is in a state in which elements that have no meaning in terms of programming language, such as spaces in the source code, are removed. Each node in the AST has a one-to-one relationship with a semantic element in the source code.

In the AST example of FIG. 5, the abbreviation of the syntax element type is shown at the beginning of each node. The types of abbreviations are as follows.
MD: method declaration
BLK: block (Java block)
ES: expression statement
MI: method invocation
A: Assignment
SN: simple name
L: literal (fixed value)

In the AST of FIG. 5, as nodes, method declaration MD: m(), block BLK: {...}, expression statement ES: send(...), method call MI: send(...), name SN: send , method call MI: readLines(...), name SN: readLines, fixed value L: "a.csv". Nodes in the direction of arrows between nodes are child nodes, and nodes in the direction opposite to the arrows are parent nodes.

FIG. 4, S21: In the code change pattern mining process, an AST difference calculation algorithm calculates the correspondence 51 between ASTs before and after the code change.

FIG. 6 is a diagram showing a specific example of the correspondence relationship between the AST before code change, the AST after code change, and both ASTs. ASTb before the code change (before) is the same as in FIG. After the code change (after) ASTa is the AST of the source code after the source code of ASTb is changed from the sentence at the beginning of the line to the sentence at the beginning of the line, as shown in the code difference CD1. be.

The AST difference calculation algorithm synthesizes multiple similarity criteria, such as node type similarity, tree structure similarity, etc., to identify corresponding sets of nodes. For example, the AST difference calculation algorithm assigns a correspondence relationship (map edge) between nodes to a set of nodes in which both the node type similarity and the tree structure similarity are 0.7 or higher. Node SN: readLines and node SN: readCSV in FIG. are the same as 0, a map edge indicating the correspondence between the two nodes is given. The other two map edges are also given because they are equally similar. Diff/TS, for example, is known as an AST difference calculation algorithm.

As described above, the AST difference calculation algorithm assigns map edges that indicate correspondence only between nodes that satisfy the correspondence criteria (similarity above a certain level).

FIG. 4 , S22: In the mining process for code change patterns, the code before and after the change is converted into a fine-grained PDG (fgPDG: fine-grained Program Dependence Graph) and stored in the fgPDG group 52 .

FIG. 7 is a diagram showing an example of fgPDG converted from the code of the source program. Source program SP11 has an assignment statement n = graph.getName() in main method m(). The PDG is a graphical representation of elements such as statements and expressions in the program code and the dependencies between the elements. In the case of normal PDG, statements and conditional expressions are used for element nodes, and data dependencies and control dependencies are used for dependencies between nodes. On the other hand, in fine-grained PDG (fgPDG), expressions and operators with finer units than sentences and conditional expressions are used for nodes, and receive (recv: receive), parameter (para: parameter), Subdivided data dependence and control dependence such as define (def: definition) and control (cont: control) are used.

Unlike normal PDG, fine-grained PDG can express data dependence and control dependence between codes that are more subdivided than statements and conditional expressions, and code change patterns where only a part of a statement or conditional expression is changed. Can be easily extracted.

fgPDG converted from code SP11 of the source program shown in FIG. have a def.

FIG. 4, S23: In the code change pattern mining process, map edges between AST nodes are added to the fgPDG before and after the change respectively converted from the code before and after the change to generate a change graph, and the change graph is accumulated in the change graph group 53. .

FIG. 8 is a diagram showing an example of a change graph. The pre-change program code SP11 and the pre-change fgPDGb converted therefrom are the same as in the example of FIG. On the other hand, in the program code SP12 after change, the assignment statement n = graph.getName() of the program code SP11 before change is changed to n = resolve(graph). The assignment statement n = graph.getName() before the change is an instruction that the method getName() returns the name for the instance graph and assigns it to the variable n. On the other hand, in the assignment statement n = resolve(graph) after the change, the method getName takes the expression graph as an argument (parameter). As a result, fgPDGa for the code after the change differs from fgPDGb for the code before the change in that the data dependency between the argument graph and the method getName becomes the parameter para.

The change graph CG1 is a graph representation in which a map edge indicating the correspondence relationship between the nodes of fgPDGb for the code before change and fgPDGa for the code after change is added to fgPDGb for the code before change. This map edge is obtained by adding the map edge corresponding to the nodes in the change graph CG1 from the node correspondence map calculated for the pre-change code ASTb and the post-change code ASTa (not shown).

The change graph shown in FIG. 8 is generated for each of a plurality of program codes before and after changes in the development history group.

Fig. 4, S24: In the code change pattern mining process, based on the correspondence (map edge) between PDG nodes in the change graph, out of the subgraphs having PDG nodes with map edges, predetermined Subgraphs that are included more than frequently are extracted as code change patterns. As a result, one or more code change patterns 11 are generated.

FIG. 9 is a diagram showing an example of extracting subgraphs having a predetermined frequency or more from a plurality of changegraphs as code change patterns. FIG. 9 shows source programs SP1 and SP2 of versions v1 and v2 of FIG. 1, and change graphs CG11 and CG12 for the source code before and after the change. The change graph CG11 in version v1 is fgPDGb and It has fgPDGa and map edges between nodes “=”. Similarly, the change graph CG12 in version v2 is fgPDGb and fgPDGa for the assignment statement u=File.read(path) before the code change, the assignment statement u=IO.read(path) after the code change, and the node” =” with map edges between.

A common portion of the two change graphs CG11 and CG12 is extracted as a frequent subgraph, that is, a code change pattern PTN.

As shown in S2 and S3 in Fig. 2, based on the mined code change pattern, the application location of the code change pattern in the program code before the code change is detected (S2), and the code at the detected application location is detected. Code modification (S3) is performed based on the code modification pattern.

FIG. 10 is a diagram showing an example of detection of a code change pattern application location and code change. FIG. 10 shows the source program SP4 of version v4 of FIG. 1 and the code change pattern PTN. As shown in the after source program SP4, the assignment statement t=File.read(“b.txt”) in the source program SP4 needs to be changed in the same way as versions v1 and v2.

First, from the code of the source program SP4 before the code change, the code edge t=File.read(“b.txt”) that matches the PDG graph before the change of the code change pattern PTN is It is detected as an application part (S2). Then the code t=File.read(“b.txt”) in the apply location is changed to the code t=IO.read(“b.txt” based on the PDG graph after the code change pattern PTN. ). In other words, the node connected to the node "=" where the map edge is formed is replaced from "File.read" to "IO.read".

As described above, by using the code change pattern PTN mined from the change graph group, it is possible to detect omission of changes in a program whose code has not been changed, and to automatically change the code.

[Code change based on pattern in this embodiment]
FIG. 11 is a diagram showing a configuration example of a development support device that changes code based on patterns according to the present embodiment. The development support device 1 is a server, personal computer, tablet terminal, or the like. The development support device 1 has a processor (CPU) 30, a main memory 32, a network interface 34, a bus 36, and an auxiliary storage device 20 which is a large-capacity storage. The storage 20 stores a development support program 21, a development history group (source code group) 10, a code change pattern 11, a program to be changed 12 systematically changed by the code change pattern, and a changed program 13, respectively. .

The development support program 21 that supports program development includes a code change pattern mining program 21A that mines code change patterns, and a pattern application portion detection program 21B that detects a portion of the program to be changed that matches the pre-change subgraph of the code change pattern. , and a code modification program 21C for generating a modified program 13 by modifying the code at a part of the pattern application location of the modification target program 26 based on the code modification pattern.

The network interface 34 is accessible from the client terminal devices 40 and 42 via a network NW such as the Internet. A user who wants to receive support for program development accesses the development support device 1 from a client terminal device, and receives support for code change pattern mining, pattern application location detection, and code change based on the code change pattern.

[Detection of pattern application location and code change processing]
FIG. 12 is a diagram showing a schematic flowchart of code change processing according to the present embodiment. As described with reference to FIG. 2, the processor 30 executing the development support program generates a pattern that matches the pre-change code of the code change pattern 11 in the change target program 12 based on the code change pattern 11 mined from the fgPDG change graph. The application point 14 is detected. In other words, in the process of detecting the pattern application location in the target program, based on the fgPDG code change pattern mined from the fgPDG change graph, in the fgPDG graph of the target program, before the change of the fgPDG code change pattern , which matches the subgraph of fgPDG.

Next, as shown in FIG. 12, the processor executes code modification based on the code modification pattern 11 (S3). This code change is called pattern-based code change. Pattern-based code changes S3 are done in the AST graph, not in the fgPDG graph. As mentioned above, the AST is a tree of nodes that correspond one-to-one with the program elements of the source code, so in the process of changing the pattern application location to the code after changing the code change pattern, it is best to use the AST graph. desirable.

As shown in FIG. 12, the processor generates an AST 13_AST of the changed code from the AST 12_AST of the program to be changed obtained by converting the program 12 to be changed of the source code, the code change pattern 11, and the pattern application location 14 (S3). . The modified code AST13_AST is modified to the modified code 13, which is the modified source code, and displayed on the screen of the client terminal. Note that conversion from source code to AST and conversion from AST to source code are performed by a function of a general compiler.

FIG. 13 is a diagram for explaining detection of pattern application locations and code change processing in fgPDG. In FIG. 13, M _L and M _R are fgPDG of the method before and after the code change in the change graph of fgPDG. _L and _R in ML and MR, which are the fgPDG of the method, are the fgPDG before and after the code change of the code change pattern, and are a part (subgraph) of the fgPDG of the method. On the other hand, MG is the _{fgPDG of the method of the program to be changed, and G in} MG is the fgPDG of the pattern application location and a part (subgraph) of the fgPDG of the method. Also, _MH is the fgPDG of the method after the code change. Here, L and R indicate the left and right sides of the change graph. Also, G and H indicate G before change and H after change (H next to alphabet G) in code change.

In the pattern application portion detection processing S2 in FIG. 13, the nodes of the pre-code change subgraph (L) of the code change pattern and the subgraph ( _G ) in the change target program MG correspond to each other. Indicates that the node was matched. On the other hand, the pattern-based code change processing S3 deletes the subgraph ( _G ) in the program to be changed MG, and instead adds the subgraph (R) after code change of the code change pattern to the method after code change. Generating fgPDG(M _H ).

As described with reference to FIG. 12, the code change processing S3 is performed by AST. Therefore, the problem of determining the connection relationship between AST nodes in the code change processing S3 performed by the AST will be explained using a specific example.

FIG. 14 is a diagram showing a specific example of the pattern application location detection processing S2 in fgPDG. An example of code changes in versions v1 and v2 in the development history group is as follows, as shown in the source code SC for this example.
Code changes in version v1
- a = m1(p1,p2);
+ a = m2(p1,p4) + p3;
Code changes in version v2
- a = m1(r1,r2);
+ a = m2(r1,r4) + r3;
In the code notation above, "-" means deleted code and "+" means added code. This means that the "-" code has been changed to a "+" code.

The code change pattern pattern extracted from the code change history as described above is therefore as follows.
- a = m1( , );
+ a = m2( , ) + ;
Subgraphs of fgPDG corresponding to the above code change patterns are shown at L and R in methods M _L , M _R . L is fgPDG with a = m1, and R is fgPDG with a = m2.

On the other hand, the method MG of the code to be changed includes a subgraph _G (fgPDG of a=m1) that matches the subgraph L (fgPDG of a=m1), and is detected as a pattern application location.

FIG. 15 is a diagram showing a specific example of the problem of the pattern-based code change processing S3 in the AST. The processing contents of the pattern-based code change processing S3 in the AST are as follows.
(1) Delete the AST node of A(G) corresponding to the fgPDG node of G from A(M _G ).
(2) Add the AST node of A(R) corresponding to the fgPDG node of R to A(M _G ) after deletion to obtain A(M _H ) after code change.

A(M _L ) and A(M _R ) in FIG. 15 are the ASTs of the methods M _L and M _R , and A(L) and A(R) are the AST before and after the code change pattern in the method. is. A(M _G ) and A(M _H ) are ASTs of methods M _G and M _H respectively. The AST node of A(R) corresponding to the fgPDG node of the post-change subgraph R in the process (2) of the above code change process S3 is added to A(M _G ) after deletion, and the AST node after code change is When obtaining A(M _H ), there are nodes whose connection relationship cannot be determined at the boundary between A(M _H ) and A(R). In the figure, ? It is difficult to determine the connection relationship between nodes shown in . Specifically, A(R) has 3 child nodes that need to be connected (1 for node "+" and 2 for node m2), whereas A(M _H ) has There are only two nodes p1 and p2 that require parent nodes. The reason why this happens is that in FIG. 14, L and R of fgPDG are of the same type, but in FIG. 15, A(G) and A(R) of AST are not necessarily the same.

[Code change processing that enables determination of connection relationships between AST nodes]
In this embodiment, in the code change processing by AST, it is possible or easy to determine the connection relation between the nodes in the boundary part of A(R), which is a subtree, and the nodes in A(M _H ). Therefore, in the code modification process, the processor, from each AST node corresponding to the fgPDG node in A(R) and A(G), determines the minimum node connection relation at the boundary more reliably. Detect derived subtrees. This minimal induced subtree is called MIDS (Munimum Insertable/Deletable induced Subtree). Then, instead of A(R) and A(G), the processor deletes the smallest derived subtree MIDS(G) from A(M _G ) and adds MIDS(R) to obtain S(M _H ). Ask.

FIG. 16 is a diagram showing a flowchart of code change processing by AST in this embodiment. The processor executes pattern-based code modification (S3), MIDS generation (S60), pattern-based code modification (S3) with the generated MIDS(G) and MIDS(R), and post-modification Generate A(M _H )13_AST as AST.

In MIDS generation processing S60, the processor generates (1) pre-change PDG (CG_L_PDG) and pre-change AST (CG_L_AST) of change graph CG from which code change pattern 11 is extracted, and (2) code change pattern 11 is extracted. A ( MIDS are generated respectively for the AST nodes in R) and A(G) (S60). The MIDS generation method will be described in detail later.

In FIG. 16, there are a plurality of code change patterns 11 output from process S1 and a plurality of pattern application locations 14 output from process S2. Furthermore, as shown in FIG. 9, there are also a plurality of original change graphs CG from which the code change pattern 11 was extracted. Along with this, the processor executes the pattern-based code change S3 for each of the plurality of code change patterns 11, the plurality of pattern application locations 14, and the plurality of change graphs CG.

FIG. 17 is a flowchart of pattern-based code change processing executed for a plurality of code change patterns, a plurality of pattern application locations, and a plurality of change graphs. As described above, the processor repeats the pattern-based code modification process S3 with MIDS generation S60 for each of the plurality of code modification patterns 11 (S40), for each of the plurality of pattern application locations 14 (S41), and Repeated execution is performed for each of a plurality of change graphs CG from which the code change pattern 11 is extracted.

In the pattern-based code modification process S3 with MIDS generation S60, the processor generates derived subtree MIDS (AST) from the pattern application location PDG, AST (S51_1), and the pattern application location AST (A(M _G ) ), delete the derived subtree MIDS (AST) for each fgPDG node in G (S51_2). Furthermore, the processor generates an induced subtree MIDS (AST) from the PDG and AST after modification of the change graph (S52_1), and stores the induced subtree MIDS (AST) for each fgPDG node in R in the AST (A(M _G )) of the pattern application location. Add MIDS (AST) (S52_2). Finally, the processor determines the connection relationship between the boundary node of the added MIDS (AST) and the node of AST (A(M _G )), connects both nodes, and converts the AST (A(M _H )) is generated (S53).

Note that the Change graph of S52_1 in FIG. 17 is obtained by associating the pre-change subgraph and the post-change subgraph of fgPDG shown in FIG. 8 with map edges. As described with reference to FIG. 4, since fgPDG is generated from AST, ASTs before and after each change can be obtained from Change graphs of multiple fgPDGs from which code change patterns are extracted.

Generate Minimal Derived Subtree MIDS
FIG. 18 is a diagram showing a flow chart of generating a minimal induced subtree MIDS. Hereinafter, the minimum derived subtree MIDS will be abbreviated as subtree MIDS. The flow chart for generating MIDS(N) for this AST node N has subtree MIDS definition S61 and MIDS(N) generation processing S62.

Definition S61 of subtree MIDS(N) of AST node N is the smallest AST subtree ST that contains AST node N and satisfies all conditions C1-C3.
Condition C1 is that the root of the AST subtree ST (MIDS) is a mapped node or an unmapped statement node.
Condition C2 is that the leaf (reaf) of the AST subtree ST (MIDS) is a mapped node or an unmapped node with no child nodes.
Condition C3 is that one or more mapped nodes exist in subtree MIDS(N) of node N of A(R). Condition C3 is a necessary condition when both root and leaf are unmapped nodes.

In condition C1, the root of the AST subtree ST(MIDS) is the node of the ancestral boundary. If the root is a mapped node, the node associated with the root (connected by the map edge) exists in A(M _G ), so the parent node of the mapped node in A(M _G ) is , becomes the destination of the root of the AST subtree ST (MIDS). Also, even if the root is unmapped, if it is a statement, it may be possible to detect the root's parent node by reconstructing the control flow, which will be described later.

Furthermore, in condition C2, if the leaf is a mapped node, the node associated with the leaf (connected by the map edge) exists in A(M _{G ), so the mapped node in A(M G )} is The child nodes of the node that was created become the connection destinations of the leaves of the AST subtree ST (MIDS). Also, if a leaf is an unmapped node with no child nodes, there is no child node for that leaf in A(M _G ), so there is no need to determine the connectivity of the leaf.

Then, if the condition C3 is satisfied, the subtree MIDS(N) of the node N in A(R) is used as a clue for the mapped node in A(MG) corresponding to the mapped node, and the subtree MIDS(N) You can decide where to connect border nodes.

A mapped node is a node with a map edge indicating correspondence, and an unmapped node is a node without a map edge. In the case of JAVA (registered trademark), statement nodes are BLK (Block), ES (expression statement), if, while, and the like. A more detailed description of the statement can be found at the end of the specification.

Starting from the AST node N corresponding to the fgPDG node, the processor repeatedly traces parent nodes and child nodes until conditions C1 to C3 of the subtree MIDS are satisfied, collects the traced nodes, and generates a subtree MIDS(N). (S62). The subtree MIDS(m2) for AST node m2 is shown at the bottom of FIG. Tracing the parent node of the node m2 leads to the mapped node "=", and tracing the child nodes of the node m2 leads to the unmapped nodes "p1" and "p4" which have no child nodes. Further, following the child node of the node "=" leads to the mapped node "a", and following the child node of the node "+" leads to the unmapped node "p3" which has no child node.

Also, in the case of the AST shown in the lower part of FIG. 18, the mapped nodes “=” and “a” satisfy the conditions C1 to C3, so they constitute the subtree MIDS by themselves. The subtree MIDS of node "+" is the same as the subtree MIDS of node "m2".

As shown in FIG. 18, in the induced subtree (MIDS), unlike a normal subtree, the root node c of the induced subtree MIDS need not have all descendant nodes d and e below the root node c. In derived subtree MIDS, root node c may only have descendant node d. A normal subtree has a root node c with all descendant nodes d and e below the root node c.

[Processing for obtaining A(M _H ) by pattern-based code change]
FIG. 19 is a diagram showing a flow chart of processing for obtaining A(M _H ) by pattern-based code modification. Processes S51, S52, and S53 in FIG. 19 correspond to processes S51_1, S51_2, S52_1, S52_2, and S53 in FIG. 17, respectively.

The processor finds MIDS(N _G ) for each AST node N _G corresponding to each fgPDG node in G, and removes MIDS(N _G ) from A(M _G ) (S51). However, the mapped nodes in MIDS(N _G ) are left in A(M _G ) without being deleted. A(M _G ) after the above deletion process is completed for all fgPDG nodes of G is called Ad(M _G ). A description based on a specific example of this deletion processing S51 will be given later.

Here, multiple MIDS(NG) obtained for each AST node NG corresponding to each fgPDG node of _G may include multiple MIDS( _NG ) having an inclusion relationship. In that case, MIDS(N _G ) with the widest range should be deleted from A(M _G ). In the case of the relationship between MIDS(m2), MIDS(=) and MIDS(a) shown in FIG. 18, the widest MIDS(m2) is deleted. Also, any two MIDSs have either a containment relationship or an independent relationship that does not intersect with each other. Relationships that intersect but do not contain do not occur. Intersecting means that parts of both MIDS overlap each other.

Next, the processor finds MIDS(N _R ) for each AST node N _R corresponding to each fgPDG node in R and adds MIDS(N _R ) to A _d (M _G ) (S52). At this time, the mapped nodes left undeleted in Ad(M _G ) are replaced with the corresponding mapped nodes in MIDS(N _R ). A description based on a specific example of this additional processing S52 will also be given later.

Then, the processor determines the connection relationship between the boundary nodes (root node, leaf node) of the added MIDS(N _R ) and the node of A _d (M _G ), and connects the nodes (S53). A description based on a specific example of this connection relationship determination process will also be given later.

[Specific example of deletion processing and addition processing]
FIG. 20 is an explanatory diagram based on a specific example of the deletion processing S51. FIG. 21 is an explanatory diagram based on a specific example of the addition process S52. Both explanations are based on the specific example of FIG.

As shown in FIG. 20, the processor deletes MIDS(N _G ) for each AST node N _G from A(M _G ) to A(G) to generate A _d (M _G ) (S51). Based on the specific example shown in FIG. 20, since the nodes '=' and 'a' in A(G) are mapped nodes, the processor satisfies the MIDS conditions, so that only the node '=' is processed. Create MIDS(=) with and MIDS(a) with only node 'a' and delete from A(M _G ). However, since the nodes “=” and “a” are mapped nodes, they are left in Ad(MG) without being deleted from A(MG) ( _{S51_a} ). Further, the processor generates MIDS(m1) of node 'm1' in A(G) as shown in the lower left of FIG. ', 'p1' and 'p2' are deleted from A(M _G ) (S51_b). As a result, A _d (M _G ) at the lower right in FIG. 20 is generated.

As shown in FIG. 21, the processor adds MIDS(N _R ) for each AST node N _R of A(R) to A _d (M _G ) to generate A(M _H ) (S52). To explain based on the specific example shown in FIG. 21, since the nodes '=' and 'a' in A(R) are mapped nodes, the processor satisfies the conditions of MIDS, respectively, so that only the node '=' is processed. Create MIDS(=) with and MIDS(a) with only node 'a' and add to A _d (M _G ). However, since the nodes '=' and 'a' are mapped nodes, they are replaced with the corresponding nodes '=' and 'a' in A _d (M _G ) (S52_a). Further, the processor generates MIDS(+) of node "+" and MIDS(m2) of node "m2", and since both MIDS are the same, MIDS(+) or MIDS(m2), A _d (M _G ) to generate A(M _H ) (S52_b). However, the mapped nodes (“+” and “a”) are exchanged in the additional processing.

In the specific examples of FIGS. 20 and 21, since the root node "=" of MIDS(+) and MIDS(m2) is a mapped node, the processor replaces the root node "=" with the corresponding mapped node. Connect with the parent node "..." in Ad (MG). On the other hand, since the leaf nodes 'p1', 'p3' and 'p4' in MIDS(N _R ) do not have child nodes, no leaf node connections occur. Therefore, in the above specific example, the boundary node connection relationship determination processing S53 is not necessary. Therefore, the connection relationship determination processing S53 of the boundary nodes will be described in detail below based on another specific example.

[Concrete example of determination processing of connection relationship of boundary nodes]
The process of determining the connection relation of the boundary nodes of MIDS(N _R ) of A(R) added to A _d (M _G ) will be described for each of the following four types of boundary nodes.
(a) When the root node is a mapped node In this case, determination is made based on the connection relation of the nodes in A _d (M _G ) corresponding to the mapped node.
(b) When the root node is an unmapped statement node In this case, the connection relationship is determined by the later-described control flow reconstruction.
(c) When the leaf node is a mapped node In this case, determination is made based on the connection relation of the nodes in A _d (M _G ) corresponding to the mapped node.
(d) When the leaf node has no child nodes (however, there is no need for a connection relationship, so there is no explanation)

[(a) When the root node is a mapped node]
FIG. 22 is a diagram showing the process of determining the connection relation of boundary nodes when (a) the root node is a mapped node. FIG. 23 and FIG. 24 are diagrams respectively showing two specific examples of (a) the process of determining the connection relationship of boundary nodes when the root node is a mapped node.

In FIG. 22, (a) when the root node N _r of the added MIDS(N _R ) is a mapped node, the processor:
(a-1) Connect the parent node of the node corresponding to the MIDS root node N _r in A _d (M _G ) to be the parent node of the root node N _r in A(M _H ) as well.
(a-2) If the node corresponding to the root node N _r of MIDS has a child node N _c in A _d (M _G ), add N _c to the child of the root node N _r in A(M _H ). If possible, connect to add N _c as a child node of N _r . If it cannot be added, the nodes below _Nc are overwritten with the child nodes of the root node Nr, or the code cannot be changed, and the process ends ( _{S53_1} ).

In the specific example S53_1(1) of FIG. 23, the code change pattern pattern is if( ){ } before change and if( ){m1(); m2(p1,p2);} after change. In this case, the processor replaces the MIDS(N _R ) shown in A _d (M _G ) with the MIDS(N _G ) (containing only 'if') (not shown) removed but the mapped node 'if' left. to generate A(M _H ).

In this specific example, the processor determines the following connection relations for the root node “if” of MIDS(N _−R ).
(a-1) The parent node of _root node N _r 'if' of _MIDS (N- _R ) is the parent node 'while ”.
(a-2) Child nodes of the root node N _r "if" of MIDS(N- _R ) are as follows. The node 'if' in A _d (M _-G ) corresponding to the root node N _r 'if' of MIDS(N _-R ) has a child node N _c 'cond', and the root node of MIDS(N _R ) Add the child node 'cond' in A _d (M _−G ) as a child node of the root node N _r 'if' because the child node of 'if' has the sentence 'BLK' but no condition node.

In the specific example S53_1(2) in FIG. 24, the code change pattern pattern and the like are the same as in FIG. However, there is a child node 'cond' in node 'if' in A _d (M _-G ) corresponding to root node N _r 'if' in MIDS( _{N -R} ), while The child node of the root node N _r "if" is the sentence "BLK" and the conditional node "cond2". In this case, the processor determines the following connection relation for the root node N _r "if" of MIDS(N _-R ).
(a-1) _Same as _FIG . 23 (a- ₂ ) _Corresponds to the case where addition is not possible in FIG. _r Overwrite with child node "cond2" of "if". Alternatively, output a comment that cannot be changed.

[(b) When the root node is an unmapped statement node]
FIG. 25 is a diagram showing the process of determining the connection relation of boundary nodes when the root node is an unmapped statement node (b). FIG. 26 is a diagram showing a specific example of the connection relationship determination processing of boundary nodes when the root node is an unmapped statement node (b).

In FIG. 25, (b) when the root node N _r of the added MIDS(N _R ) is an unmapped statement node, the processor reconstructs the control flow as follows.
(b-1) In MIDS(N _R ), let N _m be a mapped node that is a descendant of the root node N _r .
(b-2) In A _d (M _G ), let N _ac be the closest ancestor control node from the mapped node N _m — 1 corresponding to the mapped node N _m of MIDS(N _R ). here,
・Control nodes refer to block nodes or nodes that express conditional branching/repetition such as if, while, and do.
If A _d (M _G ) cannot be traced due to deletion of MIDS(N _G ), A(M _G ) is traced to identify the control node that satisfies the above conditions as N _ac .
(b-3) A(M _H ) is connected so as to add the root node N _r as a child node of the control node N _ac (S53_2).

However, in (b-1), if there are multiple N _m , the node closest to N _r is selected as N _m and the control flow is reconstructed. The parent-child relationship from N _m to N _ac in A _d (M _G ) is ignored in A(M _H ) (no parent-child relationship is created) (S53_2).

In the process of reconstructing the above control flow, the processor detects mapped nodes _{N m} that are descendants of the root node N _r in _MIDS ( _{N R} ), and The nearest ancestor node and control node N _ac is detected from the mapped node N _{m_1} in A _d ( _{M G} ) corresponding to the mapped node N _m , and A _{d (} M _G ) in the control node N _ac as a parent node.

In specific examples S53_2 and S53_3 in FIG. 26, the code change pattern is m1( ); before change and if(cond){m1();} after change. Therefore, the processor adds MIDS(N _R ) to A _d (M _G ), which deletes MIDS(N _G ) (including only m1) and leaves the mapped node m1, to generate A(M _H ). . In this case, the processor performs processing to reconstruct the next control flow.
(b-1) In MIDS(N _R ), let N _m be the mapped node “m1” descendant of the root node N _r “If”.
(b-2) Mapped node N m_1 in A _d ( _{M G} ) corresponding to mapped node N _m 'm1' in MIDS(N _R ). Let it be _Nac .
(b-3) Connect so as to add the root node N _r 'If' in MIDS(N _R ) as a child node of N _ac 'while' in A(M _H ). However, the parent-child relationship from the mapped node N _m 'm1' in A _d (M _G ) to the control node N _ac 'while' is ignored in A(M _H ).

[(c) When the leaf node is a mapped node]
FIG. 27 is a diagram showing the process of determining the connection relation of boundary nodes when (c) the leaf node is a mapped node. 28, 29, and 30 are diagrams showing specific examples of the process of determining the connection relation of boundary nodes when (c) the leaf node is a mapped node. As described above, MIDS is an induction subtree, so unlike normal subtrees, a node in A _d (M _G ) may connect to a leaf node of MIDS as a child node. Therefore, it is necessary to consider the connection relationship determination process when the leaf node in (c) is a mapped node.

In FIG. 27, when the leaf node Nl of (c) added _MIDS (N _R ) is a mapped node, the processor performs the following processing.
(c-1) Make the child node of the mapped node in A _d (M _G ) corresponding to leaf node N _l in MIDS(N _R ) the child node of leaf node N _l in A(M _H ) as well. , connect the leaf node _Nl .
(c-2) If the following conditions are satisfied, the leaf node N _l in A(M _H ) is a qualified name (qualifier + simple name) of the mapped node N _{l _1 of the leaf node N l in} A(M _G ) Replace with a group of nodes.
- Condition: In A(M _G ), the mapped node N _l _1 of the leaf node N _l is a child node of the qualifier (continuity possible).
(c-3) Except for condition (c-2), explicitly reflect the relationship between “N _l _1” and “parent of N _l _1” in A _d (M _G ) to A(M _H ) (The leaf node N _l of MIDS(N _R ) is exchanged with “N _{l_1} ” of A _d (M _G ), and the parent-child relationship is added to the root node N _r in the connection relationship determination process. (so you don't need to do anything here).

In the specific example S53_4(c-1) of FIG. 28, the code change pattern is if (cond) {m1( );} before change and do if(cond){m1();} after change. Therefore, the processor deletes MIDS(N _G ) 'If' from A(M _G ) and adds MIDS(N _R )1 to A _d (M _G ) that leaves the mapped node 'If', Generate A(M _H ). In this case, the processor performs the next processing shown in S53_4(c-1) of FIG.
For the node "If" which is a leaf node of MIDS(N _R )1,
・The child node BLK, cond of the node "If" in A _d (M _G ) corresponding to the leaf node "If" in MIDS(N _R )1 is also a child node of the leaf node "If" in A(M _H ) and so on.
・The parent node While in A _d (M _G ) is the parent node of the root node “Do” in MIDS(N _R )1 in A(M _H ) by reconstructing the control flow of the connection relationship determination method of the root node. connect as much as possible.

In the specific example S53_4(c-2) of FIG. 29, the code change pattern is if (cond) {m2(p2);} before change and if(cond){m3(p2);} after change. Therefore, the processor deletes MIDS(N _G ) 'ES~p1' from A(M _G ) and adds MIDS(N _R )2 to A _d (M _G ) which leaves the mapped node 'p1'. , A(M _H ). In this case, the processor performs the next processing shown in S53_4(c-2) of FIG.
For leaf node N _l 'p2' of MIDS(N _R )2,
The parent node of node N _l — 1 'p1' corresponding to leaf node N _l 'p2' of MIDS(N _R )2 in A(M _G ) is qualifier. Therefore, in A(M _H ), let leaf node N _l ``p2'' of MIDS(N <sub>R</sub> )2 be the qualified name node group (qualifier + qualifier + p1) of node N <sub>l</sub> _1 ``p1'' of A(M _G ) Connect to replace with .

In JAVA, qualifier + qualifier + p1 means a different method call than qualifier + qualifier + p2, so we keep qualifier + qualifier + p1 in A(M _G ).

In this example, the processor connects the control node "BLK" of A(M _H ) as a parent node to the root node Nr of MIDS(N _R )2 by the control flow reconstruction processing (b-3). do. However, since leaf node N _{l_1} “p1” of A _d (M _G ) cannot be traced to “BLK” of N _AC , leaf node N _{l_1} “p1” of A (M _G ) to “BLK” of N _AC to detect. It is as described in (b-2) of S53_2 in FIG.

As described above, according to the present embodiment, in code change by a code change pattern, the pre-change AST (A(G)) corresponding to the pre-change fgPDG subgraph of the code change pattern of fgPDG and the post-change fgPDG subgraph. Generate induced subtrees MIDS(N _G ) and MIDS(N _R ) from the corresponding modified AST (A(R)), and use MIDS(N _G ) and MIDS(N _R ) to generate the unmodified AST ( A(M _G )) is changed to AST(A(M _H )). By using MIDS(N _G ) and MIDS(N _R ), it becomes possible to detect the connection relation of nodes in code modification.

FIG. 31 is a diagram showing an example of a user screen of the development support device 1 that performs systematic editing according to this embodiment. Mining of code change patterns from the development history group 10 has already been completed, and the code change pattern group has already been stored in the storage. This is the screen of the client terminal when the user accesses the development support device 1 from the client terminal device 40 and executes the development support program in such a state.

On the screen S70, when the user selects "Ana.java" as the file of the program code to be edited in order to perform systematic editing, the code of a method "void anaFunc(Arg arg)" in the program code to be changed is displayed. be done. The user then clicks on the search button "search" which requests a search for code change patterns that match the program code to be edited.

In screen S71, in response to clicking the search button, the processor searches for each pattern in the code change pattern group and detects three matched code change patterns "Pattern title 1" to "Pattern title 3", indicate. Then, when you select "Ana.java" that matches "Pattern title 1", the processor displays the code before the code change (left side) and the code after the code change (right side) on the right screen and makes suggestions. , to highlight changes in both codes.

When the user checks the code changes in both code changes and clicks the accept button "Accept" to approve the code changes, the processor automatically makes the proposed code changes.

[JAVA (registered trademark) statements, expressions, etc.]
Examples of JAVA (registered trademark) statements, expressions, and AST elements excluding the above are as follows. Control nodes are underlined.

statement
AssertStatement, Block , BreakStatement, ConstructorInvocation, ContinueStatement, DoStatement , EmptyStatement, EnhancedForStatement , ExpressionStatement, ForStatement , IfStatement , LabeledStatement, ReturnStatement, SuperConstructorInvocation, SwitchCase, SwitchStatement , SynchronizedStatement , ThrowStatement, TryStatement , TypeDeclarationStatement, VariableDeclarationStatement, WhileStatement
expression
Annotation, ArrayAccess, ArrayCreation, ArrayInitializer, Assignment, BooleanLiteral, CastExpression, CharacterLiteral, ClassInstanceCreation, ConditionalExpression, FieldAccess, InfixExpression, InstanceofExpression, LambdaExpression, MethodInvocation, MethodReference, Name, NullLiteral, NumberLiteral, ParenthesizedExpression, PostfixExpression, PrefixExpression, StringLiteral, SuperFieldAccess, SuperMethodInvocation, ThisExpression, TypeLiteral, VariableDeclarationExpression
AST elements excluding the above
AnonymousClassDeclaration, BodyDeclaration, CatchClause , Comment, CompilationUnit, Dimension, ImportDeclaration, MemberRef, MemberValuePair, MethodRef, MethodRefParameter, Modifier, ModuleDeclaration, ModuleDirective, ModuleModifier, PackageDeclaration, TagElement, TextElement, Type, TypeParameter, VariableDeclaration

1: Development support device 10: Development history group 11: Code change pattern group 12: Change target program 13: Changed program 21: Development support program 21A: Code change pattern mining program 21B: Pattern application location detection program 21C: Code change program S1: pattern mining processing S2: pattern application location detection processing S3: code change based on pattern
A(M _L ): Program code before change
A(M _R ): Changed program code
L: Subgraph before change
R: Subgraph after change
A(M _G ): AST to be changed
A(M _R ): AST after change
MIDS(N _G ): Induction subtree to be modified
MIDS(N _R ): modified derived subtree

Claims (7)

Code change of program code to be changed based on a code change pattern having a pre-change subgraph and a post-change subgraph extracted from the pre-change program dependency graph and the post-change program dependency graph of the pre-change program code and the post-change program code a method for
In each of the AST to be changed which is an abstract syntax tree (hereinafter referred to as AST) of the program code to be changed that matches the subgraph before change and the AST after change which is the AST of the program code after change having the subgraph after change ,
Identifying a modified derived subtree and a modified derived subtree having a node of the pre-modification subgraph or the post-modification subgraph and having, as a root node or a leaf node, a map node having a correspondence between the modification target AST and the post-modification AST. death,
deleting the modified derived subtree from the modified AST;
adding the modified derived subtree to the deleted modified AST;
A code modification method, comprising connecting boundary nodes in the modified derived subtree with nodes in the deleted modified AST. The connecting process includes:
2. The method according to claim 1, comprising a process of connecting a root node with a map in the derived subtree after modification to a parent node of a root node with a map in the derived subtree to be modified which is a node in the AST to be modified. How to change code. The connecting process includes:
3. The method according to claim 2, comprising a process of connecting a root node with a map in the derived subtree after modification to a child node of a root node with a map in the derived subtree to be modified which is a node in the AST to be modified. How to change code. The connecting process includes:
3. The method according to claim 1 or 2, comprising a process of connecting a leaf node with a map in the derived subtree after modification to a child node of a leaf node with a map in the derived subtree to be modified that is a node in the AST to be modified. How to change the code as described. The connecting process includes:
Mapped leaf nodes in the modified derived subtree are qualified names having qualifiers and simple names of nodes in the modified AST associated with mapped leaf nodes in the modified derived subtree. 3. The code modification method according to claim 1, further comprising a process of replacing in a group of nodes. The process of identifying the post-change derived subtree includes:
identifying a modified induced subtree having an unmapped statement node with no association as a root node;
The connecting process includes:
identifying a first map node that is a descendant of the unmapped statement node in the modified derived subtree;
identifying a control node that is an ancestor of a second map node corresponding to the first map node in the AST to be modified;
2. The method of modifying code according to claim 1, comprising the step of connecting said unmapped statement nodes to said control nodes. Code change of program code to be changed based on a code change pattern having a pre-change subgraph and a post-change subgraph extracted from the pre-change program dependency graph and the post-change program dependency graph of the pre-change program code and the post-change program code a process for
In each of the AST to be changed which is an abstract syntax tree (hereinafter referred to as AST) of the program code to be changed that matches the subgraph before change and the AST after change which is the AST of the program code after change having the subgraph after change ,
Identifying a modified derived subtree and a modified derived subtree having a node of the pre-modification subgraph or the post-modification subgraph and having, as a root node or a leaf node, a map node having a correspondence between the modification target AST and the post-modification AST. death,
deleting the modified derived subtree from the modified AST;
adding the modified derived subtree to the deleted modified AST;
A code modification program that causes a computer to execute a process of connecting a boundary node in the modified derived subtree with a node in the deleted modified AST.

Images