Software information acquisition method for large language model, electronic device and storage medium

Abstract

The embodiment of the application relates to the technical field of software engineering, and particularly relates to a software information acquisition method for a large language model, an electronic device and a storage medium. The embodiment of the application quickly acquires a code skeleton of source code through an analysis tool, supplements details such as variable, method and calling relationship in the source code by using a type resolver, constructs a structured code index containing bidirectional calling relationship and interface implementation mapping, and in this way, without relying on a building and compiling environment of a project, the code condition of the software project is deeply understood, the code index is encapsulated as a quick and accurate query tool for calling of the large language model, so that the large language model can call the query tool as needed, quickly and accurately acquires software information in the source code, avoids dependence and computing overhead caused by vector retrieval, and is low in cost and high in interpretability.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and in particular to a software information acquisition method, electronic device, and storage medium for large language models. Background Technology

[0002] In recent years, large language models have been widely used in code understanding and development assistance scenarios. Therefore, how to provide software information to large language models has become a key factor affecting the quality of results. The aforementioned software information typically includes source code, configuration files, database table structures, SQL mapping files, version control records, and other information. Especially in application systems based on Spring Boot, MyBatis, relational databases, and Git version control, business logic is often distributed among the control layer, service layer, data access layer, configuration layer, and database layer, and there are complex calling relationships and other heterogeneous information between layers and methods.

[0003] In related technologies, traditional AST parsing requires a complete compilation environment and JAR packages for type binding, making it difficult to apply to unknown projects and unable to effectively obtain the complete call chain. At the same time, it lacks the ability to uniformly process and integrate multi-source heterogeneous information, causing large models to often rely on a single information source, which limits the depth of understanding of complex projects. Summary of the Invention

[0004] One objective of this application is to provide a software information acquisition method, electronic device, and storage medium for large language models, aiming to improve the situation in related technologies where the depth of understanding of software projects is limited by reliance on compilation environments and JAR packages and the inability to obtain complete call chains.

[0005] In a first aspect, embodiments of this application provide a method for obtaining software information for a large language model, comprising: parsing the source code of a target project using a preset parsing tool to obtain basic node code, wherein the parsing tool disables type binding functionality; parsing the basic node code using a type resolver to obtain first information, the first information including the fully qualified class name of the target variable, the method signature of the target method, the method body source code, the program interface path and call identifier, and the call implementation relationship between the target interface and the target implementation class; obtaining second information based on the call identifier of the target method in the first information, the second information including the bidirectional call relationship of the target method and the call point context code; integrating the first information and the second information according to a preset format to obtain a structured code index; encapsulating the code index into a tool and registering it to obtain a tool set, wherein the tool set includes multiple query tools; and providing the query tools to the large language model in the form of function interfaces so that the large language model can call the query tools to obtain software information from the source code of the target project.

[0006] Secondly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the processor is communicatively connected to the memory, and the memory stores computer program instructions executable by the processor. When the computer program instructions are executed by the processor, the electronic device performs the software information acquisition method for large language models provided in the first aspect.

[0007] Thirdly, embodiments of this application provide a computer-readable storage medium storing processor-executable computer program instructions, which, when executed by the processor, cause the processor to perform the software information acquisition method for large language models provided in the first aspect.

[0008] The embodiments of this application have the following beneficial effects: Unlike related technologies, the embodiments of this application, based on the basic node code obtained by the parsing tool from the source code of the target project, obtain first information, obtain second information based on the first information, integrate the first information and the second information according to a preset format to obtain a structured code index, and encapsulate the structured code index into multiple query tools, which are provided to the large language model. Thus, the large language model can call the query tools to obtain software information from the source code. In this way, the code skeleton is quickly obtained through the parsing tool, and the details such as variables, methods and call relationships are supplemented by the type resolver. A structured code index containing bidirectional call relationships and interface implementation mappings is constructed. It does not depend on the project's construction and compilation environment, and deeply understands the code situation of the software project. Moreover, the code index is encapsulated into a fast and accurate query tool for the large language model to call, so that the large language model can call the query tool as needed to quickly and accurately obtain software information in the source code, avoiding the dependence and computational overhead brought by vector retrieval, which is low-cost and highly interpretable. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the related technologies or embodiments will be briefly introduced below. Obviously, the drawings described below only show some embodiments of this application and should not be considered as limiting the scope of protection. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1A This is a schematic diagram illustrating an application scenario for obtaining software information provided in some embodiments of this application; Figure 1B These are illustrations of application scenarios for obtaining software information provided in some embodiments of this application. Figure 2 ; Figure 2These are schematic diagrams of the structure of electronic devices provided in some embodiments of this application; Figure 3 This is a flowchart illustrating a software information acquisition method for large language models provided in some embodiments of this application. Detailed Implementation

[0011] To make the objectives and advantages of the embodiments of this application more readily understood, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. The detailed description of the embodiments of this application in the accompanying drawings is not intended to limit the scope of protection claimed by this application, but only represents selected embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0012] It should be noted that, unless there is a conflict, the various technical features involved in the embodiments of this application described below can be combined with each other, and all are within the protection scope of this application. Furthermore, although functional modules are divided in the device or structural schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. In addition, the terms "first," "second," "third," and other similar expressions used herein do not limit the data or execution order, but are only for illustrative purposes and to distinguish identical or similar items with substantially the same function and effect, and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features.

[0013] Unless otherwise defined, the technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. It should be understood that the term "and / or" as used in this specification includes any and all combinations of one or more of the listed items.

[0014] In recent years, large language models have been widely used in code understanding and development assistance scenarios. Therefore, how to provide software information to large language models has become a key factor affecting the quality of results. The aforementioned software information typically includes source code, configuration files, database table structures, SQL mapping files, version control records, and other information. Especially in application systems based on Spring Boot, MyBatis, relational databases, and Git version control, business logic is often distributed among the control layer, service layer, data access layer, configuration layer, and database layer, and there are complex calling relationships and other heterogeneous information between layers and methods.

[0015] In related technologies, traditional AST parsing requires a complete compilation environment and JAR packages for type binding, making it difficult to apply to unknown projects and unable to effectively obtain the complete call chain. At the same time, it lacks the ability to uniformly process and integrate multi-source heterogeneous information, causing large models to often rely on a single information source, which limits the depth of understanding of complex projects.

[0016] In view of this, embodiments of this application provide a software information acquisition method for large language models. This method rapidly obtains the code skeleton through parsing tools, supplements details such as variables, methods, and call relationships using a type resolver, and constructs a structured code index containing bidirectional call relationships and interface implementation mappings. This eliminates reliance on the project's build and compilation environment, enabling a deep understanding of the software project's code. The code index is encapsulated as a fast and accurate query tool for large language models, allowing them to call the query tool on demand to quickly and accurately obtain software information from the source code. This avoids the dependencies and computational overhead associated with vector retrieval, resulting in low cost and high interpretability.

[0017] Please see Figure 1A , Figure 1A The illustrations show application scenarios for obtaining software information in some embodiments of this application.

[0018] like Figure 1A As shown, this application scenario includes electronic device 100, which can be any suitable device or apparatus such as a laptop, desktop computer, tablet computer, all-in-one computer, microcontroller, FPGA chip, etc. Figure 1A The electronic device 100 shown is a laptop computer.

[0019] In this embodiment, the electronic device 100 is equipped with a parsing tool for parsing code. The electronic device 100 uses the parsing tool to parse the source code of the target project to obtain the corresponding basic node code. However, considering that type binding requires parsing the compilation environment and all dependent JAR packages, which incurs significant performance overhead and may not be predictable, making it unsuitable for parsing the source code of any project, the type binding function of the parsing tool is disabled. Instead, a type resolver is used to parse the source code, supplementing details such as variables, methods, and call relationships. It is understood that the target project can be any suitable project in the software development process, and the source code can be the code of any branch or module of any requirement in any version of the target project.

