Intelligent analysis method, device and equipment for function change and storage medium

Abstract

The application discloses a function change intelligent analysis method and device, equipment and storage medium, relates to the project development and management technical field, and includes: obtaining the change code content between the benchmark version and the current version of the to-be-analyzed project, and determining a function change node according to the change code content; constructing a function change graph based on the calling relationship of the function change node; assigning an initial change cost factor to the function change node, and the initial change cost factor is used to represent the change degree of the change code content; according to the function change graph, the initial change cost factor is cost apportioned, the change cost factor apportioning value of the upstream node is obtained, and whether the corresponding graph node exists function change is determined according to the initial change cost factor and the change cost factor apportioning value. Since the initial change cost is cost apportioned to the upstream along the function change graph, the major change and the minor change are differentiated, and the problem of abnormal expansion of the calculation result is avoided.

Description

Technical Field

[0001] This application relates to the field of project development and management technology, and in particular to intelligent analysis methods, devices, equipment and storage media for functional changes. Background Technology

[0002] Function point methodology is an important method for measuring the size of software development projects. When automatically calculating function points, the code is usually abstracted into structured elements through the Automated Function Point (AFP) standard, which is then mapped to function point definitions to achieve automatic function point generation.

[0003] Currently, when a project is integrated into a system or its version changes, the system monitors whether there are any changes (additions / deletions / modifications) to the code (classes / methods) between the base version and the current version, counting each added, modified, and deleted function separately. This approach does not define the propagation weight of changes in the call chain. If node A changes, and node A is called by node B, then node B is considered to contain the change. Under this logic, as long as any changed node exists on the path, the root node of this path is marked as 1. This can lead to situations where even minor changes cause abnormally inflated calculation results, resulting in severe distortion of project size measurements and causing significant management problems. Summary of the Invention

[0004] The main objective of this application is to provide an intelligent parsing method, apparatus, device, and storage medium for functional changes, aiming to solve the technical problem that existing functional parsing schemes are prone to causing abnormal expansion of calculation results.

[0005] To achieve the above objectives, this application proposes an intelligent parsing method for function changes, which includes: Obtain the changed code content of the project to be parsed between the base version and the current version, and determine the functional change nodes based on the changed code content, wherein the current version is the version after the base version is changed; A function change graph is constructed based on the calling relationship of the function change nodes. The function change graph contains several graph nodes, and the graph nodes include the function change nodes and upstream nodes that directly or indirectly call the function change nodes. An initial change cost factor is assigned to the functional change node, and the initial change cost factor is used to characterize the degree of change of the change code content; The initial change cost factor is allocated according to the functional change map to obtain the change cost factor allocation value of the upstream node, and the existence of functional change for the corresponding map node is determined according to the initial change cost factor and the change cost factor allocation value.

[0006] In one embodiment, the step of allocating the initial change cost factor according to the functional change map to obtain the change cost factor allocation value of the upstream node includes: The functional change node is taken as the current node, and the current node with a direct upstream node is taken as the node to be allocated according to the functional change graph. The change cost factor value of the node to be allocated is evenly distributed to each of the direct upstream nodes based on the number of the direct upstream nodes to obtain the allocation value of each direct upstream node. The allocated value of each of the direct upstream nodes is used as the change cost factor value of the corresponding direct upstream node; Each of the aforementioned direct upstream nodes is taken as a new current node, and the process returns to the step of taking the current node with a direct upstream node as the node to be allocated according to the functional change graph, until the new current node has no direct upstream node. If the new current node does not have a direct upstream node, the change cost factor value corresponding to each direct upstream node shall be used as the change cost factor allocation value of each upstream node.

[0007] In one embodiment, the step of determining whether a functional change exists for the corresponding graph node based on the initial change cost factor and the change cost factor allocation value includes: The change cost of the corresponding graph node is obtained by summing the initial change cost factor of each graph node and the allocated value of the change cost factor of the corresponding graph node. When the cost of changing a map node is not less than a preset cost threshold, it is determined that the map node has undergone a functional change. When the cost of changing a graph node is less than a preset cost threshold, the graph node is verified for functional changes.

[0008] In one embodiment, the step of assigning an initial change cost factor to the function change node includes: Based on the statistics of the changed code content corresponding to the function change node, the number of lines of code change for the function change node is determined. The initial change cost factor of the function change node is determined based on the proportion of the number of lines of code changes in the corresponding code content of the function change node.

[0009] In one embodiment, the step of obtaining the changed code content of the project to be parsed between the base version and the current version, and determining the functional change node based on the changed code content, includes: Obtain the baseline code and baseline topology of the baseline version of the project to be parsed, as well as the current code and current topology of the current version; Based on the baseline code and the current code, change identification is performed to obtain the changed code content; Based on the changed code content, a functional change node is determined in the baseline topology or the current topology.

[0010] In one embodiment, the step of constructing a function change graph based on the call relationship of the function change nodes includes: Based on the tracing of the function change node in the baseline topology and the current topology, the first calling relationship of the function change node in the baseline topology and the second calling relationship in the current topology are obtained; When the change type of the function change node is deletion, a function change graph is constructed based on the first call relationship; If the change type of the function change node is not a deletion type, a function change graph is constructed based on the second call relationship.

[0011] In one embodiment, the step of obtaining the baseline code and baseline topology of the baseline version of the project to be parsed includes: Obtain the base code of the base version of the project to be parsed; Based on the aforementioned baseline code, front-end code parsing is performed to obtain the front-end topology of the project to be parsed; and... Based on the benchmark code, the backend code is parsed to obtain the backend topology of the project to be parsed. The call chain is pruned on the backend topology to obtain the pruned backend topology; By concatenating the front-end topology and the pruned back-end topology into microservice topologies, a baseline topology for the project to be parsed is obtained.

