Api use case automated update method based on library and customer project bilateral change information

Abstract

The application discloses an API use case automatic update method based on library and customer project bilateral change information, and provides a to-be-updated prompt and an update result recommendation for existing customer code through three stages of library side change analysis, customer project change mining, update rule matching and application, and comprises the following steps: 1) a simple update rule extraction strategy based on library side change information; 2) an instance update rule mining method based on an API life cycle; 3) an instance update rule redundancy removal method based on a generalization relation; 4) an instance update rule evaluation strategy integrating generalization support and mapping matching degree; and 5) an editing operation transplantation method based on abstract syntax tree node mapping. Compared with existing API use case automatic update tools, the application can mine more abundant update rules, can be adapted to more to-be-updated codes in different situations, and can more accurately perform modification, reduce the workload of secondary modification of users, and improve the work efficiency of developers.

Description

Technical Field

[0001] This invention relates to an automated update method for API use cases based on change information from both the library and the client project. When a software project migrates its dependent software library to a new version, the client code of the corresponding software library in the project should be automatically updated to adapt to the changes in the new version. This invention belongs to the field of computer technology. Background Technology

[0002] In current software development, using software libraries to implement specific functions or directly using frameworks to build projects has become a preferred choice for many development teams. Whether it's a library or a framework, the most common way to use them is by calling APIs (Application Programming Interfaces) to access their provided functionality. As software products, they also require continuous development and maintenance. During version updates, whether for bug fixes or feature enhancements, APIs are often obsolete and updated. At this point, client programs that rely on the software library need to update their code using outdated APIs to access richer and more complete features. However, manually modifying outdated API use cases requires developers to consult documentation and read code, which is time-consuming and laborious. Therefore, researchers have proposed automated tools and methods to assist developers in updating outdated API use cases. These methods can be divided into two types: one focuses on library-related information, using library changes, documentation, or comments to search for or infer the rules governing API use case changes; this can be called library-based API use case updates. The other focuses on information provided by the client project, extracting the rules related to API use case updates from the code change history; this is called update instance-based API use case updates.

[0003] Library-based API use case updates often only uncover simple migration rules, such as class name changes, package name changes, or changes in the number of method parameters. They are difficult to modify the code that combines APIs. Meanwhile, API use case updates based on update instances are often limited by the dataset being mined, and therefore lack update solutions for less commonly used APIs. Summary of the Invention

[0004] Objective: To address the problems and shortcomings of existing technologies, this invention provides a method for API update rule mining and automated API use case updates. This invention combines change information from both the library and the client project to mine API update rules, automatically searches for code to be updated in the client project, matches and sorts suitable rules, and automates code modification, reducing the work required for developers to migrate application dependency library versions to new versions.

[0005] Technical Solution: An automated API use case update method based on changes from both the library and client projects. This includes a simple update rule extraction strategy based on library-side change information, an instance update rule mining method based on the API lifecycle, a method for determining generalization relationships based on mappings and removing redundancy in update instance rules based on generalization relationships, an instance update rule evaluation strategy that integrates generalization support and mapping matching, and an editing operation portability method based on abstract syntax tree node mappings. Specifically, it includes the following steps:

[0006] Step 1: Analyze the API changes between adjacent versions of the target software library, extract the API change operations in each version and store them as API lifecycle information, and use the change information to generate simple update rules.

[0007] Step 2: Search the customer's project change history, extract evolution-related change code based on API lifecycle information, and generate instance update rules.

[0008] Step 3: Redundancy removal and generalization support calculation are performed on the instance update rules.

[0009] Step 4: Use the expired API information involved in all update rules to detect and locate the unupdated customer projects that need to be updated.

[0010] Step 5: Match available update rules and evaluate and sort them.

[0011] Step 6: Apply the update rules to perform the update.

[0012] In step 1, incremental changes in release packages between adjacent versions of the target software library are used to analyze and obtain API lifecycle information and simple update rules. The API lifecycle information supports subsequent instance update rule mining, and the simple update rules can be translated into specific editing operations to modify the code used by expired APIs. These simple update rules can handle a considerable number of API expiration cases. The specific implementation process is as follows:

[0013] 11) Download the distribution package of the target software repository and read the version sequence information.

