Project constraint document generation method and device, electronic equipment and program product

Abstract

The invention discloses a project constraint document generation method and device, electronic equipment and a program product, and relates to the field of financial science and technology, and the generation method comprises the steps: analyzing configuration files of a plurality of projects to obtain target configuration information, traversing a package path of each project, and enabling each package path to have a plurality of code files, the code file comprises at least one member function; based on all the package paths, determining a target naming rule of each code file, and determining structured data of each member function; determining semantic description of each member function, determining code snippets for calling each member function, and generating a code calling template based on the code snippets; and generating a project constraint document based on all the target configuration information, all the target naming rules, all the structured data, all the semantic descriptions and all the code calling templates. According to the invention, the technical problem of low efficiency of manually writing the project constraint document in related technologies is solved.

Description

Technical Field

[0001] This invention relates to the field of financial technology, and more specifically, to a method, apparatus, electronic device, and program product for generating project constraint documents. Background Technology

[0002] Currently, tools that use artificial intelligence to assist software development rely on project specification documents (such as Markdown, a lightweight markup language) as input for code generation. However, developers need to manually parse the code and fill in the code content item by item to write the project specification document. Manual writing consumes a lot of manpower, and the document needs to be manually updated regularly to match code changes, which is inefficient.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This invention provides a method, apparatus, electronic device, and program product for generating project constraint documents, to at least solve the technical problem of low efficiency in manually writing project constraint documents in related technologies.

[0005] According to one aspect of the embodiments of this application, a method for generating a project constraint document is provided, comprising: parsing configuration files of multiple projects to obtain target configuration information, and traversing the package path of each project, wherein each package path contains multiple code files, and each code file contains multiple source codes, the source codes including: at least one class, and each class corresponding to at least one member function; determining the target naming rules for each code file based on all package paths, and determining the structured data for each member function; determining the semantic description of each member function, and determining the code snippet that calls each member function, generating a code call template based on the code snippet; and generating a project constraint document based on all target configuration information, all target naming rules, all structured data, all semantic descriptions, and all code call templates.

[0006] Further, the steps of parsing the configuration files of multiple projects to obtain the target configuration information include: parsing the configuration file of each project to obtain multiple project data; using regular expressions to match multiple preset words in the project data and determining the corresponding content of each preset word; and determining the target configuration information based on all project data, all preset words, and all content.

[0007] Furthermore, the step of determining the target naming rule for each code file based on all package paths includes: calculating the similarity between any two package paths using a preset distance algorithm, and clustering the code fragments to obtain semantic clustering results; determining the hierarchical architecture of each package path based on all similarities and semantic clustering results; and determining the target naming rule based on all hierarchical architectures.

[0008] Furthermore, the steps for determining the structured data for each member function include: for each member function in each project, obtaining multiple metadata of the member function and obtaining the number of times the member function is called in the project; classifying each member function to obtain the member function type of the member function; and for each member function, determining the structured data based on all metadata, the number of times it is called, and the member function type.

[0009] Furthermore, the metadata includes at least: the member function name, parameter list, parameter types, scope, and classpath of each member function. The steps to obtain multiple metadata of a member function include: parsing each member function based on the abstract syntax tree to extract the member function name, parameter list, and parameter types; determining the scope of each member function and the classpath of each member function, where the scope indicates the set of objects accessing the member function, and the classpath indicates the location of the class corresponding to the member function.

[0010] Furthermore, the parameter list includes at least input parameters and output parameters, and the member function also includes at least code annotations and a member function body. The steps for determining the semantic description of each member function include: determining the parameter states of the input and output parameters based on the code annotations; performing semantic parsing on the member function body to obtain the functional description of the member function body, wherein the member function body is the logical code used to implement the function of the member function; and determining the semantic description based on the parameter states and the functional description.

[0011] Furthermore, before determining the code snippet that calls each member function, the process includes: determining whether there is a code snippet that calls the member function based on the number of times each member function is called; and if there is no code snippet that calls the member function, constructing the code snippet that calls the member function based on the member function's parameter list and parameter types.

[0012] According to another aspect of the embodiments of this application, a project constraint document generation apparatus is also provided, comprising: a first parsing unit, configured to parse configuration files of multiple projects to obtain target configuration information, and traverse the package path of each project, wherein each package path contains multiple code files, and each code file contains multiple source codes, the source codes including: at least one class, and each class corresponding to at least one member function; a first determining unit, configured to determine the target naming rules of each code file based on all package paths, and determine the structured data of each member function; a first generating unit, configured to determine the semantic description of each member function, and determine the code snippet that calls each member function, and generate a code call template based on the code snippet; and a second generating unit, configured to generate a project constraint document based on all target configuration information, all target naming rules, all structured data, all semantic descriptions, and all code call templates.

