Software system dependency defect tracking method and system based on graph database

Abstract

The invention provides a software system dependency defect tracking method and system based on a graph database, and relates to the technical field of software, and the method comprises the steps: parsing a source code into an abstract syntax tree, and extracting a dependency; constructing a dependency graph data model; establishing a defect mode feature library; performing pattern matching in the graph data model to identify potential defects; calculating a defect influence range and severity; and generating a defect tracking report, including defect priority ranking, complete call chain construction, defect detailed information recording and optimization suggestion generation. According to the method, the dependency relationship defect in a software system can be effectively identified and tracked, and the software quality is improved.

Description

Technical Field

[0001] The present invention relates to software technology, and in particular to a method and system for tracking software system dependency defects based on a graph database. Background Art

[0002] Existing dependency analysis methods mainly rely on static code analysis tools, which can usually only provide simple dependency graphs and are difficult to deeply analyze complex dependency structures. In addition, these tools often lack the ability to intelligently identify and classify dependency defects and cannot effectively locate and evaluate potential problems.

[0003] Traditional defect tracking methods usually use manual review, which is time-consuming and labor-intensive, and is prone to missing some hidden dependency issues. At the same time, existing automated tools often lack quantitative analysis of the severity and impact of defects when generating defect reports, and cannot provide targeted optimization suggestions, making it difficult for developers to effectively fix problems and optimize code. Summary of the invention

[0004] The embodiments of the present invention provide a software system dependency defect tracking method and system based on a graph database, which can solve the problems in the prior art.

[0005] According to a first aspect of the embodiments of the present invention,

[0006] Provides a software system dependency defect tracking method based on a graph database, including:

[0007] Parsing the source code file of the software system into an abstract syntax tree; extracting the class definition, method definition, variable definition and the calling relationship and inheritance relationship between them in the source code file from the abstract syntax tree; constructing the class definition, the method definition and the variable definition as nodes in a graph database respectively, and establishing directed edges between corresponding nodes based on the calling relationship and the inheritance relationship to obtain a dependency graph data model;

[0008] Construct a defect pattern feature library containing circular dependencies, unused components, and repeated dependencies; use the traversal algorithm of the graph database to perform pattern matching in the dependency graph data model, and identify the subgraph structure that matches the features in the defect pattern feature library; for each matching subgraph structure, extract the node information and edge information involved therein, and mark it as a potential defect; calculate the impact range and severity of each potential defect based on the node information and the edge information;

[0009] A defect tracking report is generated based on the impact scope and severity of the potential defect, specifically including: prioritizing the potential defects according to the severity; for each potential defect, backtracing and constructing a complete call chain caused by the defect based on the dependency graph data model; adding the type, location, impact scope, severity and complete call chain information of the potential defect to the defect tracking report; generating optimization suggestions for each potential defect based on the complete call chain information, and adding the optimization suggestions to the defect tracking report.

[0010] The class definition, the method definition, and the variable definition are respectively constructed as nodes in a graph database, and directed edges are established between corresponding nodes based on the call relationship and the inheritance relationship, so as to obtain a dependency graph data model including:

[0011] Configure the properties of the class definition node, method definition node, and variable definition node in the software system. The class definition node includes a class name property, a package path property, an access modifier property, and an inheritance relationship property. The method definition node includes a method name property, a parameter list property, a return type property, and a class property. The variable definition node includes a variable name property, a data type property, a scope property, and an initial value property.

[0012] An inheritance relationship directed edge is established between the class definition nodes using a creation statement of a graph database, the edge attribute of the inheritance relationship directed edge records the inherited access level, and the inheritance relationship directed edge points from the child class node to the parent class node; based on the call statement in the method body, a call relationship directed edge is established between the method definition nodes, the edge attribute of the call relationship directed edge includes call location information and call parameter information, and the call relationship directed edge points from the calling method node to the called method node; according to the declaration position and reference position of the variable, a usage relationship directed edge is established between the method definition node and the variable definition node, the edge attribute of the usage relationship directed edge records the usage information and usage location information of the variable, and the usage relationship directed edge points from the method definition node that uses the variable to the used variable definition node;

[0013] A first composite index is established on the class name attribute and the package path attribute of the class definition node, a second composite index is established on the method name attribute and the belonging class attribute of the method definition node, and a third composite index is established on the variable name attribute and the scope attribute of the variable definition node; the creation operations of the class definition node, the method definition node, the variable definition node, and the inheritance relationship directed edge, the call relationship directed edge, and the usage relationship directed edge are encapsulated and executed in the same transaction to ensure the atomicity of the node creation and edge creation operations; a graph traversal query statement is constructed based on the first composite index, the second composite index, and the third composite index to obtain component dependency information in the software system and obtain a dependency graph data model.

[0014] Using a traversal algorithm of a graph database to perform pattern matching in the dependency graph data model, identifying a subgraph structure that matches the features in the defect pattern feature library includes:

[0015] A depth-first traversal algorithm is used to construct a circular dependency detection query statement. The circular dependency detection query statement obtains a circular dependency path with a path length greater than a preset threshold by matching variable-length call paths between class nodes, and extracts the starting class node identifier, path node sequence, and loop depth information in the circular dependency path; an unused component detection query statement is constructed based on a reverse traversal strategy. The unused component detection query statement obtains the class name information and package path information of the class node by matching class nodes that do not have incoming call relationship edges and incoming inheritance relationship edges; a breadth-first traversal algorithm is used to construct a repeated dependency detection query statement. The repeated dependency detection query statement obtains method node pairs whose call times exceed a preset threshold by counting the number of call relationship edges between method nodes;

[0016] Add an active tag attribute to the class node, the active tag attribute is used to identify the class node with an outgoing call relationship; establish a node access index on the class name field and the package path field of the active tag attribute; construct an incremental matching query statement, the incremental matching query statement is based on the last modification timestamp of the node, and only performs dependency detection on the newly added class nodes and the modified class nodes;

[0017] When executing the circular dependency detection query statement, the matching paths are filtered based on the access level attributes of the relationship edges, and only the dependency paths with all public access levels are retained; when executing the unused component detection query statement, the matching results are filtered based on the package path attributes of the class nodes, and only the unused components across the package paths are retained; when executing the repeated dependency detection query statement, the repeated call paths are classified based on the call location information of the method nodes;

[0018] The detected dependency defect information is encapsulated as a defect pattern object, which includes a defect type identifier, involved node paths, node relationship types, call chain depth, and a detection timestamp; historical defect pattern objects that have exceeded the expiration time are deleted in the same database transaction, and the newly generated defect pattern objects are written into the graph database to identify the subgraph structure that matches the features in the defect pattern feature library.

[0019] The method further comprises:

[0020] Match the class nodes that do not have incoming call relationship edges and incoming inheritance relationship edges in the graph database, extract the class name information, package path information, and last modification time information of the class nodes; create an in-degree index for the class nodes, periodically count the sum of the number of call relationship edges and the number of inheritance relationship edges received by each class node, and update the sum of the numbers as the in-degree attribute value of the class node;

[0021] For class nodes with an in-degree attribute value of zero, collect the interface node name information implemented by the class node, extract the method name, visibility level, and parameter information of the method node contained in the class node; obtain the submission record for modifying the class node, and encapsulate the submission hash value, timestamp, author information, and submission information of the submission record as usage history data;

[0022] Record the most recent detection time of the class node, count the number of newly added call relationship edges that are later than the most recent detection time, update the number of newly added call relationship edges as the in-degree attribute value of the class node, and update the most recent detection time; collect the dependent class node set of the class node, determine the isolation level of the class node based on the number of the dependent class node set, and create an unused context object, which includes the component identifier, module name, number of dependencies, isolation level, and detection time;

[0023] Count the number of class nodes with zero in-degree attribute value contained in each module node, and calculate the ratio of the number of class nodes to the total number of class nodes contained in the module node; encapsulate the name information, path information, type information, module name of the unused context object, isolation level, detection time, code size, complexity, and last modification time of the class node into a detection report.