[0014] 12) Using two adjacent versions of JAR files as the analysis objects, two open-source JAR file difference analysis tools, clirr and japicmp, were used to analyze the two versions of JAR files.

[0015] 13) Analyze the output of clirr and japicmp, extract common changes, and generate simple update rules.

[0016] 14) Analyze the output results of clirr and japicmp to obtain a set of API changes for the five API types (class, interface, constructor, field, and method) within the version range, involving six operation types: deprecated, removed, hidden, no-longer-deprecated, and added.

[0017] 15) Collect the set of API changes between all adjacent versions to obtain the API lifecycle information.

[0018] In step 2, update instance rules are mined from the change history of the customer's project. This process generates more complex update rules than simple update rules, designed to handle situations that simple update rules cannot address, such as multiple APIs expiring simultaneously in API combination calls. The specific implementation process is as follows:

[0019] 21) Quickly locate code changes related to version evolution. The specific implementation process is as follows:

[0020] 211) Locate the target software repository version (old version v) in the change history. old And the new version v new The commit that resulted in changes collects the code changes that occurred during the commit.

[0021] 212) Locate the changes in method calls, member variable usage, and object creation operations. After parsing the corresponding API signature, use lifecycle information to determine if it has expired. If so, this API signature location is designated as a key location related to version evolution.

[0022] 213) If the critical location has already been recorded in the collected use cases, then no subsequent logic will be executed.

[0023] 214) Parse the modified code file and match each member variable and method declaration before and after the commit according to the signature. If the critical location is in the member variable initialization, the initialization content of the matched member variable is used as the matching test case, and the result is returned. If it is in the method declaration body, the matching test cases in the method body are collected.

[0024] 22) Map the nodes of the abstract syntax tree of the method body code. The specific implementation process is as follows:

[0025] 221) Use ChangeDistiller's node mapping logic to perform basic mapping on the nodes in the abstract syntax tree of the method body to obtain the initial anchor set.

[0026] 222) Find nodes in both abstract syntax trees that have unique characteristics and are identical, and add them to the anchor set. Unique characteristics refer to unique API calls, unique types, and unique content that are not found in other nodes in the syntax tree.

[0027] 223) Filter the anchor set and remove mappings that meet the following rules: a) The node types of the two mappings are different; b) Both mappings are Modifier type nodes; c) Both mappings are Statement type nodes; d) Both mappings are LiteralExpr type nodes; e) Both mappings are SimpleName type nodes and have different text content.

[0028] 224) Initialize the mapping set based on the anchor set. In the syntax tree, using the role and position of the child node as the edges connecting the parent and child nodes, starting from the anchor point, add adjacent nodes connected by the same edge value to the mapping set, thus spreading the mapping relationship. At this point, the mapping relationship in the mapping set is many-to-many, meaning that a node in one syntax tree can be mapped to multiple nodes in another syntax tree.

[0029] 225) The KM algorithm is used to converge many-to-many mappings in the mapping set, transforming them into one-to-one mappings. However, using the KM algorithm requires evaluating the connection weights between nodes. The calculation method for the connection weights between two nodes is as follows:

[0030] w pq =NS pq +∫ t∈T SC t *S tpq dt

[0031] NS pq SC is the number of pairs of nodes p and q whose parent nodes have unique mappings. t S is the matching coefficient for feature t. tpq It represents the common value of nodes p and q on feature t. The value is 1 when the two nodes have the same value on feature t, and 0 otherwise. T is the selected set of features, such as method calls, constructor calls, member variable accesses, etc.

[0032] 23) Within the method body, paired API use cases before and after the change are collected based on data dependencies and mapping relationships. The specific implementation process is as follows:

[0033] 231) Initialize the set of key statements before the change and add the statements where the key positions are located.

[0034] 232) Expand the set of key statements before the change based on data dependencies.

[0035] 233) For the expanded set, based on the mapping relationship, obtain the mapping nodes of the statements in the set in the modified code, and obtain the modified key statement set.

[0036] 234) Expand the set of key statements after the change based on data dependencies.

[0037] 235) If new modified key statements are added during the execution of 234), the mapping statement is obtained through the mapping relationship. If the mapping statement is not in the set of key statements before the change, it is added to the set, and the process jumps to 232) to expand the set of key statements before the change again.

[0038] 236) Arrange the two sets of key statements before and after the change in the original order to obtain the paired API use cases.