[0013] Furthermore, the first parsing unit includes: a first parsing module, used to parse the configuration file of each project to obtain multiple project data; a first matching module, used to use regular expressions to match multiple preset words in the project data and determine the corresponding content of each preset word; and a first determining module, used to determine the target configuration information based on all project data, all preset words, and all content.

[0014] Furthermore, the first determining unit includes: a first calculation module, used to calculate the similarity between any two package paths using a preset distance algorithm, and to cluster code fragments to obtain semantic clustering results; a second determining module, used to determine the hierarchical architecture of each package path based on all similarities and semantic clustering results; and a third determining module, used to determine the target naming rules based on all hierarchical architectures.

[0015] Furthermore, the first determining unit also includes: a first obtaining module, used to obtain multiple metadata of each member function for each member function of each project, and obtain the number of times the member function is called in the project; a first classifying module, used to classify each member function to obtain the member function type of the member function; and a fourth determining module, used to determine structured data for each member function based on all metadata, the number of times it is called, and the member function type.

[0016] Furthermore, the metadata includes at least: the member function name, parameter list, parameter types, scope, and classpath of each member function. The first acquisition module includes: a first extraction submodule, used to parse each member function based on the abstract syntax tree and extract the member function name, parameter list, and parameter types; and a first determination submodule, used to determine the scope of each member function and the classpath of each member function, wherein the scope indicates the set of objects accessing the member function, and the classpath indicates the location of the class corresponding to the member function.

[0017] Furthermore, the parameter list includes at least input parameters and output parameters, and the member function also includes at least code annotations and a member function body. The first generation unit includes: a fifth determining module, used to determine the parameter states of the input and output parameters based on the code annotations; a second parsing module, used to perform semantic parsing on the member function body to obtain the functional description of the member function body, wherein the member function body is the logical code used to implement the function of the member function; and a sixth determining module, used to determine the semantic description based on the parameter states and the functional description.

[0018] Furthermore, the device for generating the project constraint document includes: a first judgment module, used to determine whether there is a code segment that calls a member function based on the number of times each member function is called before determining the code segment that calls each member function; and a first construction module, used to construct the code segment that calls the member function based on the parameter list and parameter types of the member function if there is no code segment that calls the member function.

[0019] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method for generating any of the above-described project constraint documents.

[0020] According to another aspect of the embodiments of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement any of the above-described methods for generating project constraint documents.

[0021] In this invention, configuration files of multiple projects are parsed to obtain target configuration information, and the package paths of each project are traversed. Based on all package paths, the target naming rules for each code file are determined, and the structured data for each member function is determined. The semantic description of each member function is determined, and the code snippet that calls each member function is determined. Based on the code snippets, a code call template is generated. Based on all target configuration information, all target naming rules, all structured data, all semantic descriptions, and all code call templates, a project constraint document is generated, solving the technical problem of low efficiency in manually writing project constraint documents in related technologies.

[0022] In this invention, configuration files for multiple projects are first parsed to capture target configuration information. Then, the package paths of each project are traversed, and the code files under the paths and the source code contained in the files are analyzed. Based on the analysis results of all package paths, the target naming rules for each code file and the structured data of each member function can be determined, improving the standardization of the documentation. At the same time, natural language processing technology can be used to determine the semantic description of each member function, and the code snippets that call each member function can be determined based on the abstract syntax tree. Based on the code snippets, code call templates can be generated. Finally, based on all target configuration information, all target naming rules, all structured data, all semantic descriptions, and all code call templates, the automatic generation of specification documents is realized, improving development efficiency. Attached Figure Description

[0023] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0024] Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a method for generating project constraint documents is shown.

[0025] Figure 2 This is a flowchart of the method for generating project constraint documents according to Embodiment 1 of this application;

[0026] Figure 3 This is a schematic diagram of an optional project constraint document generation apparatus according to an embodiment of this application;

[0027] Figure 4 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0028] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] It should be noted that all related information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) collected and involved in this invention are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with the relevant laws, regulations, and standards of the relevant regions, and necessary confidentiality measures have been taken. These measures do not violate public order and good morals, and corresponding operation entry points are provided for users to choose to authorize or refuse. For example, this system has an interface with relevant users or organizations. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned user or organization through the interface. After receiving consent from the aforementioned user or organization, the relevant information is obtained. If the user chooses to refuse, the process proceeds to an expert decision-making process.