[0012] Furthermore, to achieve the above objectives, this application also proposes a functionally modified intelligent analysis device, which includes: The feature change identification module is used to obtain the changed code content of the project to be parsed between the base version and the current version, and to determine the feature change node based on the changed code content, wherein the current version is the version after the base version is changed; A change graph generation module is used to construct a function change graph based on the calling relationship of the function change nodes. The function change graph contains several graph nodes, and the graph nodes include the function change nodes and upstream nodes that directly or indirectly call the function change nodes. The change cost management module is used to assign an initial change cost factor to the function change node, and the initial change cost factor is used to characterize the degree of change of the change code content; The change factor allocation module is used to allocate the initial change cost factor according to the functional change map, obtain the change cost factor allocation value of the upstream node, and determine whether there is a functional change for the corresponding map node based on the initial change cost factor and the change cost factor allocation value.

[0013] In addition, to achieve the above objectives, this application also proposes a smart parsing device with functional changes, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the smart parsing method with functional changes as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the intelligent parsing method for functional changes as described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the intelligent parsing method for functional changes as described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: This application obtains the changed code content of the project to be analyzed between the baseline version and the current version, and determines the functional change nodes based on the changed code content; constructs a functional change graph based on the call relationship of the functional change nodes; assigns an initial change cost factor to the functional change nodes, which is used to characterize the degree of change of the changed code content; allocates the cost of the initial change cost factor according to the functional change graph to obtain the change cost factor allocation value of the upstream node, and determines whether there is a functional change for the corresponding graph node based on the initial change cost factor and the change cost factor allocation value. Because the degree of change of the changed code content is characterized by the initial change cost factor, the degree of change is quantified, avoiding the indiscriminate treatment of minor and major modifications as changes. By allocating the initial change cost upstream along the functional change graph, the change is distributed level by level to the upstream nodes, effectively filtering out minor changes and preventing upstream nodes from being misjudged as functional changes; major changes are correctly identified and accurately determined as functional changes. The two types of changes are treated differently, avoiding the problem of abnormally inflated calculation results. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating the intelligent parsing method for functional changes in this application, provided in Embodiment 1. Figure 2 A schematic diagram illustrating the cost amortization of changes to the intelligent parsing method for functional changes in this application, provided in Embodiment 1. Figure 3 A flowchart illustrating the second embodiment of the intelligent parsing method for functional changes in this application; Figure 4 A flowchart illustrating the intelligent parsing method embodiment three for functional changes in this application; Figure 5 This is a schematic diagram of the module structure of the intelligent parsing device with functional modifications according to an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the intelligent parsing method for functional changes in the embodiments of this application.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The main solution of this application embodiment is as follows: First, obtain the changed code content of the project to be parsed between the base version and the current version, and determine the functional change nodes based on the changed code content, wherein the current version is the version after the base version is changed. Second, construct a functional change graph based on the calling relationship of the functional change nodes, wherein the functional change graph contains several graph nodes, including functional change nodes and upstream nodes that directly or indirectly call the functional change nodes. Third, assign an initial change cost factor to the functional change nodes, the initial change cost factor being used to characterize the degree of change in the changed code content. Fourth, allocate the initial change cost factor according to the functional change graph to obtain the change cost factor allocation value of the upstream nodes, and determine whether the corresponding graph node has a functional change based on the initial change cost factor and the change cost factor allocation value.

[0024] In code change analysis scenarios, a functional change node (i.e., a low-level method or function that has been modified, added, or deleted) is typically located downstream in the code call chain. This means that this change node is often called directly or indirectly by several upstream nodes. The current typical approach, after identifying the change node, traces back up the code call chain, marking all upstream nodes that can be traced back to the change node as having undergone a functional change, and then calculating function points for each one. This approach treats all upstream nodes equally, regardless of the magnitude of the change (e.g., modifying a single line of logging code versus modifying hundreds of lines of business logic code), and all are judged as having undergone a functional change. Under this method, a minor low-level change may trigger dozens or even hundreds of upstream functional nodes to be mistakenly judged as having undergone a functional change, causing serious distortion in the function point calculation results.

[0025] This application provides a solution that introduces a change cost factor and a cost-sharing mechanism. By assigning an initial change cost factor to identified functional change nodes, this factor characterizes the degree of change in the code content, quantifying the severity or impact weight of functional changes and avoiding treating all changes the same. This solution constructs a functional change graph based on the call relationships of functional change nodes. The initial change cost factor of each functional change node is then distributed upstream along the call chain. As the change cost propagates upstream, it is continuously dispersed along the branches of the call relationship. If a change node has multiple upstream callers, its change cost is shared by all upstream callers, rather than each upstream caller receiving a complete change cost value independently. Therefore, after multi-level distribution, the change cost is further diluted when propagating to higher-level nodes. The limited cost of a minor underlying change, after propagating upwards to multiple levels of upstream nodes, will have its distributed value approaching zero or becoming very small, preventing a situation where a minor change causes all upstream nodes in a call chain to be considered changed, thus suppressing the escalation of functional point changes.

[0026] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or virtual device capable of performing the above functions. The following description uses a functionally modified intelligent parsing device (hereinafter referred to as the parsing device) as an example to illustrate this embodiment and the subsequent embodiments.

[0027] Based on this, embodiments of this application provide an intelligent parsing method for function changes, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the intelligent parsing method for functional changes in this application.

[0028] In this embodiment, the intelligent parsing method for function changes includes steps S10 to S40: Step S10: Obtain the changed code content of the project to be parsed between the base version and the current version, and determine the function change node based on the changed code content, wherein the current version is the version after the base version is changed.

[0029] It should be noted that the above-mentioned project to be parsed can refer to a software project that requires function point scale measurement, a project that needs to be added to the system, or a project that has been added to the system and needs to be updated, such as an application system that is under development or maintenance. This application embodiment does not limit this.