[0039] 24) Construct and save test cases, mainly performing test case simplification, API removal identification, version identification, and finally serializing and saving instance update rules. The specific implementation process is as follows:

[0040] 241) Simplify and inspect the test cases. For the API test cases before and after the change obtained in 23), remap the nodes. Delete statements that are mapped to each other and have the same content, resulting in simplified API test case pairs.

[0041] 242) Version Change Related Judgment. In the simplified test case pairs in 241), analyze the changes in API usage. If there are cases where expired APIs have been removed and newly introduced APIs are not expired, then the test case change is determined to be related to the software library version change.

[0042] 243) Re-analyze the version of the rules based on API call data. The expired APIs removed from the test case pairs are not all from the new version v. new The expired APIs may have already expired in earlier versions. Therefore, to improve the accuracy of rule usage conditions, it is necessary to re-analyze the versions corresponding to the rules for the expired APIs removed from the use case pairs. Among all the removed expired APIs, the earliest expired API was in version v. dmin The latest API to expire is version v. dmax If it expires, then the real old version v will be lost. rold =v dmin -1, the real new version v rnew =v dmax Save eligible use case pairs as instance update rules, and record the expired APIs removed from the use case pairs and the actual target version (v). rold v rnew ).

[0043] 244) Save the instance's update rules to the update rule database. The update rule database is a database that stores update rules during the mining process and provides support for subsequent search of update rules.

[0044] Step 3 involves redundancy removal and generalization support calculation for the instance update rules. The specific implementation process is as follows:

[0045] 31) Initial Redundancy Removal. In historical changes, it's common for a single modification to occur repeatedly (through commits and merges) or for multiple instances of identical code content. Therefore, the instance rules collected in step 2 also contain a large amount of redundant text. Redundancy is removed from use cases before and after the same change within the same project.

[0046] 32) Generalization refers to a binary relationship between two instance update rules. If rule A and rule B remove the same set of expired APIs, and the use cases before and after the change in A are completely contained within the use cases before and after the change in B, then rule A is considered to generalize rule B. "Contains" refers to the relationship between two use cases. When use case U and use case P are mapped through nodes, all syntax tree nodes in use case U have mapped nodes in use case P, and use case P contains use case U. First, the rules are grouped according to the set of expired APIs removed. Then, pairwise comparisons are performed within each group to obtain the set of generalization relationships.

[0047] 33) Grouping based on generalization relationships to further remove redundancy. When two instance update rules generalize to each other, they are considered equivalent. Equivalent instance update rules are aggregated into a group, and the first one is selected as the representative use case.

[0048] 34) Calculate the generalization support of instance update rules. When an instance update rule is a generalization rule of many other rules, it indicates that the change operations it contains are more general. Therefore, the number of other rules a rule generalizes to is calculated as the generalization support G, which serves as an important scoring criterion for ranking rules in subsequent applications.

[0049] In step 4, expired API information from all update rules is used to detect and locate unupdated customer projects that require updating. This involves searching the project space for target use cases that can be updated. The specific implementation process is as follows:

[0050] 41) Query the set of rules available in the current version from the update rule database, take the union of the expired APIs that have been removed from them, and get the set of APIs that can be modified. Use the simple names of these APIs to perform a text search in the code file to find the suspected key locations, and determine whether they are key locations that need to be updated by parsing the API signature.

[0051] 42) For the key locations found in 41), if they are in the initial values ​​of member variables, then the initial value expression is used as the target use case; if the node is in the method body, then it is expanded based on the data dependency relationship to obtain the target key statement set, which is sorted and used as the initial target use case to wait for update.

[0052] In step 5, appropriate rules are matched based on the target use cases obtained in step 4, and the ranking is comprehensively evaluated based on the generalization support between instance rules and the mapping matching degree with the target use cases. The specific implementation process is as follows:

[0053] 51) Obtain the candidate update rule set. Using the API signature obtained in 43), search for related update rules in the update rule database. By mapping the target use case and the use case before the instance rule change, filter out the rules that can be mapped to the key node.

[0054] 52) Simple update rules have the highest priority; instance update rules are evaluated using a score. The evaluation method is as follows:

[0055] 521) Based on the mapping results in 51), the number of mapped node pairs N is obtained. matched This leads to the degree of matching between the rules and the target use cases, m = N. matched / N o N o This represents the total number of nodes in the use case before the change.

