A service-oriented software process monitoring method based on heterogeneous graph generation rule

Abstract

The application discloses a service software process monitoring method based on a conversion rule of a heterogeneous graph, establishes a dependency relationship existing between classes and methods in a service bytecode file; uses an ASM bytecode operation library to construct a dependency relationship analysis tool, extracts a complete class name of each program class, a method name in each program class, and the dependency relationship existing between the classes and the methods; constructs a directory tree and a dependency relationship heterogeneous graph; selects a target object through the directory tree, extracts a dependency relationship related to the target object from the dependency relationship heterogeneous graph, and forms a dependency relationship subgraph; uses an Agent program to analyze the dependency relationship subgraph, forms a rule text of a plug-in object, and then passes an address of the rule text to a plug-in program; loads the plug-in program to a measured service JVM; analyzes the rule text into classes and methods with a mapping relationship, reloads the classes matched successfully, and makes directional modification on method bytecodes matched successfully; calls a measured service access interface, obtains program running logs after the interface calling, and verifies a plug-in effect; and the application improves dependency relationship analysis efficiency on the measured service.

Description

Technical Field

[0001] This invention relates to software testing and evaluation technology, specifically to a service-oriented software process monitoring method based on heterogeneous graph generation rules. Background Technology

[0002] With the development of information technology, service software is becoming increasingly large-scale and its application environment is becoming more complex. To standardize the quality of the entire lifecycle of service software development, a series of standards and specifications have been released to constrain the development process, such as GB / T 8566-2007 "Information Technology Software Lifecycle Process". How to use information technology to verify software standard compliance is of great significance for promoting the implementation of relevant standards and ensuring software development quality. For runtime software behavior, process monitoring and analysis technology is typically used to supervise the software's operation process and conduct dynamic behavioral compliance testing without affecting the execution state of the software under test.

[0003] Agent technology is an important concept in software engineering. JavaAgent, also known as Java probe technology, supports adding specified bytecode to compiled Java classes. Dynamic agent programs targeting JavaAgents (hereinafter referred to as "Agent programs") provide bytecode instrumentation entry points to the outside world by establishing access interfaces, and run the instrumentation program directly on the JVM of the Java service under test, thereby modifying the bytecode of the service. The instrumentation program completes non-intrusive modification and reloading of the Java service under test through the access interface provided by the Agent program. Dynamic agent technology targeting JavaAgents has many applications, such as Aspect-Oriented Programming (AOP) in the Java Spring framework. AOP allows adding unified additional functionality to services dynamically without modifying the source code, which is very helpful for software inspection and defect localization in complex systems, significantly improving the efficiency of problem location and repair.

[0004] However, existing dynamic program proxy technologies for JavaAgents suffer from performance issues in instrumentation applications. The main problems with existing methods are as follows: First, the Agent program does not restrict the scope of operations on the bytecode classes of the service under test. Therefore, if the instrumentation program is directly loaded through the Agent program, it will instrument all loaded classes of the service under test, consuming the execution time of unrelated programs and increasing the performance overhead of the system under test. Second, configuring the filtering rules for bytecode classes in the Agent program through external parameters, manually configuring the scope of operations for bytecode classes, transforming bytecode classes, and executing the transformed bytecode classes requires clearly understanding the call relationships between classes or methods in the service under test. For external testing personnel, obtaining the source code and identifying the call relationships between classes or methods in the source code is extremely cumbersome. Summary of the Invention

[0005] The purpose of this invention is to propose a service-oriented software process monitoring method based on heterogeneous graph generation rules.

[0006] The technical solution to achieve the purpose of this invention is: a service-oriented software process monitoring method based on heterogeneous graph generation and transformation rules, comprising the following steps:

[0007] S1, establish the dependency relationships between classes and methods in the service bytecode file, including class dependency on class, method dependency on class, and method dependency on method;

[0008] S2, Based on the established dependencies, use the ASM bytecode manipulation library to build a dependency resolution tool to extract the fully qualified class name of each program class, the method name in each program class, and the dependencies between classes and methods;