[0031] In this invention, documentation can be automatically generated through code scanning and algorithm analysis, eliminating the need for manual writing and improving efficiency. Furthermore, information such as technology stack versions and module naming rules strictly match the code project, avoiding human error. In addition, the documentation can be automatically updated as the code changes, achieving real-time synchronization between specifications and project status. The generated documentation has a standardized structure and can be directly used as input for software development tools, improving the accuracy and efficiency of code generation.

[0032] The present invention will now be described in detail with reference to various embodiments.

[0033] Example 1

[0034] According to an embodiment of this application, an embodiment of a method for generating project constraint documents is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a method for generating project constraint documents is shown. Figure 1 As shown, computer terminal 10 (or mobile device) may include one or more ( Figure 1 The processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions may also be included. In addition, it may include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera, wherein the network interface can be connected to wired and / or wireless networks. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0036] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0037] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the project constraint document generation method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-mentioned project constraint document generation method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0038] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0039] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0040] Under the aforementioned operating environment, this application provides the following: Figure 2 The method for generating project constraint documents is shown. Figure 2 This is a flowchart of the method for generating project constraint documents according to Embodiment 1 of this application, as follows: Figure 2 As shown, the method includes the following steps:

[0041] Step S201: Parse the configuration files of multiple projects to obtain the target configuration information, and traverse the package path of each project. Each package path contains multiple code files, and each code file contains multiple source codes. The source code includes at least one class, and each class has at least one member function.

[0042] Optionally, a configuration file is a file in a project used to store information such as parameters, paths, and dependencies, such as pom.xml in a Java (a programming language) project. Package paths are the directory structure for defining classes and resource files in a Java project, separated by ".", for example: "com.example.service".

[0043] In this embodiment of the invention, the technology stack (i.e., target configuration information) related to the project can be parsed from the configuration file. The technology stack is a collection of various software tools, programming languages, frameworks, libraries, and infrastructure used in the project. Simultaneously, the package paths of each project can be traversed to collect all code files and their source code information. For example, a Java application contains a pom.xml file and multiple package paths. By parsing the pom.xml file, the project's target configuration information, such as framework version, core dependencies, and tool versions, can be extracted. Furthermore, by traversing the code files in the package paths, the source code within them can be identified, including classes and their member functions.

[0044] Step S202: Based on all package paths, determine the target naming rules for each code file and determine the structured data for each member function.

[0045] In this embodiment of the invention, the code file, i.e., the .java file, can determine the hierarchical structure of each package path by calculating the similarity between various package paths, thereby determining the target naming rules for each code file. For each member function, information such as its scope (i.e., access modifier), parameter list, and return type can be recorded to form structured data.

[0046] Step S203: Determine the semantic description of each member function and determine the code snippet that calls each member function. Based on the code snippet, generate a code call template.

[0047] In this embodiment of the invention, semantic description refers to the functional explanation, parameter description, and exception description of member functions. It can be obtained through code comments or large model analysis. Furthermore, code snippets that call each member function can be extracted, and code call templates can be generated based on the code snippets. For example, the code call template for the getUserInfoById() member function is: userInfo=userService.getUserInfoById(123), to demonstrate how to call these member functions in the project.

[0048] Step S204: Generate a project constraint document based on all target configuration information, all target naming rules, all structured data, all semantic descriptions, and all code call templates.

[0049] In this embodiment of the invention, by combining all target configuration information (technology stack version, dependency libraries, etc.), target naming rules (package path, class name naming conventions), structured data (detailed information of member functions), semantic descriptions (functional explanations, parameter descriptions, and exception descriptions of member functions, etc.), and code call templates, a project specification document (i.e., project constraint document) containing technology stack, module design, common member functions, test specifications, etc. can be generated. This document lists the project's architecture specifications, technical requirements, and usage instructions for each member function, improving the efficiency and accuracy of document creation and reducing human error.

[0050] In summary, by parsing configuration files from multiple projects to extract target configuration information, and simultaneously traversing package paths within the projects to identify source code structure, including classes and their member functions, the naming rules and structured data of each code file's member functions, such as scope, parameter list, and return type, are determined based on all package paths. Natural language processing techniques can then be used to determine the semantic descriptions of member functions and automatically extract or generate code snippets for call examples, forming standardized code call templates. Finally, by integrating all target configuration information, naming rules, structured data, semantic descriptions, and call templates, a comprehensive and accurate project constraint document is automatically generated. This not only improves the efficiency of constraint document creation but also ensures consistency between the document and the code, enhancing the quality and speed of team collaboration and project maintenance. Ultimately, it solves the technical problem of low efficiency in manually writing project constraint documents in related technologies.