[0056] 522) Calculate the number of connection bridges. In the mapping node pairs between the target use case and the original use case, if there exists a pair of mapping node pairs of the same type and without structural differences (n... t n o ), n o Mapping node n also exists in the modified use case. n Then it is called (n) t n o n n The three nodes and their mapping relationships form a bridge. Count the number of bridges N. b .

[0057] 523) Calculate the difference N between the number of use case statements before and after the change in the instance update rule. sd .

[0058] 524) Read the generalization support G of the instance update rule calculated in 34).

[0059] 53) According to (G, m, N) b -N sdThe instance update rules are sorted in descending order according to the lexicographical order of the rules to generate a rule queue, and simple update rules are added to the head of the queue. Then, they are retrieved one by one and processed in step 6 to update the target use case.

[0060] Step 6 involves updating the target use case using update rules. If it's a simple update rule, the corresponding simple updater is used to modify the code of key nodes. If it's an instance update rule, the code is modified using an edit operation porting method based on abstract syntax tree node mapping. The specific implementation process is as follows:

[0061] 61) If the update rule is an instance rule, then use the mapping result in 51) to remove statements in the target use case that do not have mapping, simplify the target use case, and then make the target use case remap nodes with the use case before the change.

[0062] 62) Extracting editing operations using the connecting bridge is implemented as follows:

[0063] 621) Perform a hierarchical traversal of the target use case nodes to find connecting bridges.

[0064] 622) Extract editing operations from the connecting bridge. If n o With n t If the node types are different, it is considered a replacement operation. If n o With n t If the node types are the same, then construct a simple subtree (n) of height 2. o With n t As the root node, its direct children are treated as leaf nodes. The GumTreeDiff tool is used to extract changes to these two simple subtrees. When extracting changes, nodes with mapping relationships or data equivalence are considered as the same node.

[0065] 623) Convert the diff result output by the GumTreeDiff tool to obtain the result for n. t The operation.

[0066] 63) Apply editing operations to modify target use cases in a fine-grained manner. When inserting variables into the modified use case, escape them to equivalent variables in the target use case based on the mapping relationship of data nodes. Update the context information of the target use case.

[0067] 64) Insert statements that have not been used during the editing process. Based on the node that has been moved to the target use case and the relative position of the statement in the changed use case, locate the insertion position in the node of the target use case.

[0068] 65) Delete the broken bridge nodes that still exist in the broken bridge set.

[0069] 66) Display the final update results.

[0070] Compared with the prior art, the present invention has the following advantages:

[0071] (1) This invention proposes an update rule mining method that utilizes change information from both the library and the customer project. This method can mine as many update rules as possible while ensuring the accuracy of the rules, thereby increasing the amount of code that the tool can update.

[0072] (2) The rule sorting method for generalization support and mapping matching proposed in this invention has both the universality and particularity of rules, so that the more suitable rules are displayed first, allowing users to select and view them in turn. It is convenient, fast and efficient.

[0073] (3) This invention proposes a code update method based on syntax tree node mapping. By abstracting nodes at different levels, the code can be modified more accurately while maintaining the original code structure as much as possible, reducing the workload of secondary modifications for users.

[0074] (4) The improved node mapping method based on path diffusion proposed in this invention utilizes type information, syntax node identity information and API call information to improve the richness and accuracy of node mapping, enabling more precise mapping between codes of different projects. Compared with the original mapping logic, this method can improve the redundancy removal efficiency of update rules and the application success rate of instance update rules. Attached Figure Description

[0075] Figure 1 This is a general flowchart of an embodiment of the present invention. Detailed Implementation

[0076] The present invention will be further illustrated below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. After reading the present invention, any modifications of the present invention in various equivalent forms by those skilled in the art will fall within the scope defined by the appended claims.

[0077] Software developers often leverage existing software libraries, such as log4j and FastJson, to implement specific functionalities. However, software libraries, as software products, undergo iterative evolution, leading to older API versions becoming obsolete or being removed. This embodiment provides an automated API use case update method based on change information from both the library and the client's project. It promptly alerts and automatically updates outdated API usage code in the project, reducing the workload of manual updates for developers and mitigating the various risks associated with software library version changes.