[0009] S3, construct a directory tree based on the hierarchical relationship between classes and methods;

[0010] S4. Based on the two types of nodes, program classes and program methods, and the dependency relationships between classes and methods, construct a dependency heterogeneous graph.

[0011] S5. Select the target object through the directory tree and extract the dependencies related to the target object from the dependency heterogeneous graph to form a dependency subgraph;

[0012] S6 uses the Agent program to parse the dependency subgraph, form the instrumentation object rule text, then passes the rule text address to the instrumentation program, and loads the instrumentation program onto the JVM of the service under test;

[0013] S7. After receiving the address parameter, the instrumentation program parses the rule text into classes and methods with mapping relationships, reloads the classes that match successfully, and makes targeted modifications to the bytecode of the methods that match successfully.

[0014] S8, after instrumentation is completed, calls the interface of the service under test, obtains the program running log after the interface call, and verifies the instrumentation effect.

[0015] Furthermore, S2, based on the established dependencies, uses the ASM bytecode manipulation library to build a dependency resolution tool, specifically as follows:

[0016] Step 2.1: Use the binary combination of (package name, class name) as the unique identifier for a program class, and use the quadruple combination of (package name, class name, method name, method descriptor) as the unique identifier for a program method, where the method descriptor is a string composed of the method name, parameter type list, and return type;

[0017] Step 2.2: Deeply analyze program classes based on the ASM bytecode manipulation library. Using the ASM bytecode manipulation library, traverse the dependencies between classes, including inheritance, implementation, association, and aggregation. At the same time, traverse the dependencies at the program method level within each class, including reference, call, and declaration relationships. And use the program's unique identifier to establish a ternary relationship group (program identifier A, program identifier B, dependency relationship).

[0018] Furthermore, S3 constructs a directory tree based on the hierarchical relationship between classes and methods, where:

[0019] The hierarchical relationship between classes and methods includes the hierarchical structure of the package to which the class belongs and the hierarchical structure of the methods contained in the class.

[0020] The nodes in the directory tree consist of three levels: package, class, and method. The relationship between these three levels is parent-child, with classes being child nodes of their respective packages, and methods within a class being child nodes of that class.

[0021] Furthermore, in S4, based on the two types of nodes—program classes and program methods—and the dependencies between classes and methods, a dependency heterogeneous graph is constructed. The specific method is as follows:

[0022] Using the first element of a triplet as the starting point, the second element as the ending point, and the third element as the connection relationship, a dependency heterogeneous graph is constructed, consisting of two types of nodes: program classes and program methods, and various connection relationships between them. Different dependencies between nodes are represented by different types of edges.

[0023] Furthermore, in S5, the target object is selected through the directory tree, and the dependencies related to the target object are extracted from the dependency heterogeneous graph to form a dependency subgraph. The specific method is as follows:

[0024] Select a program class node or program method node from the directory tree formed by S3, identify the unique identifier of the node, locate the node corresponding to the identifier in the heterogeneous graph network formed by S4, and perform graph traversal based on the selected expected dependency relationship using the breadth-first search algorithm to obtain the nodes connected to the starting point and form a dependency subgraph.

[0025] Furthermore, in S7, after receiving the address parameter, the instrumentation program parses the rule text into classes and methods with mapping relationships, reloads the classes that match, and makes targeted modifications to the bytecode of the methods that match.

[0026] The parsing rule text consists of classes and methods with mapping relationships, where the mapping relationship refers to key-value pairs from class identifiers to a list of method identifiers, and the mapping relationship includes the target program that needs to be reloaded this time;

[0027] The process of reloading the matched classes and making targeted modifications to the bytecode of the matched methods involves using the ASM bytecode manipulation library to instrument the program of the method list corresponding to the value after obtaining the bytecode file of the class corresponding to the key in the mapping relationship, completing the custom modification, and then reloading the modified bytecode on the JVM.

[0028] Furthermore, after instrumentation is complete in S8, the service under test is invoked to access the interface, and the program execution log after the interface call is obtained to verify the instrumentation effect.