[0024] For each matched subgraph structure, extract the node information and edge information involved therein and mark them as potential defects; calculate the impact scope and severity of each potential defect based on the node information and the edge information, including:

[0025] For the defect pattern subgraph marked in the graph database, a defect feature vector is extracted, wherein the defect feature vector includes a node identifier, a node type, a node attribute set, a node in-degree value, and a node out-degree value; based on all paths from the start node to the end node in the defect pattern subgraph, path relationship features are extracted, wherein the path relationship features include a relationship type, a relationship attribute set, and a relationship weight value;

[0026] Based on the node identifiers in the defect feature vector, the number of direct dependency relationships between the nodes corresponding to the node identifiers is calculated to obtain a direct influence range, and the dependency strength is calculated based on the weight value of the direct dependency relationship; a dependency path whose length does not exceed a preset depth is matched between the nodes corresponding to the node identifiers, the number of nodes involved in the dependency path is counted to obtain a transfer influence range, and the transfer dependency strength is calculated based on the weight value of each relationship in the dependency path;

[0027] Calculate the ratio of the number of edges to the number of nodes in the defect mode subgraph to obtain a structural complexity index; calculate an average modification cost index based on the number of historical modifications of each node in the defect mode subgraph; encapsulate the calculation results of the direct impact range, the transfer impact range, the structural complexity index, and the average modification cost index into a defect assessment object, wherein the defect assessment object includes a defect identifier and an assessment timestamp;

[0028] Based on a preset time interval period, the most recent modification time information of the nodes in the defect mode subgraph is obtained, and various evaluation indicators are recalculated for the nodes whose most recent modification time information is later than the last evaluation time; the direct impact range, the transfer impact range, the structural complexity index, and the average modification cost index are respectively divided by the maximum values ​​of the corresponding indicators to obtain normalized scores, and the normalized scores are weighted based on the preset indicator weights to obtain a comprehensive evaluation score.

[0029] The potential defects are prioritized according to the severity; for each potential defect, a complete call chain generated by the defect is constructed based on the dependency graph data model, including:

[0030] Prioritize defects based on the comprehensive evaluation scores of defect evaluation objects, mark defects with a comprehensive evaluation score greater than a first preset threshold as critical level defects, and mark defects with a comprehensive evaluation score greater than a second preset threshold and less than the first preset threshold as high-risk level defects; calculate the time difference between the evaluation time of the defect evaluation object and the current time, calculate the time decay coefficient based on the time difference, and use the product of the comprehensive evaluation score and the time decay coefficient as the dynamic priority score of the defect;

[0031] For the critical level defects and the high-risk level defects, all call chain paths from the caller node to the target node are matched in the graph database, the path depth of the call chain path is counted, the method signature information of each node in the call chain path is extracted, and the call chain path is sorted in descending order based on the path depth; the most recent call chain analysis time of the target node is recorded, and the newly added call relationship later than the most recent call chain analysis time is obtained, and the call chain path from the entry node to the source node is matched based on the source node of the newly added call relationship;

[0032] Create a call context object, which includes the caller ID, callee ID, call times, code line number, method signature information, and recording time; based on the call chain path from the entry node to the target node, calculate the continuous product of the weights of each call relationship in the call chain path to obtain a propagation factor, and create an impact propagation object, which includes the defect ID, entry node signature, target node signature, path length, and impact factor;

[0033] Count the total number of call chain paths, average path length, and maximum impact factor corresponding to each defect, and encapsulate the total number of call chain paths, the average path length, the maximum impact factor, and the analysis timestamp as a link analysis result; encapsulate the defect identifier, dynamic priority score, call context object set, and link analysis result into a defect analysis report.

[0034] According to a second aspect of the embodiments of the present invention,

[0035] Provides a software system dependency defect tracking system based on a graph database, including:

[0036] The first unit is used to parse the source code file of the software system into an abstract syntax tree; extract the class definition, method definition, variable definition and the calling relationship and inheritance relationship between them in the source code file from the abstract syntax tree; construct the class definition, the method definition and the variable definition as nodes in a graph database respectively, and establish directed edges between corresponding nodes based on the calling relationship and the inheritance relationship to obtain a dependency graph data model;

[0037] The second unit is used to build a defect pattern feature library containing circular dependencies, unused components, and repeated dependencies; use the traversal algorithm of the graph database to perform pattern matching in the dependency graph data model, and identify the subgraph structure that matches the features in the defect pattern feature library; for each matching subgraph structure, extract the node information and edge information involved therein, and mark it as a potential defect; calculate the impact range and severity of each potential defect based on the node information and the edge information;

[0038] The third unit is used to generate a defect tracking report based on the impact scope and the severity of the potential defect, specifically including: prioritizing the potential defects according to the severity; for each potential defect, backtracing and constructing a complete call chain caused by the defect based on the dependency graph data model; adding the type, location, impact scope, severity and complete call chain information of the potential defect to the defect tracking report; generating optimization suggestions for each potential defect based on the complete call chain information, and adding the optimization suggestions to the defect tracking report.

[0039] According to a third aspect of the embodiments of the present invention,

[0040] An electronic device is provided, comprising:

[0041] processor;

[0042] a memory for storing processor-executable instructions;

[0043] The processor is configured to call the instructions stored in the memory to execute the aforementioned method.

[0044] According to a fourth aspect of the embodiments of the present invention,

[0045] A computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the aforementioned method is implemented.

[0046] The beneficial effects of this application are as follows:

[0047] 1. Improve the accuracy and efficiency of defect identification:

[0048] The present invention constructs the dependency relationship of the software system as a graph data model and uses the efficient traversal algorithm of the graph database for pattern matching, which can quickly and accurately identify defects such as circular dependencies, unused components, and repeated dependencies in the system. Compared with traditional methods, this graph-based method can more comprehensively capture complex dependency relationships and improve the coverage and accuracy of defect identification.

[0049] 2. Achieve accurate positioning and quantitative evaluation of defects:

[0050] The present invention can not only identify defects, but also extract the information of specific nodes and edges involved in the defects, and accurately locate the defect positions. At the same time, by calculating the impact range and severity of the defects, a quantitative evaluation of the defects is achieved, which helps developers to reasonably allocate resources and give priority to solving key defects.

[0051] 3. Provide comprehensive defect tracking reports and optimization suggestions:

[0052] The present invention constructs a complete call chain by backtracking, generates a comprehensive report containing information such as defect type, location, impact range, severity, etc., and provides targeted optimization suggestions based on the call chain information. This provides developers with detailed defect context information and improvement directions, helps to locate and solve problems more efficiently, and improves software quality. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 A schematic diagram of a process of tracking software system dependency defects based on a graph database according to an embodiment of the present invention;

[0054] Figure 2 It is a structural diagram of a software system dependency defect tracking system based on a graph database according to an embodiment of the present invention. DETAILED DESCRIPTION

[0055] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0056] The technical solution of the present invention is described in detail with specific embodiments below. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.

[0057] Figure 1 FIG. 1 is a flow chart of a method for tracking software system dependency defects based on a graph database according to an embodiment of the present invention. Figure 1 As shown, the method includes:

[0058] S101. Parse the source code file of the software system into an abstract syntax tree; extract the class definition, method definition, variable definition and the calling relationship and inheritance relationship between them in the source code file from the abstract syntax tree; construct the class definition, the method definition and the variable definition as nodes in a graph database respectively, and establish directed edges between corresponding nodes based on the calling relationship and the inheritance relationship to obtain a dependency graph data model;

[0059] S102. Construct a defect pattern feature library including circular dependencies, unused components, and repeated dependencies; use the traversal algorithm of the graph database to perform pattern matching in the dependency graph data model, and identify the subgraph structure that matches the features in the defect pattern feature library; for each matching subgraph structure, extract the node information and edge information involved therein, and mark it as a potential defect; calculate the impact range and severity of each potential defect based on the node information and the edge information;