[0051] In order to accurately determine the target configuration information, in the project constraint document generation method provided in Embodiment 1 of this application, the configuration file of each project is parsed to obtain multiple project data; regular expressions are used to match multiple preset words in the project data and determine the corresponding content of each preset word; based on all project data, all preset words and all content, the target configuration information is determined.

[0052] In this embodiment of the invention, the configuration file of each project can be parsed to extract all project data, including but not limited to framework version, core dependencies, tool version, and other information. Regular expressions can be used to match multiple preset words (i.e., technology stack keywords) in the project data, and the corresponding content for each preset word can be determined. Based on all project data, all preset words, and all content, the target configuration information is determined, resulting in a structured technology stack list. This step eliminates the tedious work of manually parsing configuration files and avoids errors caused by human factors.

[0053] In order to accurately determine the target naming rules, in the project constraint document generation method provided in Embodiment 1 of this application, a preset distance algorithm is used to calculate the similarity between any two package paths, and code fragments are clustered to obtain semantic clustering results; based on all similarities and semantic clustering results, the hierarchical architecture of each package path is determined; based on all hierarchical architectures, the target naming rules are determined.

[0054] In this embodiment of the invention, the Levenshtein distance algorithm (an algorithm for measuring the degree of difference between two strings) can be used to calculate the similarity between any two package paths. For example, if there are two package paths: com.example.service.user and com.example.service.order, which share the same prefix in the "com.example.service" part, the Levenshtein distance algorithm can calculate a lower value, indicating that the two are more similar in naming patterns. Based on similarity, we can initially obtain a set of package paths within different similarity ranges. For each set of package paths within a similarity range, we can use a large language model to perform semantic clustering on the code snippets under all package paths, grouping code snippets with similar functions together to obtain semantic clustering results. For example, if the similarity between the package paths com.example.project.api, com.example.project.service, and com.example.project.data and other package paths is low, meaning that these package paths independently carry different functional domains, we can select code snippets under these package paths and perform semantic clustering on them using a large language model to obtain multiple clusters (e.g., code snippet clusters related to API (Application Programming Interface), code snippet clusters related to services, and code snippet clusters related to data access). Similarly, we can use the above steps to perform semantic clustering on code snippets under other package paths to obtain clustering results.

[0055] Alternatively, semantic vectors of code snippets can be extracted using a large language model, and clustering algorithms can be used to cluster the semantic vectors to obtain clustering results.

[0056] Optionally, the code functions in different package paths may differ. For example, package paths like com.example.project.api, com.example.project.service, and com.example.project.data can identify the layered architecture of each package path (e.g., API layer, service layer, data access layer, etc.) through clustering results. Based on all layered architectures, the naming convention of each code file can be standardized (i.e., target naming rules). For example, package path com.example.project.service has a service layer architecture. The code files under this package path implement business logic, process data, and provide services. Therefore, the naming convention of this code file can be: lowercase English letters + functional description (e.g., userservice.java), expressing its identity as a service layer and the functional areas it is responsible for. Automated naming rule generation helps avoid confusion caused by inconsistent naming habits, improving code development efficiency and the convenience of document maintenance.

[0057] In order to accurately determine the structured data, in the project constraint document generation method provided in Embodiment 1 of this application, for each member function of each project, multiple metadata of the member function are obtained, and the number of times the member function is called in the project is obtained; each member function is classified to obtain the member function type of the member function; for each member function, the structured data is determined based on all metadata, the number of times it is called, and the member function type.

[0058] In this embodiment of the invention, for each member function of each project, the source code can be parsed using JavaParser (a Java parsing library) to generate an Abstract Syntax Tree (AST) to represent the syntactic structure of the program. This allows for the acquisition of multiple metadata of the member function, such as function name, parameter list, return type, scope, classpath to which the member function belongs, and comments. Simultaneously, by traversing the project source code and constructing a control flow graph, the number of times each member function is called in the project can be counted.