[0030] It is understandable that the aforementioned baseline version can refer to the code version of the project to be analyzed before the code changes occurred. This version can serve as a reference benchmark for subsequent changes, such as the initial version determined when the project started or the version at the end of the previous settlement cycle. The aforementioned current version can refer to the code version of the project to be analyzed after code modifications, additions, or deletions based on the baseline version. This current version is the version after code changes have occurred relative to the baseline version, such as the production version when the project is completed and ready for deployment.

[0031] In practical applications, neither the base version nor the current version is fixed; rather, they change continuously based on project content, progress, and updates. Before an application or interface is updated, its corresponding version is the base version; after the update, it becomes the current version.

[0032] It should be noted that the aforementioned code changes can refer to the specific code changes that have occurred in the project's code as it has evolved from the base version to the current version, including newly added lines of code, modified lines of code, and deleted lines of code.

[0033] It should be explained that the aforementioned functional change node can refer to a code element node in the code topology of the project to be parsed that has been identified as having undergone functional changes due to the appearance of changed code content. This functional change node can be used to represent the specific code unit corresponding to the changed code content, such as a method, function, or class that has been changed.

[0034] In practical use, to obtain information about code changes that have occurred during the version evolution of the project to be parsed, and to determine which of these changes are functional change nodes, the parsing device first acquires the code data of the project under the baseline version and the code data under the current version. The baseline version is the code version before the change occurred, and the current version is the code version formed after the code change to the baseline version. Next, the processor compares the code data of the baseline version and the code data of the current version line by line or structure by structure to identify the code content that differs between the two, and identifies this differing code content as the changed code content. Subsequently, based on the identified changed code content, the processor locates the code element node corresponding to the changed code content in the code topology of the project to be parsed, and identifies the located code element node as the functional change node.

[0035] Step S20: Construct a function change graph based on the calling relationship of the function change nodes. The function change graph contains several graph nodes, including the function change nodes and upstream nodes that directly or indirectly call the function change nodes.

[0036] It should be noted that the aforementioned functional change graph can refer to a directed relational graph structure constructed by tracing upstream along the code call chain, starting from a functional change node. This graph structure can be used to represent the call relationship network between a functional change node and its upstream nodes that directly or indirectly call the functional change node.

[0037] It is understood that the aforementioned graph node can refer to each code element node included in the feature change graph. This graph node can correspond to a code unit in the code topology, such as a feature change node, or a method node that directly calls a feature change node, or a class node that indirectly calls a feature change node, etc. The code topology can be determined based on the base code corresponding to the base version, or it can be determined based on the current code corresponding to the current version. This application embodiment does not impose any restrictions on this.

[0038] It should be understood that the aforementioned upstream nodes can be used to characterize code element nodes that, in a code call relationship, precede a feature change node and directly or indirectly call that feature change node. A direct call can refer to a code element node's method or function body directly calling another code element node, such as a method calling a class, where there is a direct call statement between them. An indirect call can refer to a code element node ultimately calling another code element node through a call chain of one or more intermediate nodes. For example, if A calls B, B calls C, and C calls change node D, then A and B are both upstream nodes that indirectly call feature change node D, and C is an upstream node that directly calls feature change node D.

[0039] In practical implementation, when the parsing device identifies a functional change node, to clarify the upstream scope of its influence in the code topology, a functional change graph can be constructed based on the node's call relationships. Specifically, the parsing device can obtain the position information of the functional node in the code topology and use it as the starting point to trace back along the code call chain towards the functional change node. During this backward tracing, the parsing device can first find all upstream nodes in the code topology that directly call the functional change node and include these direct upstream nodes in the functional change graph. Subsequently, the parsing device can continue to use these direct upstream nodes as new search objects to further search for higher-level nodes that directly call these upstream nodes, until it reaches the entry node of the code topology or a node where there are no higher-level callers. Through this step-by-step backward tracing, the parsing device can include the functional change node itself and all upstream nodes associated with it through direct or indirect call relationships as graph nodes in the functional change graph, and use the call relationships between these graph nodes as connecting edges in the graph, thereby constructing a complete functional change graph.

[0040] Step S30: Assign an initial change cost factor to the function change node. The initial change cost factor is used to characterize the degree of change of the change code content. Step S40: Allocate the initial change cost factor according to the functional change map to obtain the change cost factor allocation value of the upstream node, and determine whether there is a functional change for the corresponding map node based on the initial change cost factor and the change cost factor allocation value.

[0041] It should be noted that the aforementioned initial change cost factor can refer to a quantitative value assigned to a functional change node, which can be used to characterize the degree of change in the code content. In this embodiment, the value of this quantitative value can be any value within the range of [0, 1]. For example, when the change magnitude of the functional change node is large, the initial change cost factor can be assigned a value close to 1; when the change magnitude of the functional change node is small, the initial change cost factor can be assigned a value close to 0. The aforementioned change cost factor allocation value can refer to the change cost allocation value obtained by each upstream node from the functional change node according to the calling relationship during the cost allocation process of the initial change cost factor.

[0042] It is understandable that the above-mentioned change cost factor allocation value is used to reflect the magnitude of the change impact that upstream nodes need to bear due to their direct or indirect calling relationship with the functional change node. The specific size of this allocation value depends on the position and number of branches of the upstream node in the change graph.

[0043] In some embodiments of this application, in order to determine whether a functional change exists for a corresponding graph node based on the initial change cost factor and the allocated value of the change cost factor, the step of determining whether a functional change exists for a graph node includes: accumulating the initial change cost factor of each graph node and the allocated value of the change cost factor for the corresponding graph node to obtain the change cost of the corresponding graph node; determining that a functional change exists for the graph node when the change cost of the graph node is not less than a preset cost threshold; and verifying the functional change of the graph node when the change cost of the graph node is less than the preset cost threshold.