[0060] S103. Generate a defect tracking report based on the impact scope and severity of the potential defect, specifically including: prioritizing the potential defects according to the severity; for each potential defect, backtracking and constructing a complete call chain caused by the defect based on the dependency graph data model; adding the type, location, impact scope, severity and complete call chain information of the potential defect to the defect tracking report; generating optimization suggestions for each potential defect based on the complete call chain information, and adding the optimization suggestions to the defect tracking report. Specific implementation method:

[0062] First, parse the source code file of the software system into an abstract syntax tree. This step can be done by using a parser suitable for a specific programming language. For example, for the Java language, you can use the JavaParser library; for C++, you can use the Clang library. The parser converts the source code into a tree structure, where each node represents a syntax element in the code.

[0063] Next, extract the class definition, method definition, variable definition, and the calling and inheritance relationships between them in the source code file from the abstract syntax tree. This step requires traversing the abstract syntax tree to identify the corresponding syntax elements. For example, for class definition, you can look for the ClassOrInterfaceDeclaration node; for method definition, you can look for the MethodDeclaration node; for variable definition, you can look for the VariableDeclarator node. At the same time, by analyzing the method call in the method body and the extends keyword in the class declaration, the calling and inheritance relationships can be identified.

[0064] The extracted information is then constructed as nodes and edges in a graph database. A graph database system such as Neo4j can be used to store this information. Each class, method, and variable is created as a node, and the node contains corresponding attributes such as name, type, etc. Call relationships and inheritance relationships are created as directed edges between nodes. For example, if method A calls method B, a directed edge labeled "CALLS" is created between the node representing method A and the node representing method B. This results in a dependency graph data model.

[0065] Next, a defect pattern feature library including circular dependencies, unused components, and repeated dependencies is constructed. A circular dependency can be defined as a structure where a series of nodes form a ring; an unused component can be defined as a node with an in-degree of 0; and a repeated dependency can be defined as the presence of multiple edges of the same type between two nodes. These features can be expressed using the Cypher query language.

[0066] Subsequently, the graph database’s traversal algorithm is used to perform pattern matching in the dependency graph data model. This can be achieved by executing a Cypher query for each defect pattern. For example, for a circular dependency, a query similar to "MATCH(n)-[:DEPENDS_ON*]->(n)RETURN n" can be used to find all nodes that form a cycle.

[0067] For each matched subgraph structure, the node information and edge information involved in it are extracted and marked as potential defects. This can be achieved by saving the query results into a data structure that contains the defect type, the involved nodes and edges detailed information.

[0068] Then, the impact scope and severity of each potential defect are calculated based on the node information and edge information. The impact scope can be measured by counting the number of nodes directly related to the defect. The severity can be calculated based on the impact scope, the weight of the defect type, and the importance of the involved components. For example, different base scores can be assigned to different types of defects, and then this score is multiplied by the impact scope and the importance coefficient of the involved components.

[0069] Next, a defect tracking report is generated based on the impact and severity of the potential defects. First, the potential defects are prioritized according to their severity, which can be achieved using algorithms such as quick sort.

[0070] For each potential defect, the complete call chain that caused the defect is constructed by backtracking based on the dependency graph data model. This can be achieved by starting from the defect-related node and tracing back to the root node along the incoming edges. For example, if a circular dependency is found, you can start from any node in the ring and trace up along the "DEPENDS_ON" edge until you can no longer continue.

[0071] Add the type, location, impact, severity, and complete call chain information of potential defects to the defect tracking report. This information can be organized in JSON or XML format to make it easy to process and display later.

[0072] Finally, optimization suggestions are generated for each potential defect based on the complete call chain information and added to the defect tracking report. Optimization suggestions can be generated based on the defect type and specific situation. For example, for circular dependencies, it can be recommended to introduce interfaces or use dependency injection to decouple; for unused components, it can be recommended to remove or re-evaluate their necessity; for duplicate dependencies, it can be recommended to merge or refactor related code.

[0073] Beneficial effects:

[0074] 1. Improved the detection efficiency and accuracy of software system dependency defects. By using graph databases and pattern matching algorithms, complex dependency defects, including circular dependencies, unused components, and duplicate dependencies, can be quickly identified, greatly improving the efficiency and accuracy of defect detection.

[0075] 2. Automated defect analysis and prioritization. By calculating the impact and severity of defects and sorting them based on these indicators, the development team can allocate resources more effectively and prioritize the most critical issues, thereby improving the efficiency of software quality improvement.

[0076] 3. Provides detailed defect tracking reports and optimization suggestions. By generating detailed reports containing complete call chains and optimization suggestions, it provides developers with clear problem location and solutions, helps speed up the defect repair process, improves code quality, and promotes better software architecture design.

[0077] In an optional implementation, the class definition, the method definition, and the variable definition are respectively constructed as nodes in a graph database, and directed edges are established between corresponding nodes based on the call relationship and the inheritance relationship, so that the dependency graph data model is obtained, including:

[0078] Configure the properties of the class definition node, method definition node, and variable definition node in the software system. The class definition node includes a class name property, a package path property, an access modifier property, and an inheritance relationship property. The method definition node includes a method name property, a parameter list property, a return type property, and a class property. The variable definition node includes a variable name property, a data type property, a scope property, and an initial value property.

[0079] An inheritance relationship directed edge is established between the class definition nodes using a creation statement of a graph database, the edge attribute of the inheritance relationship directed edge records the inherited access level, and the inheritance relationship directed edge points from the child class node to the parent class node; based on the call statement in the method body, a call relationship directed edge is established between the method definition nodes, the edge attribute of the call relationship directed edge includes call location information and call parameter information, and the call relationship directed edge points from the calling method node to the called method node; according to the declaration position and reference position of the variable, a usage relationship directed edge is established between the method definition node and the variable definition node, the edge attribute of the usage relationship directed edge records the usage information and usage location information of the variable, and the usage relationship directed edge points from the method definition node that uses the variable to the used variable definition node;

[0080] A first composite index is established on the class name attribute and the package path attribute of the class definition node, a second composite index is established on the method name attribute and the belonging class attribute of the method definition node, and a third composite index is established on the variable name attribute and the scope attribute of the variable definition node; the creation operations of the class definition node, the method definition node, the variable definition node, and the inheritance relationship directed edge, the call relationship directed edge, and the usage relationship directed edge are encapsulated and executed in the same transaction to ensure the atomicity of the node creation and edge creation operations; a graph traversal query statement is constructed based on the first composite index, the second composite index, and the third composite index to obtain component dependency information in the software system and obtain a dependency graph data model.

[0081] This embodiment provides a method for constructing a software system dependency graph data model. The method first parses the class definition, method definition, and variable definition in the software system, then constructs them as nodes in a graph database, and establishes directed edges between corresponding nodes based on call relationships and inheritance relationships, and finally obtains a dependency graph data model. The specific implementation steps are as follows:

[0082] Step 1: Configure graph database node properties;

[0083] Configure the properties of the class definition nodes, method definition nodes, and variable definition nodes parsed in the software system. The class definition node contains properties such as class name, package path, access modifier, inheritance relationship, etc. For example, for a class named "Student", you can configure the following properties:

[0084] Class name: Student;

[0085] Package path: com.example.model;

[0086] Access modifier: public;

[0087] Inheritance relationship: extends Person;

[0088] The method definition node contains attributes such as method name, parameter list, return type, and class. For example, for a getName() method in the Student class, you can configure the following attributes:

[0089] Method name: getName;

[0090] Parameter list: ();

[0091] Return type: String;

[0092] Class: Student;

[0093] The variable definition node contains attributes such as variable name, data type, scope, initial value, etc. For example, for a name variable in the Student class, you can configure the following attributes:

[0094] Variable name: name;

[0095] Data type: String;

[0096] Scope: private;

[0097] Initial value: null;

[0098] Step 2: Establish relationship edges between nodes;

[0099] The creation statement of the graph database is used to establish directed edges between related nodes to represent the relationship between them.

[0100] First, establish inheritance relationship directed edges between class definition nodes. The edge attribute of inheritance relationship directed edges records the inherited access level, pointing from child class nodes to parent class nodes.