[0059] Optionally, member functions can be categorized based on functional dimensions (e.g., data processing classes (e.g., JSON (JavaScript Object Notation) parsing), business logic classes (e.g., permission verification), utility classes (e.g., date formatting), call hierarchy (e.g., core methods (called by ≥3 modules), general methods (cross-package calls), local methods (single-package calls), etc.) and performance characteristics (e.g., high-time-consuming methods (execution time > 50ms), high-frequency-call methods (number of calls > 100), etc.) to obtain member function types. For each member function, structured data is determined based on all metadata, the number of times it is called, and the member function type, saving developers' manual recording time and improving information completeness.

[0060] For example, structured data is shown below:

[0061] |Method Name|Class Path|Number of Calls|Method Type|Parameter Description|Return Type|;

[0062] |getGroupInfo()|com.icbc.cardendcp.service.GroupService|12|Business Logic|String groupId|GroupDO|.

[0063] The metadata includes at least the member function name, parameter list, parameter type, scope, and classpath of each member function. To accurately determine the metadata, in the project constraint document generation method provided in Embodiment 1 of this application, each member function is parsed based on an abstract syntax tree to extract the member function name, parameter list, and parameter type; the scope of each member function is determined, and the classpath of each member function is determined. The scope is used to indicate the set of objects accessing the member function, and the classpath is used to indicate the location of the class corresponding to the member function.

[0064] In this embodiment of the invention, the metadata includes at least the member function name, parameter list, parameter type, scope, and classpath to which the member function belongs. Each member function in the project can be parsed based on an Abstract Syntax Tree (AST), extracting the member function name, parameter list, and parameter type from the source code. The scope of the member function can be determined, i.e., which objects can access the member function. For example, public (meaning the function can be accessed by any other class in the project), protected (meaning it can be accessed by the class corresponding to the member function, other classes in the same package, and subclasses), and private (meaning it can only be accessed within the class corresponding to the member function). Simultaneously, the classpath to which each member function belongs can be determined. The classpath indicates the location of the class corresponding to the member function. By directly obtaining information from the code structure, the inaccuracy and time-consuming nature of manual interpretation are avoided.

[0065] The parameter list includes at least input parameters and output parameters, and the member function also includes at least code annotations and member function bodies. In order to accurately determine the semantic description, in the project constraint document generation method provided in Embodiment 1 of this application, the parameter states of the input parameters and output parameters are determined based on the code annotations; the member function bodies are semantically parsed to obtain the functional descriptions of the member function bodies, wherein the member function bodies are the logical code used to implement the functions of the member functions; and the semantic descriptions are determined based on the parameter states and the functional descriptions.

[0066] In this embodiment of the invention, code annotations are explanatory marks in the source code used to explain additional non-functional information to the compiler or program. Based on code annotations, the states of input and output parameters are identified and determined. For example, in the member function `public UserDTO getUserInfo(@NonNull Long userId)`, parsing the `@NonNull` annotation determines that the `userId` parameter cannot be null. Semantic parsing can also be performed on the member function body (the logic code that implements the member function's functionality) to obtain a functional description of the member function body. Based on the parameter states and functional descriptions, a semantic description for the member function can be automatically generated, including parameter usage constraints, expected function behavior, and exception handling instructions, effectively reducing the workload of writing comments. The semantic description can be displayed in Markdown format; for example, a structured semantic description is:

[0067] Function Description: [Core Functionality of the Method];

[0068] Parameter description: [Parameter name]: [Parameter type], [Parameter function];

[0069] Return value: [Return type], [Return value meaning];

[0070] Exception description: [Possible exception types thrown].

[0071] In order to accurately generate code call templates, in the project constraint document generation method provided in Embodiment 1 of this application, it is determined whether there is a code snippet that calls the member function based on the number of times each member function is called; if there is no code snippet that calls the member function, the code snippet that calls the member function is constructed based on the parameter list and parameter type of the member function.

[0072] In this embodiment of the invention, by counting the number of times each member function is called, it can be determined whether there is a code snippet that calls the member function. That is, member functions whose call points cannot be found in the code library are filtered out (the call points can be located through AST). In the case that there is no code snippet that calls the member function, the code snippet that calls the member function is constructed based on the parameter list and parameter types of the member function. For example, the original method is:

[0073] public String formatDate(Date date,String pattern){;

[0074] return new SimpleDateFormat(pattern).format(date);}.

[0075] The generated code snippet can be:

[0076] / / Format the current date;

[0077] String today=DateUtil.formatDate(new Date(), "yyyy-MM-dd");

[0078] / / Output: 2023-09-15.

[0079] By automatically identifying and constructing call examples of member functions, reasonable sample code can be generated even when there is a lack of actual calls in the codebase.

[0080] The project constraint document generation method provided in this application can determine the target configuration information by parsing the configuration file, and accurately calculate the package path similarity and semantic clustering through the Levenshtein distance algorithm and large language model to automatically determine the hierarchical architecture and naming rules of the code, ensuring the consistency and clarity of the project structure. At the same time, it can construct an AST parse tree, and with the help of control flow graph analysis, extract metadata from member functions and classify member functions to obtain structured data. In addition, it can generate structured semantic descriptions based on the semantic parsing of parameter states and member function bodies, and can automatically identify the number of times member functions are called and construct call examples of member functions without call points. Even if there is a lack of actual calls in the code library, it can generate reasonable example code. Finally, based on all target configuration information, all target naming rules, all structured data, all semantic descriptions, and all code call templates, the project constraint document is generated, which improves the generation efficiency and accuracy of the specification document.

[0081] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0082] Example 2

[0083] This application also provides an apparatus for generating project constraint documents. It should be noted that this apparatus can be used to execute the project constraint document generation method provided in this application. The following describes the apparatus for generating project constraint documents provided in this application.

[0084] According to an embodiment of this application, an apparatus for implementing the above-described method for generating project constraint documents is also provided. Figure 3 This is a schematic diagram of an optional project constraint document generation apparatus according to an embodiment of this application, such as... Figure 3 As shown, the device for generating the project constraint document may include: a first parsing unit 30, a first determining unit 31, a first generating unit 32, and a second generating unit 33.

[0085] The first parsing unit 30 is used to parse the configuration files of multiple projects to obtain the target configuration information and traverse the package path of each project. Each package path contains multiple code files, and each code file contains multiple source codes. The source code includes at least one class, and each class has at least one member function.

[0086] The first determining unit 31 is used to determine the target naming rules for each code file based on all package paths, and to determine the structured data for each member function;

[0087] The first generation unit 32 is used to determine the semantic description of each member function and the code snippet that calls each member function, and generate a code call template based on the code snippet;

[0088] The second generation unit 33 is used to generate project constraint documents based on all target configuration information, all target naming rules, all structured data, all semantic descriptions, and all code call templates.

[0089] The project constraint document generation device provided in this application embodiment can parse the configuration files of multiple projects through the first parsing unit 30 to obtain target configuration information and traverse the package path of each project. It can determine the target naming rules of each code file and the structured data of each member function based on all package paths through the first determining unit 31. It can determine the semantic description of each member function and the code snippet that calls each member function through the first generation unit 32. Based on the code snippet, it generates a code call template. It can generate a project constraint document based on all target configuration information, all target naming rules, all structured data, all semantic descriptions, and all code call templates through the second generation unit 33.

[0090] Optionally, the first parsing unit 30 includes: a first parsing module, used to parse the configuration file of each project to obtain multiple project data; a first matching module, used to use regular expressions to match multiple preset words in the project data and determine the corresponding content of each preset word; and a first determining module, used to determine the target configuration information based on all project data, all preset words, and all content.

[0091] Optionally, the first determining unit 31 includes: a first calculation module, used to calculate the similarity between any two package paths using a preset distance algorithm, and to cluster code fragments to obtain semantic clustering results; a second determining module, used to determine the hierarchical architecture of each package path based on all similarities and semantic clustering results; and a third determining module, used to determine the target naming rules based on all hierarchical architectures.

[0092] Optionally, the first determining unit 31 further includes: a first obtaining module, used to obtain multiple metadata of each member function for each member function of each project, and obtain the number of times the member function is called in the project; a first classifying module, used to classify each member function to obtain the member function type of the member function; and a fourth determining module, used to determine structured data for each member function based on all metadata, the number of times it is called, and the member function type.

[0093] Optionally, the metadata includes at least: the member function name, parameter list, parameter types, scope, and classpath of each member function. The first acquisition module includes: a first extraction submodule, used to parse each member function based on the abstract syntax tree and extract the member function name, parameter list, and parameter types; and a first determination submodule, used to determine the scope of each member function and the classpath of each member function, wherein the scope indicates the set of objects accessing the member function, and the classpath indicates the location of the class corresponding to the member function.

[0094] Optionally, the parameter list includes at least: input parameters and output parameters, and the member function also includes at least: code annotations and member function bodies. The first generation unit 32 includes: a fifth determining module, used to determine the parameter states of the input parameters and output parameters based on the code annotations; a second parsing module, used to perform semantic parsing on the member function bodies to obtain the functional description of the member function bodies, wherein the member function bodies are the logical code used to implement the functions of the member functions; and a sixth determining module, used to determine the semantic description based on the parameter states and the functional description.

[0095] Optionally, the device for generating the project constraint document includes: a first judgment module, used to determine whether there is a code segment that calls a member function based on the number of times each member function is called before determining the code segment that calls each member function; and a first construction module, used to construct the code segment that calls the member function based on the parameter list and parameter type of the member function if there is no code segment that calls the member function.

[0096] The aforementioned project constraint document generation device may further include a processor and a memory. The first parsing unit 30, the first determining unit 31, the first generating unit 32, the second generating unit 33, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0097] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and by adjusting kernel parameters, a project constraint document can be generated based on all target configuration information, all target naming rules, all structured data, all semantic descriptions, and all code call templates.