[0044] It should be noted that the aforementioned preset cost threshold can be a pre-set critical value used to determine whether a graph node has undergone a functional change. This critical value is used to compare with the change cost of the graph node to determine whether the graph node has reached the minimum cost standard for being identified as having undergone a functional change. The aforementioned functional change verification can refer to a further verification process implemented on the graph node when the change cost of the graph node is not greater than the preset cost threshold. This verification process is used to exclude genuine functional changes that may be missed due to filtering by the cost allocation threshold.

[0045] It is important to understand that functional change verification differs from direct judgment based on change cost thresholds. Instead, it employs more refined analysis methods to perform secondary checks on nodes, such as verification through code line-level change difference analysis or call chain structure change analysis. This application does not limit the specific verification method, and different verification methods can be adopted according to the needs of actual applications.

[0046] In some embodiments of this application, the schematic diagram of cost amortization in the solution of this application can be as follows: Figure 2 As shown.

[0047] Reference Figure 2 In one component of this application embodiment, there are graph nodes controller A, controller B, controller C, function D, function F, and function E. Among them, function D and function E are functional change nodes whose code content has been changed. In the example, the initial change cost factor of D and E is set to 1 (with a value range of [0, 1]), and the other unchanged nodes are set to 0.

[0048] Understandably, since functions D, F, and controller C directly call the change function E, these three nodes are direct upstream nodes of the function change node E. The initial change cost factor of function change node E can be evenly distributed across these three nodes, meaning each node receives a cost of 0.33. Function change node D itself has also undergone changes and has amortized the change cost of E, therefore its total change cost becomes 1.33. This cost can be truncated, setting the total change cost to 1. In other words, when the change cost of a graph node is not less than the preset cost upper limit, the change cost of the graph node is set to the preset cost upper limit.

[0049] It should be noted that the preset cost upper limit can be equal to or different from the preset cost threshold, and this application embodiment does not impose any restrictions on this.

[0050] It should be understood that since controller A and controller B respectively share the change costs of D and F, controller A receives an allocation value of 1, and controller B receives an allocation value of 0.33. Looking at the change cost factors allocated to A, B, and C, function A has a larger change cost, indicating more internal changes. Functions B and C have smaller change costs, suggesting that changes to these functions were minor or that changes occurred in common areas.

[0051] In some embodiments of this application, in order to set an initial change cost factor, the step of assigning an initial change cost factor to the functional change node includes: statistically analyzing the change code content corresponding to the functional change node to determine the number of lines of code change for the functional change node; and determining the initial change cost factor for the functional change node based on the proportion of the number of lines of code change in the code content corresponding to the functional change node.

[0052] It should be explained that the aforementioned number of lines of code changed can refer to the number of lines of code that have changed within the code content corresponding to the feature change node. This number of lines of code changed is used to quantify the extent of code changes involved in the feature change node. The specific statistical method for counting lines of code changed can include any combination of one or more of the following: newly added lines of code, modified lines of code, and deleted lines of code. The aforementioned code content corresponding to the feature change node can refer to the entire code content of the code unit represented by the feature change node, such as the complete method body code corresponding to a method node. The aforementioned percentage can refer to the proportion of the number of changed lines of code in the total number of lines of code in the code content corresponding to the feature change node. This percentage is used to reflect the scope of the impact of the changed code content relative to the entire code unit.

[0053] In some embodiments of this application, a change list in which transaction functions have been changed can be identified through the above method. After identifying the controller interface (controller function node) in the change list, the number of File Type Referenced (FTR) and Data Element Type (DET) can be calculated based on the function change graph.

[0054] It should be noted that the number of referenced file types refers to the total number of internal logic files and external interface files read or maintained during the processing of a transaction function, which is the sum of the number of input and output parameter attributes of the controller function node. The number of data element types refers to the number of data items that a transaction function needs to input, view, or output when used by the user, which is the sum of the number of database operation tables involved in a leaf node of a function chain and the number of external request interfaces.

[0055] It is understood that the above-mentioned transaction functions are the functions corresponding to the top-level entry node, such as the methods defined in the back-end controller layer (corresponding to the controller function node), the UI interactive elements in the front-end page, etc., and this application embodiment does not limit them.

[0056] It should be understood that when the underlying utility class changes, the system can trace back along the functional change graph until it finds the controller functional node with an in-degree of 0, thereby determining whether the controller functional node is a functional change node, as well as the number of referenced file types and data element types corresponding to the controller functional node.

[0057] In some embodiments of this application, after determining the functional change nodes, a candidate list of change files can be generated based on these functional change nodes. This candidate list of change files can be used to characterize a set of file nodes that may undergo functional changes, and may include file nodes of different file types.

[0058] In some embodiments of this application, since two sets of topology graphs corresponding to the baseline version and the current version have been established, the external interface nodes corresponding to the external interface files can be filtered out from the controller entry node down to the leaf nodes, such as nodes marked with @FeignClient. For these external interface nodes, if they exist in the baseline topology but not in the current topology, it can be said that they have been deleted; if they do not exist in the baseline topology but exist in the current topology, it can be said that they are newly added file nodes; if they exist in both the baseline topology and the current topology, it can be said that they have been modified.

[0059] In some embodiments of this application, the referenced database script files can be filtered out, and information such as table names, column names, and modification types can be extracted by parsing, thereby realizing the identification of internal logic files.

[0060] In some embodiments of this application, each candidate Controller node in the topology graph can be scanned at a fixed point to identify the source code corresponding to the Controller node and determine the corresponding node parameters. By recursively decomposing the attribute tree of the parameter, the number of leaf fields can be counted, and the number of leaf fields can be used as the DET value of the Controller node to be backfilled into the graph.