[0101] Secondly, based on the call statements in the method body, a call relationship directed edge is established between the method definition nodes. The edge attributes of the call relationship directed edge include the call location information and call parameter information, and point from the calling method node to the called method node.

[0102] Finally, based on the declaration and reference locations of the variables, a usage relationship directed edge is established between the method definition node and the variable definition node. The edge attributes of the usage relationship directed edge record the variable usage information and usage location information, from the method definition node that uses the variable to the variable definition node that is used.

[0103] Step 3: Create a composite index;

[0104] In order to improve the query efficiency of graph database, composite indexes are established on related node attributes.

[0105] Create a first composite index on the class name attribute and the package path attribute of the class definition node. For example, use the following Neo4j statement:

[0106] CREATE INDEX class_index FOR(n:Class)ON(n.className,n.packagePath).

[0107] Create a second composite index on the method name attribute and the class attribute of the method definition node. For example:

[0108] CREATE INDEX method_index FOR(n:Method)ON(n.methodName,n.belongingClass).

[0109] Create a third composite index on the variable name attribute and scope attribute of the variable definition node. For example:

[0110] CREATE INDEX variable_index FOR(n:Variable)ON(n.variableName,n.scope).

[0111] Step 4: Encapsulate transaction operations;

[0112] The creation operations of class definition nodes, method definition nodes, variable definition nodes, and inheritance relationship directed edges, call relationship directed edges, and usage relationship directed edges are encapsulated and executed in the same transaction to ensure the atomicity of node creation and edge creation operations.

[0113] Step 5: Construct graph traversal query statement;

[0114] Based on the composite index established previously, a graph traversal query statement is constructed to obtain component dependency information in the software system.

[0115] By executing similar query statements, we can obtain information such as the inheritance relationship between classes, the calling relationship between methods, the usage relationship between methods and variables, and thus obtain a complete dependency graph data model.

[0116] The beneficial effects of this embodiment include:

[0117] 1. Improved the efficiency and accuracy of software system dependency analysis. By building class definitions, method definitions, and variable definitions as nodes in a graph database and establishing corresponding relationship edges, the dependencies between components in a software system can be analyzed quickly and accurately, helping developers better understand and maintain complex software systems.

[0118] 2. Enhanced query performance of dependency data. By establishing composite indexes on key attributes, the query efficiency of the graph database is significantly improved, allowing developers to quickly obtain the required dependency information, thereby improving the efficiency of software development and maintenance.

[0119] 3. Ensure the consistency and reliability of data operations. By encapsulating the creation of nodes and edges in the same transaction, the integrity and consistency of the dependency graph data model are ensured, effectively preventing data inconsistency problems caused by operation failures and improving the reliability of the system.

[0120] In an optional implementation, the traversal algorithm of the graph database performs pattern matching in the dependency graph data model, and identifying a subgraph structure that matches a feature in the defect pattern feature library includes:

[0121] A depth-first traversal algorithm is used to construct a circular dependency detection query statement. The circular dependency detection query statement obtains a circular dependency path with a path length greater than a preset threshold by matching variable-length call paths between class nodes, and extracts the starting class node identifier, path node sequence, and loop depth information in the circular dependency path; an unused component detection query statement is constructed based on a reverse traversal strategy. The unused component detection query statement obtains the class name information and package path information of the class node by matching class nodes that do not have incoming call relationship edges and incoming inheritance relationship edges; a breadth-first traversal algorithm is used to construct a repeated dependency detection query statement. The repeated dependency detection query statement obtains method node pairs whose call times exceed a preset threshold by counting the number of call relationship edges between method nodes;

[0122] Add an active tag attribute to the class node, the active tag attribute is used to identify the class node with an outgoing call relationship; establish a node access index on the class name field and the package path field of the active tag attribute; construct an incremental matching query statement, the incremental matching query statement is based on the last modification timestamp of the node, and only performs dependency detection on the newly added class nodes and the modified class nodes;

[0123] When executing the circular dependency detection query statement, the matching paths are filtered based on the access level attributes of the relationship edges, and only the dependency paths with all public access levels are retained; when executing the unused component detection query statement, the matching results are filtered based on the package path attributes of the class nodes, and only the unused components across the package paths are retained; when executing the repeated dependency detection query statement, the repeated call paths are classified based on the call location information of the method nodes;

[0124] The detected dependency defect information is encapsulated as a defect pattern object, which includes a defect type identifier, involved node paths, node relationship types, call chain depth, and a detection timestamp; historical defect pattern objects that have exceeded the expiration time are deleted in the same database transaction, and the newly generated defect pattern objects are written into the graph database to identify the subgraph structure that matches the features in the defect pattern feature library.

[0125] The defect pattern matching implementation method in the dependency graph data model first needs to build a circular dependency detection function. Through the depth-first traversal algorithm, the call path is explored layer by layer starting from the starting class node. The access status of the visited nodes is recorded during the traversal process. When a node is found to be visited repeatedly, it indicates that there is a circular dependency. The loop depth threshold is set to 5. When the length of the detected loop path exceeds the threshold, the loop path information is extracted. Take class A calling class B, class B calling class C, class C calling class D, class D calling class E, and class E calling class A as an example. The length of the loop path is 5, which constitutes a typical circular dependency scenario.

[0126] For the detection of unused components, a reverse traversal strategy is adopted. First, all class nodes in the graph database are obtained, and then for each class node, whether there is a call relationship edge or inheritance relationship edge pointing to the node. If a class node does not have any incoming edges, it is marked as an unused component. Taking the NodeVisitor class as an example, if the class is not called or inherited by any other class in the project, its class name "NodeVisitor" and package path "org.example.visitor" and other information are extracted.

[0127] Repeated dependency detection uses a breadth-first traversal algorithm. Starting from a method node, count the number of call relationship edges between other method nodes. Set the repeated call threshold to 3. When the number of calls between two method nodes exceeds this threshold, they are identified as repeated dependencies. For example, method A repeatedly calls method B 4 times, involving different call locations, and these calls need to be classified and sorted.

[0128] To improve detection performance, an active tag attribute is introduced on class nodes. When a class node has an external method call, its active tag attribute is set to true. Indexes are created on the class name and package path fields to speed up node queries. Incremental detection is implemented based on the last modified timestamp of the node, and dependency analysis is performed only on nodes that have changed. Class nodes with modification timestamps later than the last detection time are detected to avoid repeated analysis of unchanged code.

[0129] A filtering mechanism is introduced when performing dependency detection: Circular dependency detection is filtered based on the access level attribute of the relationship edge, and only the call path between public methods is analyzed; Unused component detection is filtered based on the package path attribute, focusing on unused classes across packages; Duplicate dependency detection is classified based on the code location information of method calls to distinguish duplicate calls in different locations.

[0130] The detection results are encapsulated in defect pattern objects, including defect type, involved nodes, relationship type, call depth, detection time and other information. For circular dependencies, the class node sequence that forms a closed loop is recorded; for unused components, the complete information of isolated nodes is recorded; for repeated dependencies, the repeated method pairs and call locations are recorded. These defect objects are maintained in database transactions, and invalid historical records are deleted and newly generated defect information is saved.

[0131] Finally, the detected dependency defects are matched with the predefined feature library to identify the dependency subgraph structure that meets the feature pattern. The feature library defines typical bad dependency patterns, including deep-level circular dependencies, cross-layer calls, module boundary violations, and other scenarios. Through the graph pattern matching algorithm, the detection results are compared with these predefined features to find potential architectural defects.

[0132] This multi-dimensional dependency analysis method comprehensively identifies dependency defects in the code through different traversal strategies and matching algorithms. The introduction of incremental detection and filtering mechanisms improves analysis efficiency, and the persistent management of defect patterns facilitates subsequent trend analysis and problem tracking.

[0133] In an optional embodiment, the method further includes:

[0134] Match the class nodes that do not have incoming call relationship edges and incoming inheritance relationship edges in the graph database, extract the class name information, package path information, and last modification time information of the class nodes; create an in-degree index for the class nodes, periodically count the sum of the number of call relationship edges and the number of inheritance relationship edges received by each class node, and update the sum of the numbers as the in-degree attribute value of the class node;

[0135] For class nodes with an in-degree attribute value of zero, collect the interface node name information implemented by the class node, extract the method name, visibility level, and parameter information of the method node contained in the class node; obtain the submission record for modifying the class node, and encapsulate the submission hash value, timestamp, author information, and submission information of the submission record as usage history data;

[0136] Record the most recent detection time of the class node, count the number of newly added call relationship edges that are later than the most recent detection time, update the number of newly added call relationship edges as the in-degree attribute value of the class node, and update the most recent detection time; collect the dependent class node set of the class node, determine the isolation level of the class node based on the number of the dependent class node set, and create an unused context object, which includes the component identifier, module name, number of dependencies, isolation level, and detection time;

[0137] Count the number of class nodes with zero in-degree attribute value contained in each module node, and calculate the ratio of the number of class nodes to the total number of class nodes contained in the module node; encapsulate the name information, path information, type information, module name of the unused context object, isolation level, detection time, code size, complexity, and last modification time of the class node into a detection report.

[0138] When implementing the method, it is first necessary to establish and maintain a graph database, which contains different types of nodes such as class nodes, method nodes, interface nodes, and different types of edges such as call relationship edges, inheritance relationship edges, etc. Each node in the graph database has a unique identifier and related attributes, such as class name, package path, last modification time, etc.

[0139] Next, we periodically traverse all class nodes in the graph database and identify those class nodes that do not have incoming call relationship edges and do not have incoming inheritance relationship edges. For each class node that meets the conditions, we extract its class name information (such as "UserService"), package path information (such as "com.example.service"), and last modification time information (such as "2023-05-0110:30:15"). This information will be used for subsequent analysis.

[0140] Then, create the class node in-degree index. Periodically (e.g., every morning) traverse all class nodes and count the sum of the number of call relationship edges and the number of inheritance relationship edges received by each class node. For example, if a class node receives 5 call relationship edges and 2 inheritance relationship edges, its in-degree attribute value is 7. Update this sum of numbers as the in-degree attribute value of the class node and store it in the graph database.

[0141] For class nodes with zero in-degree attribute value, further analysis is performed. First, all interface node name information implemented by the class node is collected, such as "Serializable", "Cloneable", etc. Secondly, relevant information of all method nodes contained in the class node is extracted, including method name (such as "getUserById"), visibility level (such as "public", "private"), parameter information (such as "Long id"), etc.

[0142] Next, obtain the version control system commit records that modify the node of this type. For each commit record, extract its commit hash value (such as "a1b2c3d4e5f6g7h8i9j0"), timestamp (such as "2023-04-1514:20:30"), author information (such as "John Doe"), and commit information (such as "Fix user authentication bug"). Encapsulate this information as usage history data for subsequent analysis.

[0143] In order to continuously monitor the usage of class nodes, record the last detection time of each class node. At each detection, count the number of newly added call relationship edges that are later than the last detection time. For example, if the last detection time is 2023-05-01 and the current detection time is 2023-05-08, count the number of newly added call relationship edges within these 7 days. Update this newly added number as the in-degree attribute value of the class node, and update the last detection time to the current time.

[0144] In addition, collect the dependent class node set of each class node. Traverse all outgoing call relationship edges and inheritance relationship edges of the class node, and add the target class nodes connected by these edges to the dependent class node set. Determine the isolation level of the class node based on the number of dependent class node sets. For example, you can set the dependency number 0-5 as a high isolation level, 6-15 as a medium isolation level, and 16 and above as a low isolation level.

[0145] Create an unused context object containing the following information: component ID (such as "USER-001"), module name (such as "user-management"), number of dependencies (such as "3"), isolation level (such as "high"), and detection time (such as "2023-05-0809:00:00"). This object is used to record and track relevant context information of unused classes.

[0146] Perform statistical analysis at the module level. For each module node, count the number of class nodes with zero in-degree attribute values. Calculate the ratio of this number to the total number of class nodes contained in the module node. For example, if a module contains 100 class nodes, of which 20 class nodes have zero in-degree attribute values, the ratio is 0.2 or 20%.

[0147] Finally, a detection report is generated. The name information, path information, type information of the class node, module name in the unused context object, isolation level, detection time, and code size (such as the number of lines of code), complexity (such as cyclomatic complexity), and last modification time of the class node are encapsulated in the detection report. This report can help the development team quickly identify and handle potential unused code.

[0148] The beneficial effects of this method are mainly reflected in three aspects:

[0149] 1. Improve code quality: By identifying and tracking unused classes, the development team can clean up redundant code in a timely manner, reduce the complexity of the code base, and improve the overall code quality. This not only helps reduce maintenance costs, but also improves system performance and readability.

[0150] 2. Optimize resource utilization: Regular detection and analysis of unused classes can help the team better allocate development resources. By understanding which classes are no longer used, the team can focus on active and important code parts, improving development efficiency and resource utilization.

[0151] 3. Enhance system security: Removing unused classes can reduce potential security risks. Unused code may contain outdated logic or unmaintained dependencies, which may become the source of security vulnerabilities. By cleaning up these classes in a timely manner, the risk of system attacks can be reduced and overall security can be enhanced.

[0152] In an optional implementation, for each matched subgraph structure, extracting node information and edge information involved therein and marking them as potential defects; and calculating the impact scope and severity of each potential defect based on the node information and the edge information includes:

[0153] For the defect pattern subgraph marked in the graph database, a defect feature vector is extracted, wherein the defect feature vector includes a node identifier, a node type, a node attribute set, a node in-degree value, and a node out-degree value; based on all paths from the start node to the end node in the defect pattern subgraph, path relationship features are extracted, wherein the path relationship features include a relationship type, a relationship attribute set, and a relationship weight value;

[0154] Based on the node identifiers in the defect feature vector, the number of direct dependency relationships between the nodes corresponding to the node identifiers is calculated to obtain a direct influence range, and the dependency strength is calculated based on the weight value of the direct dependency relationship; a dependency path whose length does not exceed a preset depth is matched between the nodes corresponding to the node identifiers, the number of nodes involved in the dependency path is counted to obtain a transfer influence range, and the transfer dependency strength is calculated based on the weight value of each relationship in the dependency path;

[0155] Calculate the ratio of the number of edges to the number of nodes in the defect mode subgraph to obtain a structural complexity index; calculate an average modification cost index based on the number of historical modifications of each node in the defect mode subgraph; encapsulate the calculation results of the direct impact range, the transfer impact range, the structural complexity index, and the average modification cost index into a defect assessment object, wherein the defect assessment object includes a defect identifier and an assessment timestamp;

[0156] Based on a preset time interval period, the most recent modification time information of the nodes in the defect mode subgraph is obtained, and various evaluation indicators are recalculated for the nodes whose most recent modification time information is later than the last evaluation time; the direct impact range, the transfer impact range, the structural complexity index, and the average modification cost index are respectively divided by the maximum values ​​of the corresponding indicators to obtain normalized scores, and the normalized scores are weighted based on the preset indicator weights to obtain a comprehensive evaluation score.

[0157] For the defect pattern subgraph marked in the graph database, the defect feature vector is first extracted. The defect feature vector contains the following information: node identification, node type, node attribute set, node in-degree value and node out-degree value. Specifically, traverse each node in the defect pattern subgraph and extract its unique identifier as the node identification; determine the node type according to the category to which the node belongs (such as code file, configuration file, etc.); collect all attribute information of the node to form an attribute set; count the number of edges pointing to the node to obtain the in-degree value; count the number of edges starting from the node to obtain the out-degree value. For example, for a node representing a Java class file, its feature vector may be: {node identification: "class001", node type: "Java class file", attribute set: {file name: "User.java", number of lines of code: 100}, in-degree value: 2, out-degree value: 3}.