[0098] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0099] It should be noted that the first parsing unit 30, the first determining unit 31, the first generating unit 32, and the second generating unit 33 mentioned above correspond to steps S201 to S204 in Embodiment 1. The instances and application scenarios implemented by the above units and the corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above units can also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0100] Example 3

[0101] Embodiments of this application may provide a computer terminal, which may be any computer terminal device in a group of computer terminals. Optionally, in this embodiment, the aforementioned computer terminal may also be replaced with a mobile terminal or an electronic device, etc.

[0102] Optionally, in this embodiment, the computer terminal may be located in at least one of a plurality of network devices in a computer network.

[0103] In this embodiment, the computer terminal described above can execute the program code for the following steps in the method for generating a project constraint document: parsing the configuration files of multiple projects to obtain target configuration information, and traversing the package path of each project, wherein each package path contains multiple code files, and each code file contains multiple source codes, the source codes including: at least one class, and each class corresponding to at least one member function; determining the target naming rules for each code file based on all package paths, and determining the structured data for each member function; determining the semantic description of each member function, and determining the code snippet that calls each member function, and generating a code call template based on the code snippets; generating a project constraint document based on all target configuration information, all target naming rules, all structured data, all semantic descriptions, and all code call templates.

[0104] Optionally, the aforementioned computer terminal can execute program code for the following steps in the method for generating project constraint documents: parsing the configuration file for each project to obtain multiple project data; using regular expressions to match multiple preset words in the project data and determining the corresponding content for each preset word; and determining the target configuration information based on all project data, all preset words, and all content.