[0061] It should be noted that this node parameter can be used to define the data format and set of fields that the system allows for external input. Specifically, the node parameter can be the @RequestBody parameter (such as CreateOrderReq).

[0062] In some embodiments of this application, the record element type of the candidate Controller node can be identified as 1, and the record element type can be used to measure the complexity of data functions.

[0063] In some embodiments of this application, for internal logical files, the corresponding record element type is also fixedly identified as 1, while the DET value can be identified as the number of table field changes. The number of field changes can be used to characterize the columns added or modified in the database table during version updates.

[0064] This application's embodiments obtain the changed code content of the project to be parsed between the baseline version and the current version, and determine the functional change nodes based on the changed code content; construct a functional change graph based on the call relationship of the functional change nodes; assign an initial change cost factor to the functional change nodes, which is used to characterize the degree of change in the changed code content; allocate the initial change cost factor according to the functional change graph to obtain the change cost factor allocation value of the upstream node, and determine whether there is a functional change in the corresponding graph node based on the initial change cost factor and the change cost factor allocation value. Since the degree of change in the changed code content is characterized by the initial change cost factor, the degree of change is quantified, avoiding the indiscriminate treatment of minor and major modifications as changes. By allocating the initial change cost upstream along the functional change graph, the change is distributed level by level to the upstream nodes, effectively filtering out minor changes and preventing upstream nodes from being misjudged as functional changes; major changes are correctly identified and accurately determined as functional changes. The two types of changes are treated differently, avoiding the problem of abnormally inflated calculation results.

[0065] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the intelligent parsing method for functional changes in this application.

[0066] like Figure 3 As shown in the embodiment of this application, the step of allocating the initial change cost factor according to the functional change map to obtain the change cost factor allocation value of the upstream node includes: Step S410: Take the function change node as the current node, and take the current node with a direct upstream node as the node to be allocated according to the function change graph. Step S420: Based on the number of direct upstream nodes of the node to be allocated, the change cost factor value of the node to be allocated is evenly distributed to each of the direct upstream nodes to obtain the allocation value of each of the direct upstream nodes.

[0067] It is understandable that a direct upstream node is an upstream node that has a direct calling relationship with the current node in the function change graph, while an indirect upstream node is an upstream node that has an indirect calling relationship with the current node in the function change graph. For example, in a node call chain A calls B and B calls C, C is the current node, B is the direct calling node of C, and A is the indirect calling node of C.

[0068] It should be noted that the aforementioned nodes to be allocated refer to the nodes in the functional change graph whose change cost factor values ​​need to be evenly distributed to upstream nodes. By evenly distributing the change cost factor values ​​to upstream nodes, each direct upstream node can receive an equal allocation value. This application distributes the change cost factor level by level to upstream nodes. During the propagation of the initial change cost factor of a functional change node to upstream nodes, the total value of the change cost factor allocated at each level remains unchanged, and the number of identified functional point changes will not abnormally inflate due to changes in the number of upstream nodes.

[0069] Understandably, the average cost factor value of the current node is distributed equally among the direct upstream nodes.

[0070] Step S430: The allocated value of each of the direct upstream nodes is used as the change cost factor value of the corresponding direct upstream node; Step S440: Each of the directly upstream nodes is taken as a new current node, and the process returns to the step of taking the current node with a directly upstream node as the node to be allocated according to the functional change graph, until the new current node has no directly upstream node. Step S450: If the new current node does not have a direct upstream node, the change cost factor value corresponding to each direct upstream node is used as the change cost factor allocation value of each upstream node.

[0071] It should be noted that the allocation value of the direct upstream node is used as the change cost factor value of that upstream node, and the change cost factor value is used as the current node to continue traversing upstream until all nodes in the functional change graph have been traversed and the corresponding change cost factor values ​​are obtained.

[0072] In some embodiments of this application, since the functional change graph may contain multiple functional change nodes with changed code content, the same node (such as the direct upstream node of the current node) may also be allocated to multiple allocation values. In this case, the allocation values ​​can be accumulated to obtain the corresponding total allocation value, and this total allocation value can be used as the corresponding change cost factor value.

[0073] In some embodiments of this application, nodes in the functional change graph may have multiple roles (e.g., a functional change node, and a direct upstream node of another functional change node). In this case, the total allocated value of the node can be added to its corresponding initial change cost factor, and the result can be used as its corresponding change cost factor value. Simultaneously, this change cost factor value can be used to determine whether a corresponding graph node has undergone a functional change.

[0074] In some embodiments of this application, since the change cost factor value of a node may exceed the preset cost upper limit (e.g., greater than 1), it can be directly set to 1.

[0075] It should be noted that when a graph node is not a functional change node, its corresponding initial change cost factor can be set to zero; when a graph node is only a functional change node, its corresponding change cost factor allocation value can be set to zero.

[0076] This application embodiment uses a functional change node as the current node. Based on the functional change graph, current nodes with direct upstream nodes are designated as nodes to be allocated cost. The change cost factor value of the node to be allocated is evenly distributed to each direct upstream node based on the number of direct upstream nodes, obtaining an allocation value for each direct upstream node. The allocation value of each direct upstream node is then used as the change cost factor value for its corresponding direct upstream node. Each direct upstream node is then designated as a new current node, and the process returns to the step of designating current nodes with direct upstream nodes as nodes to be allocated cost based on the functional change graph, until the new current node has no direct upstream nodes. If the new current node has no direct upstream nodes, the change cost factor value corresponding to each direct upstream node is used as the change cost factor allocation value for each upstream node. This application ensures that the total change cost after each propagation level remains the same as before propagation by dividing the change cost factor value of the node to be allocated by the number of direct upstream nodes in each propagation stage. This prevents the cost from increasing due to the number of branches, eliminating the cost inflation caused by call chain branches and keeping the total propagation cost of the change constant. The change cost factor value of a node in this application is determined by three factors: whether its own code has been directly changed, whether the code of the downstream nodes that are directly or indirectly called has been changed, and the number of direct downstream nodes or indirect upstream nodes that have undergone code changes. This means that the branch density of a graph node's position in the call chain directly affects the change cost factor allocation value it receives. Therefore, the determination of a functional change is related to the actual position of the graph node in the call chain. Whether an upstream node is determined to have a functional change depends on the actual size of its allocated change cost factor value, rather than whether there is a call relationship between the node and the changed node. This allows the determination of whether a functional change exists to be based on this objectively quantified allocation value, avoiding the uncertainty of manual judgment and improving the objectivity and consistency of the determination results.