[0158] Next, based on all paths from the start node to the end node in the defect pattern subgraph, the path relationship features are extracted. The path relationship features include the relationship type, the relationship attribute set, and the relationship weight value. In the specific implementation, the depth-first search algorithm is used to traverse all paths from the start node to the end node. For each edge on the path, its relationship type (such as "call", "inheritance", etc.) is extracted; all attribute information of the edge is collected to form an attribute set; the relationship weight value is calculated according to the preset weight calculation method (such as based on the call frequency). For example, the relationship feature of a path may be: {Relationship type: "method call", attribute set: {Number of calls: 10}, weight value: 0.8}.

[0159] Then, based on the node identifier in the defect feature vector, the number of direct dependencies between the nodes corresponding to the node identifier is calculated to obtain the direct impact range. Specifically, the number of edges directly connected to the target node is counted. At the same time, the dependency strength is calculated based on the weight values ​​of these direct dependencies, and the weighted average method of the weight value can be used. For example, if a node has 3 directly connected nodes, and the corresponding weight values ​​are 0.7, 0.5, and 0.3, respectively, then its direct impact range is 3 and the dependency strength is 0.5.

[0160] Next, match the dependency path between the nodes corresponding to the node identifiers, whose length does not exceed the preset depth, count the number of nodes involved in the dependency path, and obtain the transitive influence range. Using the breadth-first search algorithm, starting from the target node, traverse the adjacent nodes layer by layer until the preset depth is reached or the traversal cannot be continued. The transitive dependency strength is calculated based on the weight value of each relationship in the dependency path, and the product of all weight values ​​on the path can be used. For example, if the maximum depth is set to 3, if a path of length 2 is found, involving 3 nodes, and the weights of the two edges on the path are 0.8 and 0.6 respectively, then the transitive influence range is 3 and the transitive dependency strength is 0.48.

[0161] Calculate the ratio of the number of edges to the number of nodes in the defect pattern subgraph to obtain the structural complexity index. For example, if the subgraph contains 10 nodes and 15 edges, the structural complexity index is 1.5. Calculate the average modification cost index based on the number of historical modifications of each node in the defect pattern subgraph. Specifically, count the number of historical modifications of each node in the subgraph in the version control system and calculate the average number of modifications of all nodes. For example, if the subgraph contains 5 nodes, and their historical modification times are 3, 5, 2, 4, and 6 respectively, the average modification cost index is 4.

[0162] The calculation results of the direct impact range, transfer impact range, structural complexity index, and average modification cost index are encapsulated as defect assessment objects. The defect assessment object contains a defect identifier and an assessment timestamp. The defect identifier can use a unique string, such as "defect001". The assessment timestamp records the specific time when the assessment is executed, accurate to milliseconds.

[0163] Based on the preset time interval (such as 2 a.m. every day), obtain the latest modification time information of the nodes in the defect pattern subgraph. For nodes whose latest modification time is later than the last evaluation time, recalculate various evaluation indicators. This ensures the timeliness of the evaluation results and promptly reflects the impact of code changes.

[0164] Finally, the direct impact range, transfer impact range, structural complexity index, and average modification cost index are divided by the historical maximum values ​​of the corresponding index to obtain the normalized score. Based on the preset index weights (such as the direct impact range weight 0.3, the transfer impact range weight 0.3, the structural complexity index weight 0.2, and the average modification cost index weight 0.2), the normalized scores of each item are weighted to obtain the comprehensive evaluation score. For example, assuming that the normalized scores of each indicator of a defect are 0.8, 0.6, 0.7, and 0.5, respectively, its comprehensive evaluation score is 0.8*0.3+0.6*0.3+0.7*0.2+0.5*0.2=0.66.

[0165] The beneficial effects of this technical solution are mainly reflected in the following three aspects:

[0166] 1. Improved the accuracy and comprehensiveness of defect assessment. By comprehensively considering multiple dimensions such as direct impact range, transfer impact range, structural complexity and modification cost, the severity and impact range of defects are comprehensively assessed, avoiding the one-sidedness that may be caused by a single indicator.

[0167] 2. Enhanced the interpretability and operability of defect assessment results. The assessment process is broken down into multiple specific steps, and the output of each step has a clear meaning, which helps developers understand the source of the assessment results and formulate targeted repair strategies accordingly.

[0168] 3. Improved the real-time and dynamic nature of defect assessment. By regularly updating the assessment results, the impact of code changes on defect severity is reflected in a timely manner, so that the assessment results are always kept up to date, providing strong support for continuous quality improvement.

[0169] In an optional implementation, the potential defects are prioritized according to the severity; for each potential defect, a complete call chain generated by the defect is constructed based on the dependency graph data model in a retrospective manner, including:

[0170] Prioritize defects based on the comprehensive evaluation scores of defect evaluation objects, mark defects with a comprehensive evaluation score greater than a first preset threshold as critical level defects, and mark defects with a comprehensive evaluation score greater than a second preset threshold and less than the first preset threshold as high-risk level defects; calculate the time difference between the evaluation time of the defect evaluation object and the current time, calculate the time decay coefficient based on the time difference, and use the product of the comprehensive evaluation score and the time decay coefficient as the dynamic priority score of the defect;

[0171] For the critical level defects and the high-risk level defects, all call chain paths from the caller node to the target node are matched in the graph database, the path depth of the call chain path is counted, the method signature information of each node in the call chain path is extracted, and the call chain path is sorted in descending order based on the path depth; the most recent call chain analysis time of the target node is recorded, and the newly added call relationship later than the most recent call chain analysis time is obtained, and the call chain path from the entry node to the source node is matched based on the source node of the newly added call relationship;

[0172] Create a call context object, which includes the caller ID, callee ID, call times, code line number, method signature information, and recording time; based on the call chain path from the entry node to the target node, calculate the continuous product of the weights of each call relationship in the call chain path to obtain a propagation factor, and create an impact propagation object, which includes the defect ID, entry node signature, target node signature, path length, and impact factor;

[0173] Count the total number of call chain paths, average path length, and maximum impact factor corresponding to each defect, and encapsulate the total number of call chain paths, the average path length, the maximum impact factor, and the analysis timestamp as a link analysis result; encapsulate the defect identifier, dynamic priority score, call context object set, and link analysis result into a defect analysis report.

[0174] In order to achieve effective evaluation and analysis of potential defects, this technical solution provides a defect priority sorting and call chain analysis method based on dependency graph. This method first prioritizes potential defects, then builds a complete call chain for critical and high-risk defects, and finally generates a defect analysis report. The specific implementation process is as follows:

[0175] First, prioritize defects based on the comprehensive evaluation scores of defect evaluation objects. Defects with comprehensive evaluation scores greater than 80 points are marked as critical level defects, and defects with comprehensive evaluation scores greater than 60 points and less than 80 points are marked as high-risk level defects. For example, the comprehensive evaluation score of defect A is 85 points, which is marked as critical level; the comprehensive evaluation score of defect B is 75 points, which is marked as high-risk level.

[0176] Then, calculate the time difference between the evaluation time of the defect evaluation object and the current time, and calculate the time decay coefficient based on the time difference. Specifically, if the time difference is less than 30 days, the time decay coefficient is 1; if the time difference is between 30-60 days, the time decay coefficient is 0.9; if the time difference is between 60-90 days, the time decay coefficient is 0.8; if the time difference is greater than 90 days, the time decay coefficient is 0.7. The product of the comprehensive evaluation score and the time decay coefficient is used as the dynamic priority score of the defect. For example, the evaluation time of defect A is 45 days ago, the time decay coefficient is 0.9, and the dynamic priority score is 85*0.9=76.5 points.

[0177] For critical level defects and high-risk level defects, match all call chain paths from the caller node to the target node in the graph database. Count the path depth of the call chain path, extract the method signature information of each node in the call chain path, and sort the call chain path in descending order based on the path depth. For example, for defect A, 3 call chain paths are matched, with path depths of 5, 4, and 3 respectively. The results after sorting in descending order by depth are: Path 1 (depth 5): method1()->method2()->method3()->method4()->method5(); Path 2 (depth 4): method6()->method7()->method8()->method9(); Path 3 (depth 3): method10()->method11()->method12().