[0078] The first step is to extract API change information and simple update rules from the target software library's JAR package list. First, the JAR packages need to be collected. Users can directly input the target software library's group and name information. This method will construct the link of the software library's distribution package in the Maven-central repository, download the JAR packages to the local machine, and read the maven-metadata.xml file in the repository that records the software library's version sequence. The open-source tools clirr and japicmp are used to analyze adjacent versions of the JAR packages. Both tools can analyze changes in classes, interfaces, constructors, fields, and methods between two JAR packages. To obtain a more comprehensive understanding of API changes, this invention uses both tools simultaneously to combine their results.

[0079] The API change operations are parsed based on the different output formats of the two tools. Common refactoring operations such as package name change, class movement, class name change, method name change, method parameter reduction, method return value change, and member variable name change are identified and stored as simple update rules. Finally, the API change sets between all adjacent versions are collected, and all changes are aggregated according to API and sorted by version to obtain the API lifecycle information.

[0080] The second step is to extract instance rules from the client's project change history. To determine the commits that changed versions, we first search the project build files (such as pom.xml) for change history using Git Logs, then parse the contents of the build files before and after the commit to obtain the versions in the dependency declarations and compare them to see if they have changed. If they have changed, the commit is a commit that changed versions.

[0081] After collecting these committed change files, to quickly locate the specific positions related to version evolution, we first use a text Git diff tool to obtain the specific line numbers of the changed code files. A TreeMap data structure is then used to record the starting line of the change and its corresponding line number. JavaParser is used to parse the content of the version change-related code files before the commit. A custom accessor is used to traverse the abstract syntax tree nodes, identifying nodes in the changed lines that are of type MethodCallExpr, FieldAccessExpr, or ObjectCreationExpr. The SymbolSolver provided by JavaParser is then used to obtain the complete API signature. The API lifecycle information is then queried for the most recent change operation before the API signature Vnew, determining if it is an expired operation (deprecated, removed, hidden). If so, this node is designated as a key location for further analysis.

[0082] Starting from key locations, and expanding based on data dependencies and the mapping between code before and after the change, we can obtain the API use cases before and after the change. The data dependencies originate from the data flow, which is constructed from the VariableDeclarator (declaration), AssignExpr (assignment), and NameExpr (use) nodes in the syntax tree according to the code execution order.

[0083] The operation of expanding the statement set based on data dependencies is as follows:

[0084] 1) Input the statement set and data stream. Add all statements in the statement set to the queue to be checked. Initialize the set of checked statements.

[0085] 2) Remove the head of the statement from the queue to be checked. If the statement is already in the set of checked statements, repeat step 2). Add the statement to the set of checked statements. Search for the related statement sets. If any statement in the related statement sets is not in the set of checked statements, add it to the queue to be checked. Repeat step 2) until the queue to be checked is empty.

[0086] 3) For variables being read, the set of possible write statements from the previous data flow is used as the set of related statements; for variables being assigned values, the set of possible read statements from the next data flow is used as the set of related statements. The union of the sets of related statements for all variables in a statement is taken as the set of related statements for that statement.

[0087] During node mapping, the basic mapping is obtained using the ChangeDistiller implementation provided by GumTreeDiff, supplemented with unique feature information, to construct an anchor mapping set. Then, a many-to-many node mapping set is obtained through a path-based mapping diffusion strategy, and finally, the KM algorithm is used to converge it into a one-to-one mapping, resulting in the final node mapping set.

[0088] When updating the rules for the final storage instance, the test case pairs are serialized into byte arrays and stored in the database. This invention uses a JDBC driver and is compatible with two commonly used databases: SQLite and MySQL. The former does not require a server and stores the database as a local file, but SQL writes can only be executed in a single thread. The latter requires a running MySQL server. Users can choose according to their needs. Each rule contains information such as the set of expired APIs removed, the versions involved, the object binary, the project name, and the test case text before and after the change.

[0089] The third step involves removing redundancy from instance rules and calculating generalization support to improve the efficiency and accuracy of matching and sorting. In the initial redundancy removal, the GROUP BY operation in SQL is used to delete redundant instance update rules with identical new and old use case texts within the same project. Next, instances are selected pairwise, and the nodes of the use cases before and after the change are mapped to determine the generalization relationship. Based on the generalization relationship, mutually generalized instance rules can be considered equivalent and grouped together to further reduce redundancy. Simultaneously, the generalization support is calculated by determining how many other rules a given instance rule generalizes.