[0077] Based on the first and / or second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to the first and / or second embodiments described above can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a flowchart illustrating the intelligent parsing method embodiment three for functional changes in this application.

[0078] like Figure 4 As shown in this embodiment, the step of obtaining the changed code content of the project to be parsed between the base version and the current version, and determining the functional change node based on the changed code content, includes: Step S110: Obtain the baseline code and baseline topology of the baseline version of the project to be parsed, as well as the current code and current topology of the current version.

[0079] It is understood that the aforementioned baseline code refers to the code corresponding to the project to be parsed in the baseline version, and the aforementioned baseline topology refers to the topology constructed based on the baseline code. This baseline topology can be a directed graph structure used to represent the calling relationships between code elements in the baseline version. The aforementioned current code refers to the code corresponding to the project to be parsed in the current version, and the aforementioned current topology refers to the topology constructed based on the current code. This current topology can also be a directed graph structure used to represent the calling relationships between code elements in the current version.

[0080] This application embodiment does not restrict the specific methods for obtaining the baseline code, baseline topology, and current code and current topology; the methods can be selected according to the needs of actual applications. In this application embodiment, taking the acquisition of baseline code and baseline topology as an example, the steps of obtaining the baseline code and baseline topology of the baseline version of the project to be parsed include: obtaining the baseline code of the baseline version of the project to be parsed; performing front-end code parsing based on the baseline code to obtain the front-end topology of the project to be parsed; and performing back-end code parsing based on the baseline code to obtain the back-end topology of the project to be parsed; performing call chain pruning on the back-end topology to obtain the pruned back-end topology; and performing microservice topology concatenation on the front-end topology and the pruned back-end topology to obtain the baseline topology of the project to be parsed.

[0081] It should be noted that the aforementioned front-end code parsing refers to the process of performing lexical and syntactic analysis on the front-end source code of the project to be parsed, converting the source code text into an abstract syntax tree structure, and extracting front-end code elements and their inter-call relationships from the abstract syntax tree. The aforementioned back-end code parsing refers to the process of scanning and analyzing the back-end source code or bytecode of the project to be parsed, and extracting back-end code elements and their inter-call relationships.

[0082] It is understandable that front-end code parsing and back-end code parsing are two parsing methods for different technology stacks; the former is for front-end framework code, and the latter is for back-end code.

[0083] For example, in the front end, the embodiments of this application can scan the source code of the React / Vue front end project and parse it into an Abstract Syntax Tree (AST). Then, the front end elements can be divided into pages, components, tags, events, functions and interfaces from large to small. Among them, pages, components and tags are interactive user interface (UI) features. Then, the calling relationship between elements is obtained through tag matching and common library parsing, and finally the front end topology is obtained.

[0084] For example, in the backend, embodiments of this application can use BCEL technology to scan the code, obtain class and method information and the calling relationship between methods, and connect the entire link of the component from the entry point to database operations and interface methods to obtain the backend topology.

[0085] It's important to note that a typical component can have hundreds of thousands of call chains between methods. Therefore, call chain pruning can be used to remove useless and interfering methods, such as the get and set methods provided by Lombok, class constructors, and dependencies not belonging to this product. Call chain pruning can identify and remove non-critical nodes from the backend topology. Simultaneously, the call relationships of these removed non-critical nodes are passed to their directly associated upstream and downstream nodes, thus preserving the processing flow of call logic between critical nodes.

[0086] This application does not impose restrictions on the identification methods of the above-mentioned key nodes or non-key nodes. The method can be selected according to the needs of actual application, such as using the labeling method or neural network recognition.

[0087] It should be noted that the above-mentioned microservice topology concatenation can refer to the process of merging and connecting the front-end topology and the back-end topology according to their mutual calling relationships to form a complete end-to-end topology structure covering both the front-end and the back-end.

[0088] For example, when connecting microservice topologies, the request URI (i.e., the target URI) obtained from scanning the frontend code can be matched with the URI exposed by the backend entry node (controller node). Alternatively, the Feign layer call URI (i.e., the target URI) obtained from scanning the backend code can be matched with the URI exposed by the backend entry node (controller node). During matching, the request methods corresponding to the URIs at both ends (i.e., the URI exposed by the controller node and the target URI) can be determined and segmented according to a preset identifier (such as / ) to obtain the number of segmented path segments. By comparing whether the number of path segments of the target URI and the URI exposed by the controller node are the same, and whether the HTTP request methods (GET, POST, PUT, DELETE, etc.) are consistent, if both are consistent, the subsequent matching proceeds; if they are inconsistent, the matching fails. For URIs where the number of path segments and the request methods are consistent, each path segment of the URI exposed by the controller node can be used as a matching pattern and matched segment by segment with each path segment corresponding to the target URI to obtain the number of successfully matched path segments. If the difference between the number of segmented path segments and the number of successfully matched path segments is less than a preset threshold, then the match is considered successful and the two ends are concatenated.

[0089] Step S120: Based on the baseline code and the current code, perform change identification to obtain the changed code content; Step S130: Based on the change code content, determine the function change node in the baseline topology or the current topology.