[0029] If the accessed interface is the target program interface, then verify that the running log should be the modified program execution log. If the accessed interface is not the target program interface, then verify whether the running log is still the previous program execution log.

[0030] A service-oriented software process monitoring system based on heterogeneous graph generation and transformation rules is provided. The system implements the aforementioned service-oriented software process monitoring method based on heterogeneous graph generation and transformation rules, and realizes service-oriented software process monitoring based on heterogeneous graph generation and transformation rules. It consists of eight modules, which are executed from s1 to s8.

[0031] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the service-oriented software process monitoring method based on heterogeneous graph generation and transformation rules, thereby realizing service-oriented software process monitoring based on heterogeneous graph generation and transformation rules.

[0032] A computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the service-oriented software process monitoring method based on heterogeneous graph generation and transformation rules, thereby realizing service-oriented software process monitoring based on heterogeneous graph generation and transformation rules.

[0033] Compared with existing technologies, the significant advantages of this invention are: 1) By performing static dependency analysis on the bytecode file of the service under test, the dependencies between classes or methods are identified, and a heterogeneous dependency graph is constructed. Combining the breadth-first traversal concept in graph theory, the complete dependencies between classes or methods can be extracted, solving the problems of inconvenient access to the source code of the service under test and difficulty in identifying dependencies from the source code, thus improving the efficiency of dependency analysis for the service under test. 2) During the service runtime loading process, the heterogeneous dependency graph obtained from static dependency analysis can narrow down the instrumentation scope of the service under test, accurately reloading the target program and its calling programs. Compared with full instrumentation, this effectively reduces the performance loss caused to the runtime service. Attached Figure Description

[0034] Figure 1 This is a technical roadmap of the present invention;

[0035] Figure 2 This is a parsing diagram of the program structure and dependency relationships of this invention;

[0036] Figure 3 It is a flowchart for extracting instrumented objects based on a dependency graph;

[0037] Figure 4 This is a flowchart of the piling process;

[0038] Figure 5 This is a flowchart of the instrumentation program's targeted reloading process. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0040] This invention proposes a service-oriented software process monitoring and analysis method based on heterogeneous graph-generated transformation rules. It utilizes JavaAgent-oriented dynamic proxy technology to perform runtime proxy control on the service under test, thereby controlling and modifying the bytecode of the loaded classes. This achieves instrumentation of the runtime software and outputs execution call chain information, thus monitoring the execution process of the service under test. During this process, static dependency analysis technology oriented towards bytecode captures dependencies at the method level and establishes a heterogeneous graph of dependencies at both class and method levels. Transformation rules for bytecode classes are generated based on this heterogeneous graph, achieving the optimization goal of generating filtering class rules before process monitoring and analysis. Using text as a carrier, connecting static dependency analysis and dynamic instrumentation proxy, it ultimately achieves precise instrumentation of the tested program and its calling programs. This enables monitoring and recording of the execution process of the service under test, while also compensating for the manpower and performance overhead of full-source code scanning analysis.

[0041] Figure 1 This is the technical roadmap for this invention. A service-oriented software process monitoring method based on heterogeneous graph generation and transformation rules comprises eight stages: S1, establishing the dependencies between classes and methods in the service bytecode file, including dependencies between classes, methods, and classes; S2, building a parsing tool using the ASM bytecode manipulation library based on the established dependencies; S3, parsing the directory structure of the service under test and establishing a directory tree; S4, parsing all dependencies of the service under test and establishing a global dependency heterogeneous graph; S5, selecting the target object through the directory tree and extracting the target from the dependency heterogeneous graph. The process involves: S6, forming a dependency subgraph of object-related dependencies; S7, the Agent program parses the dependency subgraph, forms the instrumentation object rule text, passes the rule text address to the instrumentation program, and loads the instrumentation program onto the JVM of the service under test; S8, after receiving the address parameter, the instrumentation program parses the rule text into matching objects such as classes and methods with mapping relationships, reloads the classes that pass the matching, and makes targeted modifications to the bytecode of the methods that pass the matching; S9, after completing the instrumentation, the service under test accesses the interface, obtains the program execution log after the interface call, and verifies the instrumentation effect. If the accessed interface is the target program interface, the verification execution log should be the modified program execution log. If the accessed interface is not the target program interface, the verification is whether the execution log is still the previous program execution log.