[0020] In some embodiments, any other suitable system, device, or apparatus is equipped with a parsing tool. The electronic device 100 communicates with this system, device, or apparatus via a network. The system, device, or apparatus uses the parsing tool to parse the source code of the target project to obtain the corresponding basic node code. The electronic device 100 obtains the basic node code from this system, device, or apparatus. For example, please refer to... Figure 1B Server 200 is equipped with parsing tools. Electronic device 100 communicates with server 200 via network. After server 200 parses the source code to obtain basic node code, electronic device 100 obtains basic node code from server 200 or server 200 actively sends basic node code to electronic device 100 via network.

[0021] For example, electronic device 100 is equipped with a type resolver for parsing code. After obtaining the basic node code, the type resolver is used to parse the basic node code to obtain detailed information such as variables, methods, and call relationships in the source code. This includes the fully qualified class name of the target variable, the method signature of the target method, the method body source code, the program interface path and call identifier, and the call implementation relationship between the target interface and the target implementation class (i.e., the first information). The target variable is any variable in the source code, the target method is any method in the source code, the target interface is any interface in the source code, and the target implementation class is the implementation class corresponding to the target interface. In this embodiment, based on the call identifier of the target method, the bidirectional call relationship of the target method and the call point context code (i.e., the second information) are obtained. Then, the first information and the second information are integrated based on a preset format to obtain a structured code index. Then, the predefined index fields in the structured code index are encapsulated to obtain multiple query tools, which are provided to the large language model in the form of function interfaces, enabling the large language model to call the query tools to obtain software information from the source code of the target project.

[0022] It should be understood that multiple query tools include code search, code analysis, configuration file search, database query, and code history query tools. The large language model calls one or more query tools as needed to obtain the corresponding software information from the source code of the target project.

[0023] It should be understood that, Figure 1A and Figure 1B The illustrated embodiments are merely illustrative of situations where electronic device 100 is used to obtain software information in some embodiments of this application, and do not limit the structure, type, or number of electronic devices in other embodiments. In other embodiments, the electronic device may also include... Figure 1A or Figure 1B The laptop shown has more or fewer components, or has the same... Figure 1A or Figure 1B The laptops shown have different configurations.

[0024] To facilitate understanding of the software information acquisition method for large language models provided in the embodiments of this application, the electronic device provided in the embodiments of this application will first be described in detail.

[0025] Please see Figure 2 , Figure 2 The schematic diagram illustrates the structure of an electronic device provided in some embodiments of this application.

[0026] See Figure 2 As shown, the electronic device 100 includes at least one processor 110 and at least one memory 120 connected in communication. Figure 2 Taking a bus system 130, a processor 110, and a memory 120 as an example, the various components of the electronic device 100 are coupled together through the bus system 130, which is used to realize the connection and communication between the various components. It is easy to understand that the bus system 130 may include, in addition to the data bus, a power bus, a control bus, and a status signal bus, etc. However, for the sake of clarity and brevity, in... Figure 2 The general labels all buses as Bus System 130. This is understandable. Figure 2 The structures shown in the embodiments are merely illustrative and do not limit the structure of the electronic device described above. For example, the electronic device may also include components that are more... Figure 2 The structure shown has more or fewer components, or has the same as Figure 2 The diagram shows different configurations of the structure.

[0027] Specifically, processor 110 provides computational and control capabilities to support electronic device 100 in executing corresponding business logic and functions. For example, it supports electronic device 100 in executing the software information acquisition method for large language models provided in this application embodiment, or in executing steps in any possible implementation of the software information acquisition method for large language models provided in this application embodiment. Those skilled in the art will understand that processor 110 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc., or it can be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0028] The memory 120, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, instructions, and modules, such as the programs, instructions, and modules corresponding to the software information acquisition method for large language models in the embodiments of this application. In some embodiments, the memory 120 may include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function, and the data storage area may store data created according to the use of the processor 110. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the non-transitory software programs, instructions, and modules stored in the memory 120, thereby implementing the software information acquisition method for large language models provided in the embodiments of this application, or executing the steps in any possible implementation of the software information acquisition method for large language models provided in the embodiments of this application. In some embodiments, the memory 120 may include high-speed random access memory and may also include non-transitory memory. For example, at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 120 may also include memories remotely located relative to the processor 110, which can be connected to the processor 110 through a communication network. It is understood that examples of the aforementioned communication networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0029] As can be understood from the above, the implementing entity of the software information acquisition method for large language models provided in this application embodiment can be any suitable type of electronic device with certain computing and control capabilities, such as the aforementioned electronic device 100. In some feasible implementations, the software information acquisition method for large language models provided in this application embodiment can be implemented by a processor executing computer program instructions stored in memory.

[0030] The following will describe in detail the software information acquisition method for large language models provided in this application embodiment, with reference to exemplary applications and implementations of the electronic devices provided in the embodiments of this application.

[0031] It is understood that the software information acquisition method for large language models provided in this application embodiment can be applied to the aforementioned electronic device (such as electronic device 100). Specifically, the execution entity of the software information acquisition method for large language models is one or at least two processors of the electronic device.

[0032] See Figure 3 As shown, in this embodiment of the application, software information is acquired through steps S31 to S36.

[0033] Step S31: Use a preset parsing tool to parse the source code of the target project to obtain the basic node code. The parsing tool disables the type binding function.

[0034] In this embodiment, the basic node code is the code obtained by parsing the source code using a preset parsing tool. This parsing tool can be Eclipse JDT (Java Development Tools), a core sub-project of the Eclipse platform. It is a set of open-source plugins that provide complete IDE capabilities for Java development, parsing Java code into a structured abstract syntax tree (AST) and supporting low-level operations such as code analysis, generation, and refactoring.

[0035] In this embodiment, a pre-defined parsing tool (such as an abstract syntax tree parser or a compiler front-end) is used to parse the source code of the target project to obtain structured basic node code. It is understood that the basic node code can be stored on local storage of the electronic device, or on any suitable storage medium such as a server or the cloud.

[0036] It is worth noting that, considering that when the parsing tool parses the source code for type binding, it needs to parse the compilation environment of the source code and all dependent JAR packages, which incurs significant performance overhead and may not be able to predict dependent JAR packages, it is not suitable for parsing the source code of any project. Therefore, the type binding function of the parsing tool is disabled during the process of parsing the source code to obtain the basic node code. In subsequent processes, this embodiment uses a type resolver to parse the source code and supplement detailed information such as variables, methods, and call relationships in the source code.

[0037] Step S32: Use the type resolver to parse the basic node code to obtain the first information.

[0038] The first piece of information includes the fully qualified class name of the target variable, the method signature of the target method, the method body source code, the program interface path and invocation identifier, and the invocation relationship between the target interface and the target implementation class. The target variable is any variable in the base node code. The target method is any method in the base node code. The target interface is any interface in the base node code, and the target implementation class is the implementation class in the base node code corresponding to the target interface.

[0039] For example, in this embodiment, a type resolver is used to traverse and parse the basic node code to locate various nodes (including class nodes, method nodes, field nodes, call expression nodes, etc.) in the basic node code, and to construct intermediate structures such as an abstract syntax tree (AST) index table, a symbol table, and a type mapping table. For variable declaration nodes, variable declaration information (including variable name and type identifier) ​​is parsed. Based on import statements and package information, type resolution is performed to map the type identifier of the target variable to a fully qualified class name, for example, List → java.util.List, thus obtaining the fully qualified class name of the target variable, and finally obtaining the fully qualified class names of all target variables.

[0040] For example, the method nodes are traversed to extract the method name, return type, and parameter type list. The method name, return type, and parameter type list are then combined to generate a standardized method signature, thus obtaining the method signature of the target method.

[0041] For example, the scope of method nodes can be located in the basic node code, and the source code fragment or AST subtree sequence corresponding to the method node can be extracted as the method body source code.

[0042] For example, for an interface class or a Controller class, the annotation nodes in the interface class or Controller class are parsed to extract the class-level path and method-level path. The class-level path and method-level path are then concatenated to obtain the complete program interface path, such as " / user / getById".