[0090] It is understandable that the baseline topology mentioned above corresponds to the code structure state before the code change, while the current topology corresponds to the code structure state after the code change. By comparing the baseline code and the changed code to identify the change, the content of the changed code can be determined.

[0091] In some embodiments of this application, the step of constructing a function change graph based on the calling relationship of the function change node includes: tracing the function change node in the baseline topology and the current topology to obtain a first calling relationship of the function change node in the baseline topology and a second calling relationship in the current topology; constructing a function change graph based on the first calling relationship when the change type of the function change node is a deletion type; and constructing a function change graph based on the second calling relationship when the change type of the function change node is not a deletion type.

[0092] It should be noted that code changes typically involve three scenarios: addition, deletion, and modification. Additions and modifications can be found in the current topology corresponding to the current version, while deletions require finding the corresponding functional change graph in the baseline topology corresponding to the base version. Therefore, the first calling relationship mentioned above represents the direct and indirect calling relationships of the functional change node in the baseline topology. Based on these relationships, the direct and indirect upstream nodes of the functional change node can be determined, thus constructing the functional change graph corresponding to the baseline topology. Similarly, the second calling relationship represents the direct and indirect calling relationships of the functional change node in the current topology. Based on these relationships, the direct and indirect upstream nodes of the functional change node can be determined, thus constructing the functional change graph corresponding to the current topology.

[0093] It is understandable that during project development or maintenance, additions, deletions, and modifications are usually involved simultaneously. Therefore, in this application embodiment, there may be a first functional change map constructed based on the first calling relationship and a second functional change map constructed based on the second calling relationship.

[0094] This application embodiment obtains the baseline code and baseline topology of the baseline version of the project to be parsed, as well as the current code and current topology of the current version; it identifies changes based on the baseline code and current code to obtain the changed code content; and it determines the functional change node in the baseline topology or the current topology based on the changed code content. Since the functional change node is determined in the baseline topology or the current topology based on the changed code content, if the change node no longer exists in the current topology, it can be determined from the baseline topology, avoiding the problem of being unable to locate the node due to its non-existence; and if the change node does not exist in the baseline topology, it can be determined from the current topology. The determination of the functional change node is always performed in the topology where the node actually exists, and will not cause location failure due to the singularity of topology selection.

[0095] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the intelligent parsing method for changing the function of this application. Any simple transformations based on this technical concept are within the protection scope of this application.

[0096] This application also provides a smart analysis device with modified functions, please refer to... Figure 5 , Figure 5 This is a schematic diagram of the module structure of the intelligent parsing device with modified functions according to an embodiment of this application. The intelligent parsing device with modified functions includes: The function change identification module 10 is used to obtain the changed code content of the project to be parsed between the base version and the current version, and to determine the function change node based on the changed code content, wherein the current version is the version after the base version is changed; The change graph generation module 20 is used to construct a function change graph based on the calling relationship of the function change nodes. The function change graph contains a number of graph nodes, and the graph nodes include the function change nodes and upstream nodes that directly or indirectly call the function change nodes. The change cost management module 30 is used to assign an initial change cost factor to the function change node, and the initial change cost factor is used to characterize the degree of change of the change code content; The change factor allocation module 40 is used to allocate the initial change cost factor according to the functional change map, obtain the change cost factor allocation value of the upstream node, and determine whether there is a functional change for the corresponding map node based on the initial change cost factor and the change cost factor allocation value.

[0097] The intelligent parsing device for function changes provided in this application, employing the intelligent parsing method for function changes in the above embodiments, can solve the technical problem that existing function parsing schemes easily lead to abnormally inflated calculation results. Compared with the prior art, the beneficial effects of the intelligent parsing device for function changes provided in this application are the same as those of the intelligent parsing method for function changes provided in the above embodiments, and other technical features in the intelligent parsing device for function changes are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0098] This application provides a functionally modified intelligent parsing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the functionally modified intelligent parsing method in the first embodiment described above.

[0099] The following is for reference. Figure 6 This document illustrates a structural schematic diagram of an intelligent parsing device suitable for implementing functional changes in the embodiments of this application. The intelligent parsing device with functional changes in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The illustrated intelligent parsing device with modified functions is merely an example and should not impose any limitations on the functions and scope of use of the embodiments of this application.

[0100] like Figure 6As shown, the functionally modified intelligent parsing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the functionally modified intelligent parsing device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the modified smart parsing device to communicate wirelessly or wiredly with other devices to exchange data. While the figures show modified smart parsing devices with various systems, it should be understood that implementing or possessing all of the systems shown is not required. More or fewer systems may be implemented alternatively.

[0101] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0102] The intelligent parsing device with modified functions provided in this application, employing the intelligent parsing method with modified functions in the above embodiments, can solve the technical problem that existing functional parsing schemes easily cause abnormal expansion of calculation results. Compared with the prior art, the beneficial effects of the intelligent parsing device with modified functions provided in this application are the same as the beneficial effects of the intelligent parsing method with modified functions provided in the above embodiments, and other technical features in this intelligent parsing device with modified functions are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0103] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0104] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0105] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the intelligent parsing method for functional changes in the above embodiments.

[0106] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0107] The aforementioned computer-readable storage medium may be included in the intelligent parsing device with modified functionality; or it may exist independently and not be assembled into the intelligent parsing device with modified functionality.

[0108] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by a functionally modified intelligent parsing device, cause the functionally modified intelligent parsing device to: Obtain the changed code content of the project to be parsed between the base version and the current version, and determine the functional change nodes based on the changed code content, wherein the current version is the version after the base version is changed; A function change graph is constructed based on the calling relationship of the function change nodes. The function change graph contains several graph nodes, and the graph nodes include the function change nodes and upstream nodes that directly or indirectly call the function change nodes. An initial change cost factor is assigned to the functional change node, and the initial change cost factor is used to characterize the degree of change of the change code content; The initial change cost factor is allocated according to the functional change map to obtain the change cost factor allocation value of the upstream node, and the existence of functional change for the corresponding map node is determined according to the initial change cost factor and the change cost factor allocation value.