[0042] Figure 2This involves program structure parsing and dependency graph analysis. A parsing tool is built based on the ASM bytecode manipulation library to parse the structure and content of bytecode file packages. First, the fully qualified class name of each program class is extracted as a combination of package name and class name, and then the method names within each program class are extracted. Based on this, the hierarchical structure relationships between classes and methods are extracted, and a directory tree is constructed according to a tree structure. The hierarchical structure relationships between classes and methods include the hierarchy of the packages to which the classes belong and the hierarchy of the methods contained within the classes; the nodes of the directory tree include three levels: package, class, and method. The relationship between these three levels is a parent-child relationship, with classes as child nodes of their respective packages, and methods within a class as child nodes of the class. Dependencies between classes and methods are extracted, and a heterogeneous dependency graph is constructed according to a graph structure. These dependencies include class-to-class, method-to-class, and method-to-method dependencies, and the dependency relationships will differ between different services under test. Class dependencies include inheritance, implementation, association, and aggregation relationships between classes; method dependencies include parameter types, return types, and variable types defined or declared using classes within methods; and method dependencies include method calls to methods. Nodes in a heterogeneous dependency graph include classes and methods. The combination of package name and class name serves as the unique identifier for class nodes, while the combination of package name, class name, and method descriptor serves as the unique identifier for method nodes. The method descriptor is a string consisting of the method name, a list of parameter types, and a return type. Different dependencies between nodes are represented by edges of different types, forming a heterogeneous graph network.

[0043] Figure 3 This is a flowchart for extracting instrumentation objects based on a dependency graph. From the directory tree formed in S3, a specific type of node or method node is selected, and its unique identifier is identified. The node corresponding to this identifier is located in the heterogeneous graph network formed in S4, and a dependency subgraph containing this node is extracted using a breadth-first search algorithm. The Euclidean space information of the dependency subgraph is converted into text information, forming the instrumentation object rule text.

[0044] Figure 4 This is a flowchart of the instrumentation process. The Agent program identifies the instrumentation object (target program such as a class or method) and passes the address of the instrumentation object to the instrumentation program to perform the instrumentation process. The instrumentation program identifies the instrumentation object and modifies it. Then, the Agent program reloads the class containing the instrumentation object to perform the instrumentation operation.

[0045] Figure 5This is a flowchart of the instrumentation program's rule-matching reloading process. The instrumentation program reads the rule text and parses it into a collection with mapping relationships. These mapping relationships are key-value pairs that map class identifiers to a list of method identifiers, and contain the target program that needs to be reloaded. Rule-matching reloading involves obtaining the bytecode files of the classes corresponding to the keys in the mapping relationships, using the ASM bytecode manipulation library to instrument the programs in the list of methods corresponding to the values, completing the custom modifications, and then reloading the modified bytecode on the JVM.

[0046] Example

[0047] To verify the effectiveness of the present invention, the following simulation experiment was conducted.

[0048] The specific execution steps of a service-oriented software process monitoring technology based on heterogeneous graph generation rules are as follows.

[0049] Step 1: Determine the dependencies of the service under test. This process establishes the dependencies between the service classes or methods under test, and integrates all program dependencies that may occur in the project, in order to build a more comprehensive dependency heterogeneous graph model.

[0050] Step 2: Build a dependency resolution tool. Based on the established relationships, build a tool to resolve the dependencies between these programs.

[0051] Step 2.1: Use the binary combination of (package name, class name) as the unique identifier for a program class, and use the quadruple combination of (package name, class name, method name, method description) as the unique identifier for a program method.

[0052] Step 2.2: Deep parsing of program classes based on the ASM bytecode manipulation library. For program classes, the ASM bytecode manipulation library is used to traverse the dependencies between classes, such as implementation, inheritance, association, and aggregation. At the same time, the dependencies at the program method level, such as references, calls, and declarations, are traversed within the class. A ternary relationship group (program identifier A, program identifier B, dependency relationship) is established using the program's unique identifier.