[0043] For example, all method invocation nodes are traversed to extract the method name, calling object type, and method context of the target method call. Based on the calling method name, calling object type, and method context, the invocation identifier of the target method (including class, method, variable, etc.) is generated.

[0044] Specifically, the basic node code is traversed, and interface type nodes and class nodes are selected. For each class node, its `implements` or `extends` list is extracted. The interface methods and implementation class methods are matched (i.e., methods with matching method signatures (including method names and parameter type lists) are searched in the implementation class and its parent classes). A mapping "(interface, interface method) → (implementation class, implementation method)" is constructed to obtain the call implementation relationship between the target interface and the target implementation class. Specifically, if a variable of type interface in the basic node code calls a method, the actual executed method can be located through the above mapping (i.e., the call implementation relationship between the target interface and the target implementation class).

[0045] Step S33: Obtain the second information based on the call identifier of the target method in the first information.

[0046] In this embodiment, the second information includes the bidirectional call relationship of the target method and the call point context code.

[0047] For example, based on the call identifier of the target method, a forward call relationship is constructed: target method → ​​called method, forming a call graph. Based on the call graph, a reverse call relationship (i.e., target method → ​​all methods that call the target method) is extracted. Integrating the forward and reverse call relationships, a bidirectional call relationship of the target method is obtained.

[0048] For example, the line containing the target method's method name is used as the call point. The code preceding the call point (M lines) and following the call point (N lines), along with the code on the line containing the target method's method name, are extracted as the call point context code. M and N are both positive integers and can be any suitable value.

[0049] Step S34: Integrate the first information and the second information based on the preset format to obtain a structured code index.

[0050] In this embodiment, the preset format includes any suitable format such as JSON, graph database structure, or inverted index. The first information and the second information are integrated according to the preset format (such as JSON format) to obtain a structured code index.

[0051] For example, a unified data structure is predefined to carry the first and second information. The predefined format includes entity fields (such as class name, method name, variable name), attribute fields (such as method signature, method body source code, program interface path, fully qualified class name), relationship fields (such as call identifier, bidirectional call relationship, call implementation relationship between interface and implementation class), and context fields (such as call point context code). A unique identifier (ID) is generated for each type of entity, including class ID, method ID, and variable ID. The target variable and its fully qualified class name are mapped to the index structure, and a mapping relationship is established between the variable ID and its type. For each method ID, the method signature, method body source code, and class information are integrated to form a method index unit. The program interface path is bound to the corresponding method ID. A call relationship index is constructed based on the call identifier and bidirectional call relationship. The call point context code and environment information are mounted to the method ID or variable ID. A class-level mapping relationship is established between the target interface and the target implementation class, and a method-level mapping relationship is established between the interface method and the implementation method. Finally, all the above information is merged to construct the smallest index unit, ultimately generating a structured code index.

[0052] For example, the code index represented in JSON format constructed in this application embodiment is as follows. This code index can be encapsulated as a query tool for large language models to call on demand.

[0053] Code index in JSON format: [ { "filePath": "src\\main\\java\\com\\example\\carc\\codeindex\\CodeVectorizer.java", "packageName": "com.example.carc.codeindex", "className": "CodeVectorizer", "fullClassName": "com.example.carc.codeindex.CodeVectorizer", "methodName": "getCollectionId", "methodSignature": "getCollectionId(String)", "startLine": 414, "endLine": 420, "methodBody": " / \n Get collection ID\n / \nprivate String getCollectionId(String collectionName) throws IOException {\nChromaHttpClient.Collectioncollection=chromaClient.getCollection(collectionName);\n returncollection.id;\n}\n", "comment": null, "javadoc": " / \n Get collection ID\n / \n", "calledMethods":["com.example.carc.util.ChromaHttpClient.getCollection"], "calledBy": [ "com.example.carc.codeindex.CodeVectorizer.indexMethodBatch", "com.example.carc.codeindex.CodeVectorizer.search", "com.example.carc.codeindex.CodeVectorizer.batchSearch", "com.example.carc.codeindex.CodeVectorizer.deleteByFilePaths" ], "apiMapping": "", "apiOperation": "" } ] Step S35: Encapsulate the code index into a tool and register it to obtain a tool set.

[0054] In this embodiment, the toolset includes multiple query tools.

[0055] For example, in this embodiment of the application, fields that can be used for querying are selected from the structured code index as index fields to obtain an index field set. The index field set includes method dimension fields (e.g., method signature, method name), type dimension fields (e.g., fully qualified class name, interface name), call relationship fields (e.g., call identifier), and context fields (e.g., call point context code), etc.

[0056] For example, a unified query tool abstract structure is defined based on the set of indexed fields. The query tool abstract structure includes the input parameter structure (including query fields (e.g., method_name / class_name) and query conditions (e.g., exact, fuzzy, range)), the output result structure (including hit field values ​​and related field information), and query constraints (e.g., the limit on the number of results returned), etc.

[0057] For example, based on different query scenarios / applicable scenarios, index fields are encapsulated into corresponding query tools, resulting in multiple query tools, each corresponding to a query capability / query type. For instance, encapsulating the method dimension field yields a method query tool corresponding to the method query type, and encapsulating the call relationship field yields a call relationship query tool corresponding to the call relationship query type.

[0058] For example, standardized interface description information is generated for each query tool to be provided to the large language model. The interface description information includes the tool name, function description, applicable scenario description, input parameter description, and output structure description, etc.

[0059] In this embodiment, each query tool corresponds to a query capability / query type, avoiding the problem of large-scale language selection due to overly coarse query tools, thereby improving query accuracy and speed.

[0060] Step S36: Provide the query tool to the large language model in the form of a function interface so that the large language model can call the query tool to obtain software information from the source code of the target project.