[0178] Record the time of the most recent call chain analysis of the target node, and obtain the newly added call relationships that are later than the most recent call chain analysis time. Match the call chain path from the entry node to the source node based on the source node of the newly added call relationship. For example, the most recent call chain analysis time of defect A is 2023-05-0110:00:00, and 2 newly added call relationships are obtained: method13()->method14 and method15()->method16. Based on method13 and method15 as source nodes, match the call chain path from the entry node to the source node.

[0179] Create a call context object, including attributes such as caller ID, callee ID, number of calls, code line number, method signature information, and recording time. Based on the call chain path from the entry node to the target node, calculate the continuous product of the weights of each call relationship in the call chain path to obtain the propagation factor. Create an impact propagation object, including attributes such as defect ID, entry node signature, target node signature, path length, and impact factor. For example, for path 1, create 5 call context objects, corresponding to the call relationships from method1 to method5. Assuming that the weights of each call relationship are 0.9, 0.8, 0.7, 0.6, and 0.5, respectively, the propagation factor is 0.9*0.8*0.7*0.6*0.5=0.1512. Create an impact propagation object, with defect ID A, entry node signature method1, target node signature method5, path length 5, and impact factor 0.1512.

[0180] The total number of call chain paths, average path length, and maximum impact factor corresponding to each defect are counted, and the total number of call chain paths, average path length, maximum impact factor, and analysis timestamp are encapsulated as link analysis results. For example, the total number of call chain paths for defect A is 3, the average path length is 4, the maximum impact factor is 0.1512, and the analysis timestamp is 2023-06-0114:30:00.

[0181] Finally, the defect identification, dynamic priority score, call context object set, and link analysis results are encapsulated into a defect analysis report. For example, the analysis report of defect A contains: defect identification A, dynamic priority score 76.5, call context object set (including 12 call context objects), link analysis results (total number of call chain paths 3, average path length 4, maximum impact factor 0.1512, analysis timestamp 2023-06-0114:30:00).

[0182] This technical solution has the following beneficial effects:

[0183] 1. Through dynamic priority sorting, the timeliness of defects is taken into account, making priority assessment more accurate and reasonable, which helps to better allocate resources to solve critical and high-risk defects.

[0184] 2. By building a complete call chain, the impact scope and propagation path of the defect are comprehensively analyzed, providing a detailed basis for defect repair and system optimization, and improving the efficiency and quality of defect repair.

[0185] 3. By generating detailed defect analysis reports, comprehensive defect information is provided to the development team, which helps the team better understand and resolve defects, and also provides valuable reference for subsequent code optimization and architecture improvement.

[0186] Figure 2 FIG. 1 is a schematic diagram of the structure of a software system dependency defect tracking system based on a graph database according to an embodiment of the present invention. Figure 2 As shown, the system comprises:

[0187] The first unit is used to parse the source code file of the software system into an abstract syntax tree; extract the class definition, method definition, variable definition and the calling relationship and inheritance relationship between them in the source code file from the abstract syntax tree; construct the class definition, the method definition and the variable definition as nodes in a graph database respectively, and establish directed edges between corresponding nodes based on the calling relationship and the inheritance relationship to obtain a dependency graph data model;

[0188] The second unit is used to build a defect pattern feature library containing circular dependencies, unused components, and repeated dependencies; use the traversal algorithm of the graph database to perform pattern matching in the dependency graph data model, and identify the subgraph structure that matches the features in the defect pattern feature library; for each matching subgraph structure, extract the node information and edge information involved therein, and mark it as a potential defect; calculate the impact range and severity of each potential defect based on the node information and the edge information;

[0189] The third unit is used to generate a defect tracking report based on the impact scope and the severity of the potential defect, specifically including: prioritizing the potential defects according to the severity; for each potential defect, backtracing and constructing a complete call chain caused by the defect based on the dependency graph data model; adding the type, location, impact scope, severity and complete call chain information of the potential defect to the defect tracking report; generating optimization suggestions for each potential defect based on the complete call chain information, and adding the optimization suggestions to the defect tracking report.

[0190] According to a third aspect of the embodiments of the present invention,

[0191] An electronic device is provided, comprising:

[0192] processor;

[0193] a memory for storing processor-executable instructions;

[0194] The processor is configured to call the instructions stored in the memory to execute the aforementioned method.

[0195] According to a fourth aspect of the embodiments of the present invention,

[0196] A computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the aforementioned method is implemented.

[0197] The present invention may be a method, an apparatus, a system and / or a computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for executing various aspects of the present invention.

[0198] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A software system dependency defect tracking method based on a graph database, characterized in that: include: Parse the source code files of the software system into an abstract syntax tree; Extracting class definitions, method definitions, variable definitions, and call relationships and inheritance relationships between them in the source code file from the abstract syntax tree; constructing the class definitions, the method definitions, and the variable definitions as nodes in a graph database, respectively, and establishing directed edges between corresponding nodes based on the call relationships and the inheritance relationships, to obtain a dependency graph data model; Construct a defect pattern feature library containing circular dependencies, unused components, and repeated dependencies; use the traversal algorithm of the graph database to perform pattern matching in the dependency graph data model, and identify the subgraph structure that matches the features in the defect pattern feature library; for each matching subgraph structure, extract the node information and edge information involved therein, and mark it as a potential defect; calculate the impact range and severity of each potential defect based on the node information and the edge information; A defect tracking report is generated based on the impact scope and severity of the potential defect, specifically including: prioritizing the potential defects according to the severity; for each potential defect, backtracing and constructing a complete call chain caused by the defect based on the dependency graph data model; adding the type, location, impact scope, severity and complete call chain information of the potential defect to the defect tracking report; generating optimization suggestions for each potential defect based on the complete call chain information, and adding the optimization suggestions to the defect tracking report.

2. The method according to claim 1, characterized in that The class definition, the method definition, and the variable definition are respectively constructed as nodes in a graph database, and directed edges are established between corresponding nodes based on the call relationship and the inheritance relationship, so as to obtain a dependency graph data model including: Configure the properties of the class definition node, method definition node, and variable definition node in the software system. The class definition node includes a class name property, a package path property, an access modifier property, and an inheritance relationship property. The method definition node includes a method name property, a parameter list property, a return type property, and a class property. The variable definition node includes a variable name property, a data type property, a scope property, and an initial value property. An inheritance relationship directed edge is established between the class definition nodes using a creation statement of a graph database, the edge attribute of the inheritance relationship directed edge records the inherited access level, and the inheritance relationship directed edge points from the child class node to the parent class node; based on the call statement in the method body, a call relationship directed edge is established between the method definition nodes, the edge attribute of the call relationship directed edge includes call location information and call parameter information, and the call relationship directed edge points from the calling method node to the called method node; according to the declaration position and reference position of the variable, a usage relationship directed edge is established between the method definition node and the variable definition node, the edge attribute of the usage relationship directed edge records the usage information and usage location information of the variable, and the usage relationship directed edge points from the method definition node that uses the variable to the used variable definition node; A first composite index is established on the class name attribute and the package path attribute of the class definition node, a second composite index is established on the method name attribute and the belonging class attribute of the method definition node, and a third composite index is established on the variable name attribute and the scope attribute of the variable definition node; the creation operations of the class definition node, the method definition node, the variable definition node, and the inheritance relationship directed edge, the call relationship directed edge, and the usage relationship directed edge are encapsulated and executed in the same transaction to ensure the atomicity of the node creation and edge creation operations; a graph traversal query statement is constructed based on the first composite index, the second composite index, and the third composite index to obtain component dependency information in the software system and obtain a dependency graph data model.