[0053] Step 3: Analyze the program structure and build a program directory tree. Based on the unique identifiers of program classes and methods extracted by the dependency resolution tool in Step 2, establish the hierarchical relationship of the program and build a directory tree according to the tree structure.

[0054] Step 4: Construct a heterogeneous dependency graph. Restructuring is performed based on the triplet groups extracted by the dependency resolution tool in Step 2. The triplet consists of program identifier A, program identifier B, and program dependency. Using the first element of the triplet as the starting point, the second element as the ending point, and the third element as the connection, a heterogeneous dependency graph is constructed, consisting of program classes, program methods, and various connections between them.

[0055] Step 5: Select the target program in the directory tree and extract the dependency subgraph from the dependency heterogeneous graph. Select a program and the expected dependency relationship in the directory tree, obtain the unique identifier of the program, and take the program node corresponding to the unique identifier as the starting point in the dependency heterogeneous graph. Use the breadth-first search algorithm to traverse the graph according to the selected expected dependency relationship, and obtain the nodes connected to the starting point and having the dependency relationship, forming the dependency subgraph.

[0056] Step 6: The proxy control program resolves the dependency subgraph.

[0057] Step 6.1: The proxy control program parses the dependency subgraph to obtain the program class nodes or program method nodes in the graph.

[0058] Step 6.2: Parse the unique identifier of the obtained node and adapt it to the format recognized by JVM class loading.

[0059] Step 6.3: Write the program identifiers of all adapted nodes into the rule text and record the rule text address.

[0060] Step 7: The instrumentation program reads the overloaded class and the instrumentation object. The proxy control program receives the instruction, passes the rule text address to the instrumentation program, and attaches the instrumentation program to the service-oriented software system under test. The instrumentation program iterates through each line of rule text, treating it as an object of program class overloading, and modifies the bytecode of each overloaded program object according to the bytecode modification program implemented based on ASM. After the modification is complete, the modified bytecode class file is reloaded in the JVM.

[0061] Step 8: Call the interface that is consistent with or has a dependency relationship with the target program selected in the service under test directory tree, obtain the program running log after the interface call, and verify whether the running log is the modified program execution log.

[0062] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0063] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these modifications and improvements all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A service-oriented software process monitoring method based on heterogeneous graph generation and transformation rules, characterized in that, Includes the following steps: S1, establish the dependency relationships between classes and methods in the service bytecode file, including class dependency on class, method dependency on class, and method dependency on method; S2, Based on the established dependencies, use the ASM bytecode manipulation library to build a dependency resolution tool to extract the fully qualified class name of each program class, the method name in each program class, and the dependencies between classes and methods; S3, construct a directory tree based on the hierarchical relationship between classes and methods; S4. Based on the two types of nodes, program classes and program methods, and the dependency relationships between classes and methods, construct a dependency heterogeneous graph. S5. Select the target object through the directory tree and extract the dependencies related to the target object from the dependency heterogeneous graph to form a dependency subgraph; S6 uses the Agent program to parse the dependency subgraph, form the instrumentation object rule text, then passes the rule text address to the instrumentation program, and loads the instrumentation program onto the JVM of the service under test; S7. After receiving the address parameter, the instrumentation program parses the rule text into classes and methods with mapping relationships, reloads the classes that match successfully, and makes targeted modifications to the bytecode of the methods that match successfully. S8. After instrumentation is completed, call the interface of the service under test, obtain the program running log after the interface call, and verify the instrumentation effect. In S4, a dependency heterogeneous graph is constructed based on two types of nodes: program classes and program methods, as well as the dependencies between classes and methods. The specific method is as follows: Establish a ternary relation group (unique identifier of program class, unique identifier of program method, dependency relationship). Take the first element of the ternary relation group as the starting point, the second element as the ending point, and the third element as the connection relationship. Construct a dependency heterogeneous graph consisting of program class and program method nodes and various connection relationships between them. Different dependencies between nodes are represented by different types of edges.