[0105] Optionally, the aforementioned computer terminal can execute program code for the following steps in the method for generating project constraint documents: calculating the similarity between any two package paths using a preset distance algorithm, and clustering the code fragments to obtain semantic clustering results; determining the hierarchical architecture of each package path based on all similarities and semantic clustering results; and determining the target naming rules based on all hierarchical architectures.

[0106] Optionally, the aforementioned computer terminal may execute program code for the following steps in the method for generating project constraint documents: for each member function of each project, obtain multiple metadata of the member function and obtain the number of times the member function is called in the project; classify each member function to obtain the member function type of the member function; for each member function, determine structured data based on all metadata, the number of times it is called, and the member function type.

[0107] Optionally, the aforementioned computer terminal can execute program code for the following steps in the method for generating project constraint documents: based on the abstract syntax tree, parse each member function to extract the member function name, parameter list, and parameter type; determine the scope of each member function and the classpath to which each member function belongs, wherein the scope is used to indicate the set of objects accessing the member function, and the classpath is used to indicate the location of the class corresponding to the member function.

[0108] Optionally, the aforementioned computer terminal can execute program code for the following steps in the method for generating project constraint documents: determining the parameter states of input and output parameters based on code annotations; performing semantic parsing on member function bodies to obtain functional descriptions of member function bodies, wherein the member function body is the logical code used to implement the functions of member functions; and determining semantic descriptions based on parameter states and functional descriptions.

[0109] Optionally, the aforementioned computer terminal can execute program code for the following steps in the method for generating project constraint documents: determining whether there is a code snippet calling a member function based on the number of times each member function is called; and constructing a code snippet calling a member function based on the parameter list and parameter types of the member function if no code snippet calling a member function exists.

[0110] Optionally, Figure 4 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 4 As shown, the electronic device may include: one or more ( Figure 4 (Only one is shown) Processor 402, memory 404, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0111] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the project constraint document generation method and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned project constraint document generation method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0112] The processor can invoke the information and application program stored in the memory through the transmission device to execute the steps described above in the method for generating the project constraint document.

[0113] The embodiments of this application provide a scheme for generating project constraint documents. Through automated code engineering and semantic analysis, it can systematically extract technology stack configuration, modular design specifications, member function metadata and semantic descriptions, and intelligently generate code call templates, thereby realizing the automatic generation and real-time updating of project constraint documents and solving the technical problem of low efficiency in manually writing project constraint documents in related technologies.