[0090] The fourth step involves the user using this method to locate target use cases that can be updated within the project space. The current target software library version v can be obtained from the project's build file. c The method first checks the target software library version declared in the project to be updated. Using SQL statements, it queries the rule base for simple and instance rules applicable to versions prior to this one, compiling a set of APIs that can be updated. It then checks the package and class names imported by each code file, filtering out code files that use the target software library's APIs. Next, this method searches within the file for the names of APIs that can be updated, thus identifying potential key locations. The method parses the code file, locates the node containing the potential key location, parses the specific API signature, and determines if it's in the set of updatable APIs. If so, this node is a key node. Through the preceding steps, the method finds the code files containing the target use cases and their list of key nodes. At this point, the method generates a report listing the found files and locations, and provides jump links. These links lead to the corresponding location within the file, where the method expands the location based on data dependencies to obtain the target use cases and highlights the code.

[0091] The fifth step involves matching appropriate rules to the target use case and sorting the rules. A rule library is searched based on the APIs involved in key locations to obtain a set of relevant update rules. Then, each selected instance update rule is mapped to a node in the target use case. If a key node in the target use case is not mapped, the instance update rule is discarded. Simple update rules have the highest priority, and instance update rules are evaluated using a score. A joint score (G, m, Nb, -Nsd) is calculated, and the rules are sorted lexicographically to generate a rule queue. If a simple update rule exists, it is added to the head of the queue. This method provides a visual interface, allowing users to try each update rule sequentially and see the corresponding update results.

[0092] Step 6: Update the target use case using the update rule. If the update rule is a simple update rule, then use the corresponding type of updater to modify the code of the target use case. Here, we take the class name modification updater as an example. The rule records the original class name and the target class name. The specific execution flow is as follows:

[0093] 1) Modify the import section, changing the original class name to the target class name.

[0094] 2) If a critical node contains a SimpleName type node with a value of the original class name, replace it with a SimpleName node with a value of the target class name.

[0095] 3) If the critical node is object creation, then modify the constructor method name.

[0096] 4) Modify the class name part of the declaration section in the target use case. If the original class name is matched, modify it to the target class name.

[0097] If the update rule is an instance update rule, the instance updater is used to modify the code of the target use case. Node mapping is performed between the target use case and the use case before the change. Irrelevant (unmapped) target use case statements are filtered out. Then, edit operations are extracted by establishing a connection bridge and replayed. During hierarchical traversal of target use case nodes, if the node has already been deleted in the edit operations extracted from the parent node, the processing of that subtree is interrupted. The logic for determining the connection bridge is as follows:

[0098] 1) Obtain the mapping node n of the target use case node nt in the use case before the change. o If n does not exist o No connecting bridge.

[0099] 2) Determine n t With n o To determine if there are structural differences, we need to check if the two nodes have the same type, interface usage, and number of child nodes. Then, we traverse the child node list in the same order, comparing the identities of child nodes at the same position and the content of text child nodes. Here, child node identity refers to the role a child node represents within its parent node. In this invention, its value is the name of a member variable of the Java class to which the parent node belongs, obtained at runtime via Java reflection.

[0100] 3) If n o There is no mapping node n n Then record (n) t n o A broken bridge (n) indicates a structural difference in the use case before and after the change. It cannot be directly interpreted as a removal operation, so it is stored in a broken bridge set. When a descendant node has a connecting bridge, the broken bridge is removed. n If it exists, it is considered a connection bridge has been discovered, and then the editing and extraction operation is performed.

[0101] From n o With n n Edit and extract from the differences, applied to nt When adding a new statement, attempt to delete any nodes that have already been used. If a syntax error occurs after deletion, continue deleting the parent node until the entire statement is deleted. If the entire statement is deleted, do not insert it. Finally, delete the remaining statements from the broken bridge to obtain the updated code. Evaluate the final code. If the updated use cases do not remove critical nodes or contain syntax errors, display the use cases before and after the change for the user's reference. If the update is successful, display the updated result to the user.

Claims