[0109] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0110] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0111] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0112] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the intelligent parsing method for the aforementioned functional changes. This addresses the technical problem that existing functional parsing schemes easily lead to abnormally inflated calculation results. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the intelligent parsing method for functional changes provided in the above embodiments, and will not be elaborated upon here.

[0113] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the intelligent parsing method for functional changes as described above.

[0114] The computer program product provided in this application can solve the technical problem that existing function parsing schemes easily lead to abnormally inflated calculation results. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the intelligent parsing method for function changes provided in the above embodiments, and will not be repeated here.

[0115] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A method for intelligent parsing of functional changes, characterized in that, The method includes: Obtain the changed code content of the project to be parsed between the base version and the current version, and determine the functional change nodes based on the changed code content, wherein the current version is the version after the base version is changed; A function change graph is constructed based on the calling relationship of the function change nodes. The function change graph contains several graph nodes, and the graph nodes include the function change nodes and upstream nodes that directly or indirectly call the function change nodes. An initial change cost factor is assigned to the functional change node, and the initial change cost factor is used to characterize the degree of change of the change code content; The initial change cost factor is allocated according to the functional change map to obtain the change cost factor allocation value of the upstream node, and the existence of functional change for the corresponding map node is determined according to the initial change cost factor and the change cost factor allocation value.

2. The intelligent parsing method for function changes as described in claim 1, characterized in that, The step of allocating the initial change cost factor according to the functional change map to obtain the change cost factor allocation value of the upstream node includes: The functional change node is taken as the current node, and the current node with a direct upstream node is taken as the node to be allocated according to the functional change graph. The change cost factor value of the node to be allocated is evenly distributed to each of the direct upstream nodes based on the number of the direct upstream nodes to obtain the allocation value of each direct upstream node. The allocated value of each of the direct upstream nodes is used as the change cost factor value of the corresponding direct upstream node; Each of the aforementioned direct upstream nodes is taken as a new current node, and the process returns to the step of taking the current node with a direct upstream node as the node to be allocated according to the functional change graph, until the new current node has no direct upstream node. If the new current node does not have a direct upstream node, the change cost factor value corresponding to each direct upstream node shall be used as the change cost factor allocation value of each upstream node.

3. The intelligent parsing method for functional changes as described in claim 1, characterized in that, The step of determining whether there is a functional change for the corresponding map node based on the initial change cost factor and the allocated value of the change cost factor includes: The change cost of the corresponding graph node is obtained by summing the initial change cost factor of each graph node and the allocated value of the change cost factor of the corresponding graph node. When the cost of changing a map node is not less than a preset cost threshold, it is determined that the map node has undergone a functional change. When the cost of changing a graph node is less than a preset cost threshold, the graph node is verified for functional changes.

4. The intelligent parsing method for function changes as described in claim 1, characterized in that, The step of assigning an initial change cost factor to the function change node includes: Based on the statistics of the changed code content corresponding to the function change node, the number of lines of code change for the function change node is determined. The initial change cost factor of the function change node is determined based on the proportion of the number of lines of code change in the corresponding code content of the function change node.

5. The intelligent parsing method for functional changes as described in claim 1, characterized in that, The steps of obtaining the changed code content of the project to be parsed between the base version and the current version, and determining the functional change nodes based on the changed code content, include: Obtain the baseline code and baseline topology of the baseline version of the project to be parsed, as well as the current code and current topology of the current version; Based on the baseline code and the current code, change identification is performed to obtain the changed code content; Based on the changed code content, a functional change node is determined in the baseline topology or the current topology.

6. The intelligent parsing method for function changes as described in claim 5, characterized in that, The step of constructing a function change graph based on the call relationship of the function change nodes includes: Based on the tracing of the function change node in the baseline topology and the current topology, the first calling relationship of the function change node in the baseline topology and the second calling relationship in the current topology are obtained; When the change type of the function change node is deletion, a function change graph is constructed based on the first call relationship; If the change type of the function change node is not a deletion type, a function change graph is constructed based on the second call relationship.

7. The intelligent parsing method for functional changes as described in claim 5, characterized in that, The steps of obtaining the baseline code and baseline topology of the baseline version of the project to be parsed include: Obtain the base code of the base version of the project to be parsed; Based on the aforementioned baseline code, front-end code parsing is performed to obtain the front-end topology of the project to be parsed; and... Based on the benchmark code, the backend code is parsed to obtain the backend topology of the project to be parsed. The call chain is pruned on the backend topology to obtain the pruned backend topology; By concatenating the front-end topology and the pruned back-end topology into microservice topologies, a baseline topology for the project to be parsed is obtained.

8. A smart analysis device with variable function, characterized in that, The intelligent analysis device for the functional changes includes: The feature change identification module is used to obtain the changed code content of the project to be parsed between the base version and the current version, and to determine the feature change node based on the changed code content, wherein the current version is the version after the base version is changed; A change graph generation module is used to construct a function change graph based on the calling relationship of the function change nodes. The function change graph contains several graph nodes, and the graph nodes include the function change nodes and upstream nodes that directly or indirectly call the function change nodes. The change cost management module is used to assign an initial change cost factor to the function change node, and the initial change cost factor is used to characterize the degree of change of the change code content; The change factor allocation module is used to allocate the initial change cost factor according to the functional change map, obtain the change cost factor allocation value of the upstream node, and determine whether there is a functional change for the corresponding map node based on the initial change cost factor and the change cost factor allocation value.

9. A smart analysis device with variable functionality, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the intelligent parsing method for functional changes as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the intelligent parsing method for functional changes as described in any one of claims 1 to 7.

Images