[0061] For example, standardized function interface description information is defined for each query tool. This description includes the function name (to uniquely identify the query tool), a function description (to describe the tool's purpose and applicable scenarios), input parameter structure (including parameter names, parameter types, parameter constraints, etc.), and output result structure (including returned field names, field meanings, etc.). All function interface description information for all query tools is managed uniformly, a function registry is constructed, and the function interface description information in the registry is passed to the large language model, enabling the large language model to have tool awareness capabilities. The function interface description information needs to meet the model's function call protocol specifications. When the large language model generates a function call request based on a user's question, this embodiment receives the function call request, which includes the target function name, input parameters, etc. Based on the target function name, the query tool corresponding to the target function name is located from the function registry, and the query tool is used to perform the following operations: parsing the input parameters, mapping them to a structured code index, performing index retrieval operations (including field matching, call relationship traversal, context code extraction, etc.), and obtaining query results (such as query hit fields, related information, and context code, etc.). The query results are encapsulated according to a predefined return structure to obtain structured response data. This structured response data is then returned to the large language model as the result of a function call. The large language model parses the structured response data to obtain software information.

[0062] In this embodiment, the query tool is available for the large language model to call on demand to complete tasks such as code search, code analysis, configuration file search, database query, and code history query, thereby obtaining the corresponding software information from the source code of the target project.

[0063] This application's embodiments quickly obtain the code skeleton through parsing tools, supplement detailed information such as variables, methods, and call relationships using type resolvers, and construct a structured code index containing bidirectional call relationships and interface implementation mappings. In this way, it does not depend on the project's build and compilation environment, and deeply understands the code situation of the software project. Moreover, the code index is encapsulated into a fast and accurate query tool for large language models to call, thereby enabling large language models to call the query tool on demand, quickly and accurately obtain software information in the source code, avoid the dependence and computational overhead brought by vector retrieval, and have low cost and high interpretability.

[0064] For example, in the embodiments of this application, steps S321 to S329 are used to parse the basic node code using a type resolver to obtain first information.

[0065] Step S321: Use the type resolver to parse the import statement and field declaration respectively to obtain the corresponding first parsing result and second parsing result.

[0066] In this embodiment, the basic node code includes import statements, field declarations, and class declarations.

[0067] For example, in this embodiment of the application, the TypeResolver is used to parse the import statement to obtain a first parsing result. The TypeResolver is also used to parse the field declaration to obtain a second parsing result. The first parsing result includes the variable name and type, and the second parsing result includes the fully qualified class name and / or wildcards.

[0068] For example, traversing the basic node code (such as AST nodes or intermediate representations), the following variable declaration information is identified and extracted: For local variable declaration statements, the declaration node is identified, and the local variable name and declaration type identifier are extracted; for field declaration statements, member variable declarations in the class are identified, and the field name and declaration type identifier are extracted; for method parameter declaration statements, the formal parameter list node in the method signature is identified, and the parameter name and declaration type identifier are extracted; for type casting and type test expressions, the bound variables in the type casting expression or type pattern matching are identified, and the name and type identifier of the converted expression text or pattern bound variable are extracted, finally obtaining the first parsing result. The type identifier is the type name directly declared in the code, i.e., the type of the declared variable.

[0069] For example, based on the type identifier extracted from the first parsing result and the source code context, the fully qualified class name corresponding to the simple type identifier is parsed, including: parsing explicit import statements and establishing a direct mapping table from simple names to fully qualified names. If a corresponding single-type import exists, the fully qualified class name is returned directly. The current package path (i.e., the package declaration) is parsed. For simple names that are not explicitly imported, a matching class file is searched in the current package path. If found, it is completed as "current package.type identifier". If none of the above steps are found, the predefined default automatic import package set of the language specification is traversed, and the matched and completed fully qualified class names from the standard library are obtained. If unresolved simple names still exist, the recorded wildcard candidate package list is traversed to find matching class files. If only one candidate match exists, it is determined as the final fully qualified class name. If multiple candidate matches exist, disambiguation is performed by combining preset domain knowledge rules (such as the similarity priority between class name suffix and package name pattern) to determine the final fully qualified class name. Finally, the second parsing result is obtained, which is the deterministic mapping relationship between the type identifier and its fully qualified class name.

[0070] Step S322: Construct a type mapping table based on the first parsing result and a class name mapping table based on the second parsing result.

[0071] In this embodiment, the type mapping table represents the correspondence between the name and type of a variable, and the class name mapping table represents the correspondence between the type and fully qualified class name of a variable.

[0072] Understandably, a type mapping table records the direct correspondence between variable names and type identifiers. Based on the first parsing result, a mapping relationship between variable names and type identifiers is established, thus constructing the type mapping table. For local variable declarations, the local variable name is associated with the type identifier. For field declarations, the field name is associated with the type identifier. For method parameter declarations, the parameter name is associated with the type identifier. For source expression text generated by type casting, a separate temporary type assertion is recorded, and the source expression text is associated with the type identifier. After associating all field names, variable names, parameter names, or source expressions generated by type casting with type identifiers, the type mapping table is obtained.

[0073] For example, taking the first code segment below as an example, the constructed type mapping table is shown in Table 1 below.

[0074] First code segment: package com.example.controller; import com.example.service.OrderService; import com.example.dto. ; import java.util. ; public class OrderController{ private OrderService orderService; / / Field declaration public void createOrder(){ OrderDTO dto = new OrderDTO(); / / Local variable List <string>items = new ArrayList<>(); } } Table 1:

[0075] As shown in Table 1, the variable names include items, orderService, and dto in the first code segment, and their corresponding types (type identifier / type name) are List, OrderService, and OrderDTO in the first code segment.

[0076] It can be understood that the class name mapping table records the mapping relationship between type identifiers and fully qualified class names. Based on the second parsing result, the mapping relationship between the type identifier of a variable and its fully qualified class name is established, thereby constructing the class name mapping table.

[0077] For example, taking the first code segment mentioned above as an example, the constructed class name mapping table is shown in Table 2 below.

[0078] Table 2:

[0079] As shown in Table 1, the variable types include List, OrderService, and OrderDTO from the first code segment, and their corresponding fully qualified class names are java.util.List (based on the wildcards in the first code segment). (Based on the variable type List), com.example.service.OrderService and com.example.dto.OrderDTO (based on the wildcard in the first code segment). (This is obtained by combining the variable type OrderDTO).

[0080] In some embodiments, the present application implements the construction of a type mapping table based on the first parsing result and the construction of a class name mapping table based on the second parsing result through steps S3221 to S3224.

[0081] Step S3221: Match the variable name with the variable type to obtain the correspondence between the variable name and type.

[0082] In this embodiment, the first parsing result includes the name and type of the variable.

[0083] For example, in this embodiment of the application, the names of variables in the first parsing result are associated one-to-one with the types / type identifiers of the variables, establishing a correspondence between the names of variables and the types / type identifiers of the variables, thus obtaining a type mapping table. Understandably, when variables with the same name exist, they are distinguished based on the scope and location information (such as the class to which they belong).

[0084] Step S3222: In response to the presence of a variable type in the fully qualified class name, determine the fully qualified class name as the type of the variable.

[0085] Step S3223: Generate the fully qualified class name of the variable's type based on the wildcard and the variable's type.

[0086] Step S3224: Match the type of the variable with the fully qualified class name of the variable's type to obtain the correspondence between the variable's type and the fully qualified class name.

[0087] In this embodiment, the second parsing result includes the fully qualified class name and / or wildcards.

[0088] The basic node code includes import statements, package statements, and type declaration statements. Import statements provide fully qualified class names or wildcards for import, package statements provide the package path of the current file, and type declaration statements provide fully qualified class names for custom types.

[0089] For example, in this application embodiment, the basic node code is traversed, import statements, package statements and type declaration statements in the basic node code are identified, and the corresponding fully qualified class names and / or wildcards are extracted.

[0090] For example, in this application embodiment, the type / type identifier of the variable is compared with the fully qualified class name. When the fully qualified class name contains the type / type identifier of the variable, it means that the fully qualified class name is the fully qualified class name of the type / type identifier of the variable, and the fully qualified class name is determined as the fully qualified class name of the type / type identifier of the variable.

[0091] For example, when no result is obtained through fully qualified class name matching, this embodiment performs completion processing based on wildcards. That is, the wildcard is concatenated with the variable's type / type identifier to generate candidate fully qualified class names. The generated candidate fully qualified class names are then validated (e.g., checked for existence in the code project or classpath). If the validation passes, the candidate fully qualified class name is determined to be the fully qualified class name of the variable's type / type identifier. Finally, the variable's type / type identifier is associated with its corresponding fully qualified class name to establish a correspondence between the variable's type / type identifier and the fully qualified class name, resulting in a class name mapping table.

[0092] It should be understood that when a variable's type / type identifier maps to multiple fully qualified class names, the correct fully qualified class name is determined according to priority rules (such as explicit imports taking precedence over wildcard imports, and custom classes in the project taking precedence over library classes).

[0093] Step S323: Obtain the fully qualified class name of the target variable in the base node code based on the type mapping table and the class name mapping table.

[0094] For example, for any target variable, this embodiment of the application obtains the type identifier of the target variable according to the type mapping table, and looks up the fully qualified class name corresponding to the type identifier of the target variable according to the class name mapping table to obtain the fully qualified class name of the target variable. In some embodiments, if there are multiple candidate fully qualified class names to be matched, the final fully qualified class name of the target variable is determined according to the priority rule (i.e., explicit import types take priority, types in the same package are medium priority, and default library types are low priority).

[0095] In some embodiments, this application embodiment achieves the acquisition of the fully qualified class name of the target variable in the basic node code based on the type mapping table and the class name mapping table through steps S3231 to S3232.

[0096] Step S3231: Determine the type in the type mapping table that corresponds to the name of the target variable as the target type of the target variable.

[0097] Step S3232: Determine the fully qualified class name of the target variable in the class name mapping table that corresponds to the target type of the target variable.

[0098] Specifically, in this embodiment, the type corresponding to the name of the target variable is found from the type mapping table, and the type corresponding to the name of the target variable is determined as the target type of the target variable. The fully qualified class name corresponding to the target type of the target variable is found from the class name mapping table, and the fully qualified class name corresponding to the target type of the target variable is determined as the fully qualified class name of the target variable.

[0099] For example, referring to Tables 1 and 2, the target variable (the name of the target variable) is items. In the type mapping table shown in Table 1, the type (or type identifier, type name) corresponding to the name items of the target variable is found to be List. The type List corresponding to the name items of the target variable is determined as the target type of the target variable. Then, in the class name mapping table, the fully qualified class name corresponding to the target type List is found to be java.util.List. The fully qualified class name java.util.List corresponding to the target type List is determined as the fully qualified class name of the target variable items.

[0100] Step S324: Locate the target method in the basic node code and extract the method name, parameter list, method body source code, class-level interface path, and method-level interface path of the target method.

[0101] For example, in this embodiment of the application, method nodes are traversed in the basic node code, target method nodes are located based on preset matching conditions, and the AST subtree structure of the target method node is extracted as structured information, or the source code corresponding to the method is directly extracted as a reference code block. The reference code block includes the method declaration, the method body, and the declaration information of the class to which the method belongs.

[0102] For example, in this embodiment of the application, syntax parsing is performed on the reference code block to extract the method name, parameter list (including the type and name of each parameter), and method body source code of the target method. In the declaration information of the class to which the target method belongs, class-level annotations (path mapping annotations) or configuration items (path definitions in configuration files) are parsed to extract the class-level interface path, where the class-level interface path represents the access path of the class or interface to which the method belongs. In the declaration information of the target method, method-level annotations are parsed to extract the method-level interface path, which is used to characterize the routing mapping path of the method itself.

[0103] Step S325: Integrate the method name and parameter list according to the preset signature format to obtain the method signature.

[0104] In this embodiment, the preset signature format includes fully qualified class name.method name(parameter type list):return value type. For example, the method name, parameter list, and return value type are structurally integrated according to the preset signature format to obtain the method signature.

[0105] Step S326: Concatenate the class-level interface path and the method-level interface path to obtain the program interface path.

[0106] For example, the class-level interface path and the method-level interface path are concatenated to obtain the complete program interface path. In some embodiments, normalization processing is performed during the concatenation process, including removing duplicate separators, completing path separators, and standardizing path format.

[0107] For example, the second code segment below illustrates the method name, method body source code, and program interface path of the target method.

[0108] Second code segment: package com.example.controller; import org.springframework.web.bind.annotation. ; @RestController @RequestMapping(" / api / order") public class OrderController{ / / Method body code /

[0109] Create an order / @PostMapping(" / create") @ApiOperation("Create Order Interface") public Result createOrder(@RequestBody OrderDTO dto, @RequestParamString userId){ orderService.save(dto); return Result.success(); } } The target method is named "createOrder" in the second code segment, and its parameter list includes "OrderDTO" and "String" from the second code segment. Combining the method name "createOrder" with the parameter list "OrderDTO" and "String" yields the method signature "createOrder(OrderDTO,String)". The method body source code is the method body code marked in the second code segment. The class-level interface path is the path " / api / order" in the second code segment, and the method-level interface path is the path " / create" in the second code segment. Concatenating the class-level interface path and the method-level interface path yields the complete program interface path " / api / order / create".

[0110] Step S327: Obtain the call identifier of the target method based on the type of the target method, the type mapping table, and the class name mapping table.

[0111] For example, in this embodiment of the application, the type mapping table and the class name mapping table are queried according to the type of the target method to determine the call identifier of the target method.

[0112] In some embodiments, this application embodiment achieves the acquisition of the call identifier of the target method based on the type of the target method, the type mapping table, and the class name mapping table through steps S3271 to S3273.

[0113] Step S3271: For methods whose target method is a simple method call type, obtain the call identifier of the target method based on the reference variable, type mapping table, and class name mapping table.

[0114] In this embodiment, the reference variable is the variable in the target method.

[0115] For example, in the basic node code, the syntax node of the target method is parsed, the call expression node is extracted, and the call type corresponding to the target method is determined based on the call expression structure. If the target method is a simple method call type, the reference variable in the call expression is extracted, the type / type identifier of the reference variable is obtained based on the type mapping table, the type / type identifier of the reference variable is parsed based on the class name mapping table to obtain the fully qualified class name of the reference variable, the called method name is extracted, and the fully qualified class name of the reference variable is combined with the called method name to obtain the call identifier of the target method.

[0116] Step S3272: For methods where the target method is a chained call type, obtain multiple call identifiers of the target method based on the reference variable, type mapping table, and class name mapping table.

[0117] In this embodiment, one call identifier corresponds to one call level.

[0118] For example, if the target method is a chained method, the chained call expression is parsed according to the call order, splitting it into multiple sub-call nodes (e.g., obj.getA().getB().getC()). Each call level is treated as an independent call level, and the following processing is performed on each call level: determine the reference variable or intermediate return object of the current level, determine the type / type identifier based on the type mapping table, obtain the fully qualified class name of the reference variable based on the class name mapping table and the type / type identifier, and extract the name of the called method of the current level. Finally, multiple call identifiers of the target method are generated according to the call order.

[0119] Step S3273: When responding to a method whose target method is a constructor call type or a static method call type, obtain the call identifier of the target method based on the type of the reference variable and the class name mapping table.

[0120] For example, if the target method is a method of the constructor call type, the constructor call expression (such as new ClassName()) is identified, the reference type (i.e. the type of the class to which the constructor belongs) is extracted, the fully qualified class name of the reference variable is obtained based on the class name mapping table and the reference type resolution, the name of the called method is extracted, the fully qualified class name of the reference variable is combined with the name of the called method, and finally the call identifier of the target method is generated.

[0121] For example, if the target method is a static method call type, the static method call expression (such as ClassName.method()) is identified, the reference type (i.e., class name) is extracted, the fully qualified class name of the reference variable is obtained based on the class name mapping table and the reference type resolution, the static method name is extracted, the fully qualified class name of the reference variable is combined with the static method name, and finally the call identifier of the target method is generated.

[0122] For example, the third code segment below illustrates the process of obtaining the call identifier of target methods of various types and the obtained call identifiers of target methods of various types.

[0123] Third code segment: package com.example.service; import com.example.dao.OrderDao; import com.example.dto.OrderDTO; import org.apache.commons.lang3.StringUtils; public class OrderService{ private OrderDao orderDao; public void processOrder(OrderDTO dto){ / / Scenario 1: Simple method call orderDao.save(dto); / / Scenario 2: Chained Calls dto.getUser().getName().toUpperCase(); / / Scenario 3: Constructor call OrderDTO newDto = new OrderDTO(); / / Scenario 4: Static method call String result = StringUtils.isEmpty(dto.getName()); } } Among them, com.example.dao.OrderDao and com.example.dto.OrderDTO are fully qualified class names, and org.apache.commons.lang3.StringUtils is a static class.

[0124] For example, based on the third code snippet, a simple method call is as follows: orderDao.save(dto) Inference process: 1. Look up the type mapping table: orderDao → OrderDao 2. Look up the class name mapping table: OrderDao → com.example.dao.OrderDao 3. Construct the complete call identifier: com.example.dao.OrderDao.save Chained calls are as follows: dto.getUser().getName().toUpperCase() Inference process: 1.dto→OrderDTO→com.example.dto.OrderDTO Build call identifier: com.example.dto.OrderDTO.getUser 2. getUser() returns the User object (e.g., com.example.entity.User). Build the call identifier: com.example.entity.User.getName 3. getName() returns a String (java.lang.String). Build call identifier: java.lang.String.toUpperCase The constructor call is as follows: new OrderDTO() Inference process: 1. Identify the keyword "new" 2. Parsing type: OrderDTO → com.example.dto.OrderDTO 3. Construct the call identifier: new:com.example.dto.OrderDTO The static method call is as follows: StringUtils.isEmpty(...) Inference process: 1. Look up the class name mapping table: StringUtils → org.apache.commons.lang3.StringUtils 2. Construct the call identifier: org.apache.commons.lang3.StringUtils.isEmpty Step S328: Use the type resolver to parse the class declaration and obtain the correspondence between the target interface and the target implementation class.

[0125] In this embodiment, the target interface is any interface in the basic node code, and the target implementation class is the implementation class corresponding to the target interface.

[0126] For example, in this embodiment of the application, a type resolver is used to parse the class declaration information in the basic node code, obtain the interface implementation relationship (such as the `implements` relationship) in each class declaration, and obtain the correspondence between interface / interface identifier and implementation class / implementation class identifier. When there are multiple implementation classes, all implementation classes are retained or the target implementation class is filtered based on the calling relationship or context information. It can be understood that the interface identifier is the fully qualified class name of the interface, and the implementation class identifier is the fully qualified class name of the implementation class.

[0127] Step S329: Based on the correspondence between the target interface and the target implementation class, and the implementation methods called in the target implementation class, construct the calling implementation relationship between the target interface and the target implementation class.

[0128] For example, in this embodiment of the application, the method nodes in the target implementation class are traversed, and the method signature, call identifier, and method body source code of the implementation methods are extracted. Based on the method signature, call identifier, and method body source code of the implementation methods, a set of call relationships within the implementation class is constructed. The correspondence between the target interface and the target implementation class, and the method call relationship in the target implementation class (i.e., the implementation methods called in the target implementation class) are structurally combined to obtain the call implementation relationship between the target interface and the target implementation class.

[0129] In some embodiments, the call implementation relationship between the target interface and the target implementation class also includes the correspondence between interface methods and implementation methods. For example, the interface methods in the target interface are matched with the methods in the target implementation class to establish the correspondence between interface methods and implementation methods.

[0130] For example, the fourth code segment below illustrates the process of obtaining the call implementation relationship between the target interface and the target implementation class, and the obtained call implementation relationship between the target interface and the target implementation class.

[0131] Fourth code segment: / / Controller package com.example.controller; public class OrderController{ private OrderService orderService; / / Note: This is an interface type. public void handleRequest(OrderDTO dto){ orderService.createOrder(dto); } } / / interface package com.example.service; public interface OrderService{ void createOrder(OrderDTO dto); } / / Implementation class package com.example.service.impl; public class OrderServiceImpl implements OrderService{ private OrderDao orderDao; @Override public void createOrder(OrderDTO dto){ orderDao.save(dto); orderDao.updateStatus(dto.getId()); } } / / Dao package com.example.dao; public class OrderDao{ public void save(OrderDTO dto){} public void updateStatus(Long id){} } According to the fourth code segment, the interface implementation class mapping is as follows: Interface mapping table: com.example.service.OrderService→[com.example.service.impl.OrderServiceImpl] Interface method mapping: com.example.service.OrderService.createOrder→com.example.service.impl.OrderServiceImpl.createOrder The API call parsing process is as follows: In OrderController: The code is: orderService.createOrder(dto) The variable type is: OrderService (interface) Interface parsing process: 1. Identify that OrderService is an interface. 2. Look up the interface mapping table 3. Locate the implementation class: OrderServiceImpl 4. Record two call relationships simultaneously: ├─com.example.service.OrderService.createOrder(interface) └─com.example.service.impl.OrderServiceImpl.createOrder(implementation class) The call implementation relationship is as follows: OrderController.handleRequest ↓Call OrderService.createOrder(interface) ↓Mapped to OrderServiceImpl.createOrder(implementation class) ↓Call ├─ OrderDao.save └─ OrderDao.updateStatus The target interface is "OrderService", the target implementation class is "OrderServiceImpl", and the methods called in the target implementation class include the methods "save" and "updateStatus" (only the abbreviated method names are written here).

[0132] For example, in this embodiment of the application, steps S331 to S339 are used to obtain the second information based on the call identifier of the target method in the first information.

[0133] Step S331: Determine the first method based on the call identifier of the target method.

[0134] In this embodiment, the bidirectional calling relationship of the target method includes a forward relationship and a reverse relationship. The first method is the method called by the target method.

[0135] For example, in this embodiment of the application, one or more call identifiers of the target method are obtained. The call identifier includes at least a caller method identifier (i.e., the target method identifier) ​​and a called method identifier. Each call identifier is parsed, and the called method identifier is extracted from the call identifier. The first method is determined based on the called method identifier.

[0136] Step S332: Construct a positive relationship based on the first method and the target method.

[0137] In this context, a positive relationship represents a call from the target method to the first method. For example, a positive relationship is constructed based on the call relationship between the target method and the first method.

[0138] Step S333: Determine the second method based on the call identifiers of all methods except the target method in the basic node code.

[0139] The second method is the method that calls the target method.

[0140] For example, in this embodiment of the application, the call identifiers of all methods except the target method in the basic node code are traversed. The call identifiers include at least the caller method identifier and the called method identifier. Each call identifier is parsed, and call identifiers whose called method identifiers are the target method identifiers are selected. Finally, the caller method identifier is extracted from the selected call identifiers, and the second method is determined based on the caller method identifier.

[0141] Step S334: Construct the reverse relationship based on the second method and the target method.

[0142] Step S335: Integrate the positive and negative relationships to obtain a bidirectional calling relationship.

[0143] In this context, the reverse relationship represents the target method being called by the second method. For example, a reverse relationship is constructed based on the calling relationship between the second method and the target method. Finally, the forward and reverse relationships of the target method are integrated to form a bidirectional calling relationship, which represents the calling relationship between the target method and other methods (i.e., the calling method and the called method).

[0144] For example, taking the aforementioned fourth code segment as an example, we can illustrate the positive and negative relationships of the constructed target method.

[0145] According to the fourth code segment, when the target method is the method "handleRequest" (only the abbreviated method name is shown here, the same below), the target method calls the method "createOrder" in the fourth code segment. When the target method is the method "createOrder" in the fourth code segment, the target method calls the methods "save" and "updateStatus" in the fourth code segment, and the target method is called by the method "handleRequest" in the fourth code segment. When the target method is either the method "save" or "updateStatus" in the fourth code segment, the target method is called by the method "createOrder" in the fourth code segment. Based on the above calling relationships, the forward and reverse relationships of the target methods constructed in this application embodiment are as follows.

[0146] Positive relations (called methods) are as follows: com.example.controller.OrderController.handleRequest └─calledMethods: [com.example.service.OrderService.createOrder] com.example.service.impl.OrderServiceImpl.createOrder └─calledMethods: [ com.example.dao.OrderDao.save, com.example.dao.OrderDao.updateStatus ] The reverse relationship (calledBy) is as follows: com.example.service.OrderService.createOrder └─ calledBy: [com.example.controller.OrderController.handleRequest] com.example.dao.OrderDao.save └─ calledBy: [com.example.service.impl.OrderServiceImpl.createOrder] com.example.dao.OrderDao.updateStatus └─ calledBy: [com.example.service.impl.OrderServiceImpl.createOrder] Step S336: Extract the code of the first preset line number before the line containing the first method in the basic node code as the first code.

[0147] In this embodiment, the first method is the method called by the target method. Engineers customize and set the first and second preset number of rows based on their engineering experience; for example, both the first and second preset number of rows are 5 rows.

[0148] For example, in this embodiment of the application, the code of a first preset number of lines is extracted forward from the line containing the first method as the first code. It can be understood that when the number of lines of all code preceding the line containing the first method is less than or equal to the first preset number of lines, then all code preceding the line containing the first method is extracted as the first code.

[0149] Step S337: Extract the code of the line containing the first method in the basic node code as candidate code.

[0150] For example, based on the call identifier of the target method, the call expression node corresponding to the first method is located in the basic node code, the position information of the call expression node in the source code is determined (e.g., the line number, or the start and end line numbers), and the code snippets corresponding to the line number range corresponding to the call expression node are extracted from the basic node code as candidate code.

[0151] It is understandable that in some embodiments, the line containing the first method refers to the line containing the method name of the first method (i.e., the call line), and only the code in the line containing the method name of the first method is extracted as candidate code.

[0152] Step S338: Extract the code from the second preset line number after the line containing the first method in the basic node code as the second code.

[0153] Step S339: Integrate the first code, candidate code, and second code to obtain the call point context code.

[0154] For example, in this embodiment of the application, the code following the line containing the first method is extracted as the second code by a second preset number of lines. It can be understood that when the number of lines of all code following the line containing the first method is less than or equal to the second preset number of lines, then all code following the line containing the first method is extracted as the second code.

[0155] For example, in the embodiments of this application, the first code, candidate code and second code are concatenated or structurally combined in code order to obtain the call point context code.

[0156] For example, in this embodiment of the application, steps S351 to S354 are used to encapsulate the code index into a tool and register it to obtain a tool set.

[0157] Step S351: Define the general tool abstract structure and registration scheduling framework.

[0158] Construct a basic framework for tool invocation that supports plug-in extensions (i.e., a general tool abstract structure). Define a general tool interface specification, including metadata fields such as tool name, function description, parameter description, applicable scenarios, and priority, as well as abstract execution methods including parameter validation, exception handling, and logging. Encapsulate general logic such as parameter validation, exception handling, and logging through an abstract base class. Specific tool classes (i.e., the query tool below) inherit from the abstract base class and implement core business logic (such as Git commit queries, database table queries, configuration file searches, and method call chain tracing).

[0159] A unified tool invocation protocol and registry center (i.e., a registration and scheduling framework) are established, and a concurrent secure hash container is used to maintain the mapping relationship between tool names and instances. The registration and scheduling framework provides capabilities for automatic tool discovery, priority sorting, structured prompt text generation, and dynamic scheduling.

[0160] Step S352: Based on the structured code index, encapsulate the call relationship query tool.

[0161] For example, based on a structured code index, queryable fields are extracted and encapsulated into a query tool that invokes relationships.

[0162] Extract the set of index fields from the code index, including call relationship fields (such as call identifiers) and context semantic fields (such as call point context code fragments).

[0163] Define a unified query tool abstract structure for index-oriented queries, and standardize the input parameter structure (e.g., query fields and condition types), output result structure (e.g., hit field values ​​and related information), and query constraints (e.g., limits on the number of results returned).

[0164] By combining the unified query tool abstraction structure, the index fields are encapsulated into calling relationship query tools according to the query dimensions, and standardized interface description information including name, description, parameter description and output example is generated for calling relationship query tools.

[0165] Step S353: Based on the software development environment metadata and configuration information, encapsulate an auxiliary query tool.

[0166] For example, an auxiliary query tool can be built for non-code text data (such as software development environment metadata) and configuration information that are relied upon during the software development process, forming a complete tool set alongside the call relationship query tool.

[0167] This paper identifies and abstracts engineering query scenarios, including version control system log retrieval, database schema definition query, and structured configuration file query. Based on a general abstract base class, specific utility classes are implemented, such as a version control query tool (supporting Git commit record and change difference retrieval), a data dictionary query tool (supporting database table structure and field comment retrieval), and a dependency configuration query tool (supporting project dependency tree and YAML / Properties configuration file parsing and retrieval). Each specific utility class is encapsulated into an auxiliary query tool with corresponding business functions. The auxiliary query tool and the call relationship query tool form a tool set.

[0168] Step S354: During the system startup phase, perform the registration operation to obtain the structured prompt text for the query tool.

[0169] During system startup, the registry center uses dependency injection or classpath scanning mechanisms to automatically discover all class instances that implement the common tool interface. These class instances cover all query tools in the tool set.

[0170] Extract the metadata of each query tool, build a mapping table from tool name to class instance, sort it according to the priority field and store it in a concurrent safe hash container.

[0171] Traverse the tool mapping table and generate structured prompt text containing the calling format, applicable scenarios, capability boundaries and usage examples of each tool, so that the large language model can use it as a calling context for tool selection and calling orchestration.

[0172] In some embodiments, a unified tool invocation protocol is defined, which includes the tool name and a sequence of parameters connected by separators. After parsing, the invocation request generates a request object containing the tool identifier and a parameter list. The registry center retrieves the corresponding tool instance from the concurrent secure hash container based on the tool name, executes the business logic of the tool instance, and returns a response object encapsulated with a status identifier, result content, error information, and suggested actions. New tools only need to implement the general tool interface and declare it as a manageable component to be automatically discovered and registered by the system, without requiring modification of the registration logic, achieving zero-configuration automatic expansion.

[0173] In some embodiments, this application implements steps S361 to S363 to enable the large language model to call a query tool to obtain software information from the source code of the target project.

[0174] Step S361: The large language model selects reference tools from the toolset based on the user's input question content.

[0175] In this embodiment, the query tool includes an applicable scenario description and a preset priority. The applicable scenario description characterizes the query type corresponding to the query tool. The reference tool is a query tool whose applicable scenario description matches the question content.

[0176] For example, the large language model extracts the query intent based on the user's input question content, and matches the query intent with the applicable scenario descriptions of each query tool in the tool set to filter out the query tools whose applicable scenario descriptions match the query intent as reference tools. Understandably, the number of reference tools may be one or more.

[0177] Step S362: In response to the presence of multiple reference tools, the large language model obtains the preset priority of the reference tools and calls multiple reference tools to query and obtain software information from the source code of the target project according to the preset priority from high to low.

[0178] For example, when multiple reference tools are selected (i.e., there are multiple reference tools), the large language model calls the reference tools in sequence. That is, it obtains the preset priority of each reference tool and calls each reference tool in order of preset priority from high to low to perform the query. It then parses the query results of each reference tool to obtain the software information in the source code of the target project.

[0179] Step S363: The large language model responds to the requirement of having only one reference tool, and calls the reference tool to query and obtain software information from the source code of the target project.

[0180] For example, when a reference tool is selected (i.e., the number of reference tools is one), the large language model calls that reference tool to perform a query, parses the query results of that reference tool to obtain the software information in the source code of the target project.

[0181] For example, the query tool called by the large language model is the SEARCH_FILE tool (i.e., the code search tool). The SEARCH_FILE tool supports full-text keyword search (i.e., directly searching the entire project's files for keyword matching), regular expression search (including exact query mode and regular expression query mode), viewing by specified line number (single or multiple lines, using the line number positioning algorithm (getting code by line number)), and context code display. It is suitable for scenarios such as searching annotation content (e.g., @PostMapping), searching code snippets, viewing code near a specified line number, and complex regular expression matching.

[0182] For example, the query tool invoked by the large language model is the SEARCH_CONFIG tool (also known as the configuration file search tool), which supports searching configuration files such as YML, YAML, Properties, and XML, and also supports searching for configuration item names and values. The SEARCH_CONFIG tool is based on recognizing configuration file extensions (such as .yml, .yaml, .properties, .xml, etc.) and configuration file names (such as application, bootstrap, config, pom), and is suitable for scenarios such as finding database configurations, finding Redis / MQ configurations, and finding configuration items such as ports and paths.

[0183] For example, the query tool called by the large language model is the DATABASE tool (i.e., the database query tool), which supports functions such as querying all tables in the database, querying table structure, and querying table data. The DATABASE tool is implemented using methods such as JDBC-based database connection and SQL security checks (prohibiting dangerous operations such as DELETE, UPDATE, INSERT, and DROP), and is suitable for scenarios such as viewing data tables, viewing table structure, and querying table data in the database.

[0184] For example, the query tool called by the large language model is the GIT_DIFF tool (i.e., the code commit query tool), which supports functions such as viewing commit history, viewing commit details, viewing code differences, viewing file modification records, searching commit information, and viewing author commit records. The GIT_DIFF tool is implemented by executing Git commands and parsing Git output through ProcessBuilder, and is suitable for scenarios such as viewing code change history, tracking defect fix records, and analyzing code evolution.

[0185] In summary, the embodiments of this application quickly obtain the code skeleton through parsing tools and supplement it with detailed information such as variables, methods, and call relationships using a type resolver, constructing a structured code index containing bidirectional call relationships and interface implementation mappings. In this way, it can deeply understand the code situation of the software project without relying on the project's build and compilation environment. Moreover, the code index is encapsulated into a fast and accurate query tool for large language models to call, thereby enabling large language models to call the query tool on demand to quickly and accurately obtain software information in the source code. This avoids the dependence and computational overhead brought by vector retrieval, resulting in low cost and high interpretability.

[0186] This application provides a computer-readable storage medium storing processor-executable computer program instructions. When executed by a processor, the computer program instructions cause the processor to perform the software information acquisition method for large language models provided in this application, or to perform the steps in any possible implementation of the software information acquisition method for large language models provided in this application.

[0187] Those skilled in the art will understand that the embodiments provided in this application are merely illustrative. The order in which the steps in the methods of the embodiments are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The order can be adjusted, merged, and deleted according to actual needs. Modules or sub-modules, units or sub-units in the apparatus or system of the embodiments can be merged, divided, and deleted according to actual needs. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. For another example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed.

[0188] Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, and of course, it can also be implemented using hardware. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. It should be understood that the storage medium can be flash memory, hard disk, optical disk, register, magnetic surface memory, removable disk, CD-ROM, random access memory (RAM), read-only memory (ROM), electrically programmable ROM, and electrically erasable programmable ROM, etc.

[0189] It should be noted that the above embodiments are for illustrating the technical concept and features of this application, and are intended to enable those skilled in the art to understand the content of this application and implement it accordingly. They should not be construed as limiting the scope of protection of this application. Those skilled in the art can understand that all or part of the processes of the above embodiments can be implemented, modified according to the technical solutions described in the embodiments of this application, or equivalent substitutions can be made to some of the technical features. It is understood that these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and should be considered as equivalent changes and modifications made based on the embodiments of this application, all of which should fall within the scope of the claims of this application.< / string>

Claims

1. A method for acquiring software information for large language models, characterized in that, include: The source code of the target project is parsed using a preset parsing tool to obtain the basic node code. The parsing tool has its type binding function disabled. The basic node code is parsed using a type resolver to obtain first information, which includes the fully qualified class name of the target variable, the method signature of the target method, the method body source code, the program interface path and call identifier, and the call implementation relationship between the target interface and the target implementation class. Based on the call identifier of the target method in the first information, the second information is obtained, which includes the bidirectional call relationship of the target method and the call point context code; The first information and the second information are integrated based on a preset format to obtain a structured code index; The code index is encapsulated into a tool and registered to obtain a tool set, wherein the tool set includes multiple query tools; The query tool is provided to the large language model in the form of a function interface, so that the large language model can call the query tool to obtain software information from the source code of the target project.

2. The software information acquisition method according to claim 1, characterized in that, The basic node code includes import statements, field declarations, and class declarations. The process of parsing the basic node code using a type resolver to obtain first information includes: The type parser is used to parse the field declaration and the import statement respectively to obtain the corresponding first parsing result and second parsing result; A type mapping table is constructed based on the first parsing result, and a class name mapping table is constructed based on the second parsing result. The type mapping table represents the correspondence between the name and type of a variable, and the class name mapping table represents the correspondence between the type of the variable and the fully qualified class name. Based on the type mapping table and the class name mapping table, obtain the fully qualified class name of the target variable; Locate the target method in the base node code, and extract the method name, parameter list, method body source code, class-level interface path, and method-level interface path of the target method; The method name and the parameter list are integrated according to a preset signature format to obtain the method signature; The class-level interface path and the method-level interface path are concatenated to obtain the program interface path; Based on the type of the target method, the type mapping table, and the class name mapping table, the call identifier of the target method is obtained; The class declaration is parsed using the type resolver to obtain the correspondence between the target interface and the target implementation class; Based on the correspondence between the target interface and the target implementation class, and the implementation methods called in the target implementation class, the call implementation relationship between the target interface and the target implementation class is constructed.

3. The software information acquisition method according to claim 2, characterized in that, The first parsing result includes the name and type of the variable, and the second parsing result includes the fully qualified class name and / or wildcards. The step of constructing a type mapping table based on the first parsing result and a class name mapping table based on the second parsing result includes: The names of the variables are associated with their types to obtain the correspondence between the variable names and types; In response to the presence of the variable's type in the fully qualified class name, determine that the fully qualified class name is the fully qualified class name of the variable's type; Based on the wildcard and the type of the variable, generate the fully qualified class name of the variable's type; The type of the variable is associated with the fully qualified class name of the variable type to obtain the correspondence between the variable type and the fully qualified class name.

4. The software information acquisition method according to claim 2, characterized in that, Obtaining the fully qualified class name of the target variable based on the type mapping table and the class name mapping table includes: The type corresponding to the name of the target variable in the type mapping table is determined as the target type of the target variable; The fully qualified class name corresponding to the target type of the target variable in the class name mapping table is determined to be the fully qualified class name of the target variable.

5. The software information acquisition method according to claim 2, characterized in that, The step of obtaining the call identifier of the target method based on the type of the target method, the type mapping table, and the class name mapping table includes: When the target method is a simple method call type, the call identifier of the target method is obtained based on the reference variable, the type mapping table, and the class name mapping table, where the reference variable is a variable in the target method; and / or, In response to a method that is a chained call type, multiple call identifiers of the target method are obtained based on the reference variable, the type mapping table, and the class name mapping table, where each call identifier corresponds to a call level; and / or, When the target method is a constructor call type or a static method call type, the call identifier of the target method is obtained according to the type of the reference variable and the class name mapping table.

6. The software information acquisition method according to claim 1, characterized in that, The bidirectional invocation relationship includes a forward relationship and a reverse relationship. The step of obtaining the second information based on the invocation identifier of the target method in the first information includes: Based on the call identifier of the target method, a first method is determined, wherein the first method is the method called by the target method; Based on the first method and the target method, the positive relationship is constructed, wherein the positive relationship represents that the target method calls the first method; Based on the call identifiers of all methods in the basic node code except the target method, the second method is determined, and the second method is the method that calls the target method; Based on the second method and the target method, the reverse relationship is constructed, wherein the reverse relationship indicates that the target method is invoked by the second method; The positive relationship and the negative relationship are integrated to obtain the bidirectional calling relationship; Extract the code from the basic node code that is a first preset number of lines before the line containing the first method, and use it as the first code; Extract the line containing the first method from the basic node code as candidate code; Extract the code from the basic node code after the line containing the first method, which is a second preset line number, as the second code; The first code, the candidate code, and the second code are integrated to obtain the call point context code.

7. The software information acquisition method according to any one of claims 1-6, characterized in that, The process of encapsulating the code index into a tool and registering it to obtain a tool set includes: Define a general-purpose tool abstract structure and registration scheduling framework; Based on the structured code index, a call relationship query tool is encapsulated; Based on the metadata and configuration information of the software development environment, an auxiliary query tool is encapsulated. During system startup, a registration process is performed, resulting in structured prompts for the query tool.

8. The software information acquisition method according to any one of claims 1-6, characterized in that, The query tool includes descriptions of applicable scenarios and preset priorities. The large language model invokes the query tool to obtain software information from the source code of the target project, including: The large language model filters reference tools from the tool set based on the question content input by the user. The reference tools are query tools whose applicable scenario descriptions match the question content. The large language model responds to the fact that there are multiple reference tools, obtains the preset priority of the reference tools, and calls multiple reference tools to query and obtain software information from the source code of the target project according to the preset priority from high to low. The large language model responds to the fact that there is only one reference tool, and calls the reference tool to query and obtain software information from the source code of the target project.

9. An electronic device, characterized in that, The device includes a processor and a memory, the processor being communicatively connected to the memory, the memory storing computer program instructions executable by the processor, the computer program instructions being executed by the processor to cause the electronic device to perform the software information acquisition method for large language models as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, cause the processor to perform the software information acquisition method for large language models as described in any one of claims 1 to 8.

Images