1. A method for automatically updating API use cases based on change information from both the library and the customer project, characterized in that, Specifically, it includes the following steps: Step 1: Analyze API changes between adjacent versions of the target software library, extract API change operations in each version and store them as API lifecycle information, and generate simple update rules using the change information. The specific implementation process is as follows: Download the distribution package of the target software library and read the version sequence information. Use two adjacent version JAR packages as analysis objects, and analyze the two versions of JAR packages using two open-source JAR package difference analysis tools, clirr and japicmp. Analyze the output results of clirr and japicmp, extract common changes to generate simple update rules; analyze the output results of clirr and japicmp to obtain a comprehensive set of API changes related to operation types within the version range; collect the API change sets between all adjacent versions to obtain the API lifecycle information. Step 2: Search the customer's project change history, extract evolution-related change code based on API lifecycle information, and generate instance update rules; Step 3: Redundancy removal and generalization support calculation are performed on the instance update rules; Step 4: Use all expired API information involved in the update rules to detect and locate the target project that needs to be updated; Step 5: Match the update rules and use an evaluation strategy based on generalization support and mapping matching degree to score and rank the results; Step 6: Update using update rules; If it's a simple update rule, the corresponding simple updater is used to modify the code of the key nodes. If it's an instance update rule, the code is modified using an edit operation porting method based on abstract syntax tree node mapping. The specific implementation process is as follows: 61) Utilize the node mapping results between the pre-change use cases and the target use cases to remove statements in the target use cases that do not have mappings, thereby simplifying the target use cases; 62) Locate connecting bridges, record broken bridges, and extract editing operations based on connecting bridges; 63) Apply editing operations to modify target use cases in a fine-grained manner; When inserting variables into the modified use case, they are escaped into the equivalent variables in the target use case based on the mapping relationship of the data nodes; Update the context information of the target use case; 64) Insert statements that were not used during the editing process. Based on the nodes that have been migrated to the target use case and the relative position of the statements in the changed use case, locate the insertion position of the new statements in the nodes of the target use case. 65) Delete the broken bridge nodes that still exist in the broken bridge set.

2. The method for automatically updating API use cases based on changes to both the library and customer projects as described in claim 1, characterized in that, In step 1, based on the group and name information of the target software library input by the user, the release packages of each version of the software library are automatically retrieved; by using the incremental changes of adjacent version release packages, API lifecycle information and simple update rules are analyzed to obtain.

3. The method for automatically updating API use cases based on changes to both the library and customer projects as described in claim 1, characterized in that, The specific implementation process of step 2 is as follows: 21) Quickly locate code changes related to version evolution: use the project build file to parse version information, find commits that changed the version and related code changes, and use API lifecycle information to find removed expired API calls as key locations; If the critical location is within the method declaration body, collect paired use cases within the method body; 22) Map nodes to the abstract syntax tree of the method body code; 23) Within the method body, collect paired test cases: Initialize the set of key statements before the change, and add statements where key positions are located; expand the set of key statements before the change based on data dependencies; then, for the expanded set, obtain the mapping nodes of the statements in the set in the changed code according to the mapping relationship, and obtain the set of key statements after the change; then expand the set of key statements after the change based on data dependencies. If there are new statements, map them to the statements before the change and re-execute the expansion mapping logic of the key statements before the change; otherwise, return the result directly. 24) Construct and save instance update rules: For the API use cases before and after the change obtained in 23), remap the nodes and delete statements that are mapped to each other and have the same content; if an expired API is removed in the use case change and a new non-expired API is introduced, then the use case change is determined to be related to the software library version change; then serialize and save the use case objects before and after the change, as well as the version information involved.

4. The method for automatically updating API use cases based on changes to both the library and customer projects as described in claim 1, characterized in that, The specific implementation process of step 3 is as follows: 31) Preliminary redundancy removal: Remove redundancy in the same use cases before and after the same change within the same project; 32) Determine the generalization relationship and remove redundancy by grouping according to the generalization relationship: First, group the rules according to the set of expired APIs to be removed, and compare each pair within the group to obtain the set of generalization relationships; 33) Grouping based on generalization relationship to further remove redundancy: When two instance update rules are mutually generalized, they are considered equivalent; equivalent instance update rules are aggregated into a group, and the first one is selected as the representative use case; 34) Generalization support of rule update: The number of times a rule generalizes to other rules is counted as the generalization support G, which is used as the scoring basis for ranking a rule when it is applied later.