2. The service-oriented software process monitoring method based on heterogeneous graph generation and transformation rules according to claim 1, characterized in that, S2, based on the established dependencies, uses the ASM bytecode manipulation library to build a dependency resolution tool. The specific method is as follows: Step 2.1: Use the binary combination of (package name, class name) as the unique identifier for a program class, and use the quadruple combination of (package name, class name, method name, method descriptor) as the unique identifier for a program method, where the method descriptor is a string composed of the method name, parameter type list, and return type; Step 2.2: Implement deep parsing of program classes based on the ASM bytecode manipulation library. Using the ASM bytecode manipulation library, traverse the dependencies between classes. The dependencies between classes include inheritance, implementation, association, and aggregation. At the same time, traverse the dependencies at the program method level within the class. The dependencies at the program method level include reference, call, and declaration relationships. And use the program's unique identifier to establish a ternary relationship group (unique identifier of program class, unique identifier of program method, dependency relationship).

3. The service-oriented software process monitoring method based on heterogeneous graph generation and transformation rules according to claim 1, characterized in that, S3, construct a directory tree based on the hierarchical relationship between classes and methods, where: The hierarchical relationship between classes and methods includes the hierarchical structure of the package to which the class belongs and the hierarchical structure of the methods contained in the class. The nodes in the directory tree consist of three levels: package, class, and method. The relationship between these three levels is parent-child, with classes being child nodes of their respective packages, and methods within a class being child nodes of that class.

4. The service-oriented software process monitoring method based on heterogeneous graph generation and transformation rules according to claim 1, characterized in that, S5: Select the target object through the directory tree, and extract the dependencies related to the target object from the dependency heterogeneous graph to form a dependency subgraph. The specific method is as follows: Select a program class node or program method node from the directory tree formed by S3, identify the unique identifier of the node, locate the node corresponding to the unique identifier in the heterogeneous graph network formed by S4 as the starting point, and perform graph traversal according to the selected expected dependency relationship using the breadth-first search algorithm to obtain the nodes connected to the starting point, forming a dependency subgraph.

5. The service-oriented software process monitoring method based on heterogeneous graph generation and transformation rules according to claim 1, characterized in that, S7, after receiving the address parameter, the instrumentation program parses the rule text into classes and methods with mapping relationships, reloads the classes that match, and makes targeted modifications to the bytecode of the methods that match. The parsing rule text consists of classes and methods with mapping relationships, where the mapping relationship refers to key-value pairs from class identifiers to a list of method identifiers, and the mapping relationship includes the target program that needs to be reloaded this time; The process of reloading the matched classes and making targeted modifications to the bytecode of the matched methods involves using the ASM bytecode manipulation library to instrument the program of the method list corresponding to the value after obtaining the bytecode file of the class corresponding to the key in the mapping relationship, completing the custom modification, and then reloading the modified bytecode on the JVM.

6. The service-oriented software process monitoring method based on heterogeneous graph generation and transformation rules according to claim 1, characterized in that, S8, after instrumentation is complete, call the interface of the service under test, obtain the program execution log after the interface call, and verify the instrumentation effect, including: If the accessed interface is the target program interface, then verify that the running log should be the modified program execution log. If the accessed interface is not the target program interface, then verify whether the running log is still the previous program execution log.

7. A service-oriented software process monitoring system based on heterogeneous graph generation and transformation rules, characterized in that, The service-oriented software process monitoring method based on heterogeneous graph generation and transformation rules as described in any one of claims 1-6 is implemented to realize service-oriented software process monitoring based on heterogeneous graph generation and transformation rules, which is divided into eight modules and executed s1~s8.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it implements the service-oriented software process monitoring method based on heterogeneous graph generation and transformation rules as described in any one of claims 1-6, thereby realizing service-oriented software process monitoring based on heterogeneous graph generation and transformation rules.

9. A computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the service-oriented software process monitoring method based on heterogeneous graph generation and transformation rules as described in any one of claims 1-6, thereby realizing service-oriented software process monitoring based on heterogeneous graph generation and transformation rules.

Images