[0114] Those skilled in the art will understand that Figure 4 The structure shown is for illustrative purposes only. Electronic devices can also be terminal devices such as smartphones, tablets, PDAs, and mobile internet devices (MIDs). Figure 4 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 4 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 4 The different configurations shown.

[0115] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0116] Example 4

[0117] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the method for generating the project constraint document provided in Embodiment 1.

[0118] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0119] This application also provides a computer program product that, when executed on a data processing device, is adapted to perform the steps of a method for generating a project constraint document.

[0120] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0121] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0122] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0123] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0124] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0125] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0126] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for generating project constraint documents, characterized in that, include: The configuration files of multiple projects are parsed to obtain the target configuration information, and the package path of each project is traversed. Each package path contains multiple code files, and each code file contains multiple source codes. The source code includes at least one class, and each class has at least one member function. Based on all the package paths, determine the target naming rules for each of the code files, and determine the structured data for each of the member functions; Determine the semantic description of each member function and the code snippet that calls each member function; based on the code snippet, generate a code call template. Based on all the target configuration information, all the target naming rules, all the structured data, all the semantic descriptions, and all the code call templates, a project constraint document is generated.

2. The method for generating project constraint documents according to claim 1, characterized in that, The steps to parse configuration files from multiple projects to obtain target configuration information include: The configuration file for each project is parsed to obtain multiple project data. Regular expressions are used to match multiple preset words in the project data and determine the corresponding content for each preset word; The target configuration information is determined based on all the project data, all the preset words, and all the content.

3. The method for generating project constraint documents according to claim 1, characterized in that, The step of determining the target naming rule for each of the code files based on all the package paths includes: A preset distance algorithm is used to calculate the similarity between any two of the packet paths, and the code fragments are clustered to obtain semantic clustering results; Based on all the aforementioned similarities and the semantic clustering results, the hierarchical architecture of each of the package paths is determined; Based on all the aforementioned layered architectures, the target naming rules are determined.

4. The method for generating project constraint documents according to claim 1, characterized in that, The steps for determining the structured data for each member function include: For each member function in each project, obtain multiple metadata of the member function and obtain the number of times the member function is called in the project; Each member function is classified to obtain its member function type. For each member function, the structured data is determined based on all the metadata, the number of times it is called, and the type of the member function.

5. The method for generating project constraint documents according to claim 4, characterized in that, The metadata includes at least: the member function name, parameter list, parameter type, scope, and classpath of each member function. The step of obtaining multiple metadata entries for each member function includes: Based on the abstract syntax tree, each member function is parsed to extract its member function name, parameter list, and parameter type; Determine the scope of each member function and the classpath to which each member function belongs, wherein the scope is used to indicate the set of objects accessing the member function, and the classpath is used to indicate the location of the class corresponding to the member function.

6. The method for generating project constraint documents according to claim 1, characterized in that, The parameter list includes at least: input parameters and output parameters, and the member function further includes at least: code annotations and member function bodies. The step of determining the semantic description of each member function includes: Based on the code annotations, the parameter states of the input parameters and the output parameters are determined; Semantic parsing is performed on the member function body to obtain the functional description of the member function body, wherein the member function body is the logical code used to implement the function of the member function; The semantic description is determined based on the parameter status and the functional description.

7. The method for generating project constraint documents according to claim 1, characterized in that, Before determining the code snippet that calls each of the aforementioned member functions, the following is also included: Based on the number of times each member function is called, determine whether there exists a code segment that calls the member function; In the absence of a code snippet that calls the member function, the code snippet that calls the member function is constructed based on the parameter list and parameter types of the member function.

8. A device for generating project constraint documents, characterized in that, include: The first parsing unit is used to parse the configuration files of multiple projects to obtain target configuration information and traverse the package path of each project. Each package path contains multiple code files, and each code file contains multiple source codes. The source code includes at least one class, and each class has at least one member function. The first determining unit is configured to determine the target naming rules for each of the code files based on all the package paths, and to determine the structured data for each of the member functions; The first generation unit is used to determine the semantic description of each member function, determine the code fragment that calls each member function, and generate a code call template based on the code fragment; The second generation unit is used to generate a project constraint document based on all the target configuration information, all the target naming rules, all the structured data, all the semantic descriptions, and all the code call templates.

9. A computer program product, characterized in that, The method includes a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the method for generating a project constraint document as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method for generating project constraint documents as described in any one of claims 1 to 7.

Images