5. The method for automatically updating API use cases based on changes to both the library and customer projects as described in claim 1, characterized in that, The specific implementation process of step 4 is as follows: 41) Obtain the set of modifiable APIs: Query the set of rules available in the current version from the rule base, take the union of the expired APIs that have been removed from them, and obtain the set of modifiable APIs. 42) Search for key locations: Using the simple names of the API set obtained in 41), perform a text search in the code file, parse the matching code content, and if the parsed API signature is in the set of modifiable APIs, then it is determined to be a key location. 43) Obtain the target use case: If the key location is in the initial value of the member variable, then use that initial value expression as the target use case; If it is within the method body, it is expanded based on data dependencies to obtain a set of target key statements, which are then sorted and used as the initial target use cases to await updates.

6. The method for automatically updating API use cases based on changes to both the library and customer projects as described in claim 5, characterized in that, The specific implementation process of step 5 is as follows: 51) Obtain the candidate update rule set: Use 42) to obtain the API signature corresponding to the key node, search for the update rule related to it in the update rule library; map the pre-change use case and the target use case in the rule to nodes in turn, and filter and retain the update rules that can be mapped to the key position; 52) Generate an ordered rule queue: simple update rules have the highest priority, while instance update rules are sorted based on evaluation of generalization support and mapping matching degree.

7. The method for automatically updating API use cases based on changes to both the library and customer projects as described in claim 3, characterized in that, 22) Mapping nodes in the abstract syntax tree of the method body code. The specific implementation process is as follows: 221) Use ChangeDistiller's node mapping logic to perform basic mapping on the nodes in the method body abstract syntax tree to obtain the initial anchor point set; 222) Find nodes in the syntax tree that have unique features on both sides and have the same features, and add them to the anchor set; unique features refer to the unique API calls, unique types, and unique content that the node contains in the use case that other nodes do not have; 223) Filter common nodes; 224) In the syntax tree, the roles and positions of child nodes are used as edges connecting parent and child nodes. Starting from the anchor point, adjacent nodes with the same edge value are added to the anchor point set, thus spreading the mapping relationship. 225) The KM algorithm is used to transform many-to-many mappings in a mapping set into one-to-one mappings. However, using the KM algorithm requires evaluating the connection weights between nodes. The calculation method for the connection weights between two nodes is as follows: NS pq It represents the number of pairs of nodes p and q whose parent nodes have unique mappings. SC t S is the matching coefficient for feature t. tpq It is the common value of nodes p and q on feature t. When the two nodes are the same on feature t, the value is 1, otherwise the value is 0; T is the selected feature set.

8. The method for automatically updating API use cases based on changes to both the library and customer projects as described in claim 6, characterized in that, In step 52, the instance update rules are evaluated by score, and the evaluation method is as follows: 521) Based on the mapping results in 51), the number N of mapped node pairs is obtained. matched This leads to the degree of matching between the rules and the target use cases, m = N. matched / N o N o This is the total number of nodes in the use cases before the change; 522) Calculate the number of connection bridges; among the mapping node pairs of the target use case and the use case before the change, there exist mapping node pairs of the same type and without structural differences (n t n o If n o Mapping node n also exists in the modified use case. n Then it is called (n) t n o n n The three nodes and their mapping relationships form a bridge; count the number of bridges N. b ; 523) Calculate the difference N between the number of use case statements before and after the change in the instance update rule. sd ; 524) Generalization support G of read instance update rules; 525) Calculate the joint fraction (G, m, N) b -N sd The instance update rules are sorted in lexicographical reverse order.

9. The method for automatically updating API use cases based on changes to both the library and the customer project as described in claim 1, characterized in that, The specific implementation process of extracting and editing operations using the connecting bridge in step 62) is as follows: 621) Perform a hierarchical traversal of the target use case nodes to find connecting bridges; 622) Extract editing operations from the connecting bridge; if n o With n t Different node types are considered replacement operations; if n o With n t If the node types are the same, then a simple subtree of height 2 is constructed, n o With n t As the root node, its direct child nodes are leaf nodes. Changes to tree nodes are extracted using the GumTreeDiff tool. When extracting changes, nodes with mapping relationships or data equivalence are considered as the same node. 623) Convert the diff result output by the GumTreeDiff tool to obtain the result for n. t The operation.

Images