3. The method according to claim 1, characterized in that: Using a traversal algorithm of a graph database to perform pattern matching in the dependency graph data model, identifying a subgraph structure that matches the features in the defect pattern feature library includes: A depth-first traversal algorithm is used to construct a circular dependency detection query statement. The circular dependency detection query statement obtains a circular dependency path with a path length greater than a preset threshold by matching variable-length call paths between class nodes, and extracts the starting class node identifier, path node sequence, and loop depth information in the circular dependency path; an unused component detection query statement is constructed based on a reverse traversal strategy. The unused component detection query statement obtains the class name information and package path information of the class node by matching class nodes that do not have incoming call relationship edges and incoming inheritance relationship edges; a breadth-first traversal algorithm is used to construct a repeated dependency detection query statement. The repeated dependency detection query statement obtains method node pairs whose call times exceed a preset threshold by counting the number of call relationship edges between method nodes; Add an active tag attribute to the class node, the active tag attribute is used to identify the class node with an outgoing call relationship; establish a node access index on the class name field and the package path field of the active tag attribute; construct an incremental matching query statement, the incremental matching query statement is based on the last modification timestamp of the node, and only performs dependency detection on the newly added class nodes and the modified class nodes; When executing the circular dependency detection query statement, the matching paths are filtered based on the access level attributes of the relationship edges, and only the dependency paths with all public access levels are retained; when executing the unused component detection query statement, the matching results are filtered based on the package path attributes of the class nodes, and only the unused components across the package paths are retained; when executing the repeated dependency detection query statement, the repeated call paths are classified based on the call location information of the method nodes; The detected dependency defect information is encapsulated as a defect pattern object, which includes a defect type identifier, involved node paths, node relationship types, call chain depth, and a detection timestamp; historical defect pattern objects that have exceeded the expiration time are deleted in the same database transaction, and the newly generated defect pattern objects are written into the graph database to identify the subgraph structure that matches the features in the defect pattern feature library.

4. The method according to claim 3, characterized in that The method further comprises: Match the class nodes that do not have incoming call relationship edges and incoming inheritance relationship edges in the graph database, extract the class name information, package path information, and last modification time information of the class nodes; create an in-degree index for the class nodes, periodically count the sum of the number of call relationship edges and the number of inheritance relationship edges received by each class node, and update the sum of the numbers as the in-degree attribute value of the class node; For class nodes with an in-degree attribute value of zero, collect the interface node name information implemented by the class node, extract the method name, visibility level, and parameter information of the method node contained in the class node; obtain the submission record for modifying the class node, and encapsulate the submission hash value, timestamp, author information, and submission information of the submission record as usage history data; Record the most recent detection time of the class node, count the number of newly added call relationship edges that are later than the most recent detection time, update the number of newly added call relationship edges as the in-degree attribute value of the class node, and update the most recent detection time; collect the dependent class node set of the class node, determine the isolation level of the class node based on the number of the dependent class node set, and create an unused context object, which includes the component identifier, module name, number of dependencies, isolation level, and detection time; Count the number of class nodes with zero in-degree attribute value contained in each module node, and calculate the ratio of the number of class nodes to the total number of class nodes contained in the module node; encapsulate the name information, path information, type information, module name of the unused context object, isolation level, detection time, code size, complexity, and last modification time of the class node into a detection report.

5. The method according to claim 1, characterized in that For each matched subgraph structure, extract the node information and edge information involved therein and mark them as potential defects; calculate the impact scope and severity of each potential defect based on the node information and the edge information, including: For the defect pattern subgraph marked in the graph database, a defect feature vector is extracted, and the defect feature vector includes a node identifier, a node type, a node attribute set, a node in-degree value, and a node out-degree value; based on all paths from the start node to the end node in the defect pattern subgraph, path relationship features are extracted, and the path relationship features include a relationship type, a relationship attribute set, and a relationship weight value; Based on the node identifier in the defect feature vector, the number of direct dependency relationships between nodes corresponding to the node identifier is calculated to obtain a direct impact range, and the dependency strength is calculated based on the weight value of the direct dependency relationship; Matching dependency paths whose length does not exceed a preset depth between nodes corresponding to the node identifiers, counting the number of nodes involved in the dependency paths to obtain a transfer influence range, and calculating the transfer dependency strength based on the weight value of each relationship in the dependency paths; Calculate the ratio of the number of edges to the number of nodes in the defect mode subgraph to obtain a structural complexity index; calculate an average modification cost index based on the number of historical modifications of each node in the defect mode subgraph; encapsulate the calculation results of the direct impact range, the transfer impact range, the structural complexity index, and the average modification cost index into a defect assessment object, wherein the defect assessment object includes a defect identifier and an assessment timestamp; Based on a preset time interval period, the most recent modification time information of the nodes in the defect mode subgraph is obtained, and various evaluation indicators are recalculated for the nodes whose most recent modification time information is later than the last evaluation time; the direct impact range, the transfer impact range, the structural complexity index, and the average modification cost index are respectively divided by the maximum values ​​of the corresponding indicators to obtain normalized scores, and the normalized scores are weighted based on the preset indicator weights to obtain a comprehensive evaluation score.

6. The method according to claim 5, characterized in that Prioritize the potential defects according to their severity; For each potential defect, the complete call chain generated by the defect is constructed based on the dependency graph data model, including: Prioritize defects based on the comprehensive evaluation scores of defect evaluation objects, mark defects with a comprehensive evaluation score greater than a first preset threshold as critical level defects, and mark defects with a comprehensive evaluation score greater than a second preset threshold and less than the first preset threshold as high-risk level defects; calculate the time difference between the evaluation time of the defect evaluation object and the current time, calculate the time decay coefficient based on the time difference, and use the product of the comprehensive evaluation score and the time decay coefficient as the dynamic priority score of the defect; For the critical level defects and the high-risk level defects, all call chain paths from the caller node to the target node are matched in the graph database, the path depth of the call chain path is counted, the method signature information of each node in the call chain path is extracted, and the call chain path is sorted in descending order based on the path depth; the most recent call chain analysis time of the target node is recorded, and the newly added call relationship later than the most recent call chain analysis time is obtained, and the call chain path from the entry node to the source node is matched based on the source node of the newly added call relationship; Create a call context object, which includes the caller ID, callee ID, call times, code line number, method signature information, and recording time; based on the call chain path from the entry node to the target node, calculate the continuous product of the weights of each call relationship in the call chain path to obtain a propagation factor, and create an impact propagation object, which includes the defect ID, entry node signature, target node signature, path length, and impact factor; Count the total number of call chain paths, average path length, and maximum impact factor corresponding to each defect, and encapsulate the total number of call chain paths, the average path length, the maximum impact factor, and the analysis timestamp as a link analysis result; encapsulate the defect identifier, dynamic priority score, call context object set, and link analysis result into a defect analysis report.

7. A software system dependency defect tracking system based on a graph database, used to implement the method described in any one of claims 1 to 6, characterized in that: include: The first unit is used to parse the source code files of the software system into an abstract syntax tree; Extracting class definitions, method definitions, variable definitions, and call relationships and inheritance relationships between them in the source code file from the abstract syntax tree; constructing the class definitions, the method definitions, and the variable definitions as nodes in a graph database, respectively, and establishing directed edges between corresponding nodes based on the call relationships and the inheritance relationships, to obtain a dependency graph data model; The second unit is used to build a defect pattern feature library containing circular dependencies, unused components, and repeated dependencies; use the traversal algorithm of the graph database to perform pattern matching in the dependency graph data model, and identify the subgraph structure that matches the features in the defect pattern feature library; for each matching subgraph structure, extract the node information and edge information involved therein, and mark it as a potential defect; calculate the impact range and severity of each potential defect based on the node information and the edge information; The third unit is used to generate a defect tracking report based on the impact scope and the severity of the potential defect, specifically including: prioritizing the potential defects according to the severity; for each potential defect, backtracing and constructing a complete call chain caused by the defect based on the dependency graph data model; adding the type, location, impact scope, severity and complete call chain information of the potential defect to the defect tracking report; generating optimization suggestions for each potential defect based on the complete call chain information, and adding the optimization suggestions to the defect tracking report.

8. An electronic device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor is configured to call the instructions stored in the memory to execute the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the computer program instructions are executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images