Design document generation method and electronic device

Abstract

The application discloses a design document generation method and electronic equipment, and relates to the technical field of software engineering, and comprises the following steps: obtaining project source code, and generating a method call link diagram of each to-be-generated document class based on the project source code; analyzing the project source code from leaf nodes of each method call link diagram from bottom to top according to each method call link diagram to obtain function logic information of each to-be-generated document class; analyzing the project source code from top to bottom according to an architecture level of the project source code to obtain business architecture information of each to-be-generated document class; and obtaining design documents of each to-be-generated document class based on the function logic information of each to-be-generated document class and the business architecture information of each to-be-generated document class. The application realizes automatic generation of design documents, solves the problems of low efficiency and high cost of manual writing, and overcomes the defects of shallow code understanding and incomplete document content of existing tools.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and in particular to a design document generation method and an electronic device. Background Technology

[0002] As enterprise application system architectures become increasingly complex, design documents, as a crucial link between code implementation and system architecture, play an irreplaceable role in the software development lifecycle. Currently, the generation of design documents mainly relies on manual writing, which is inefficient and costly, especially in scenarios with large amounts of code. Existing auxiliary tools only understand the superficial structure of the code and lack the ability to deeply analyze the business logic embedded within it, resulting in incomplete documents that fail to meet actual development needs. Therefore, how to automatically extract information from the code and generate complete design documents has become an urgent technical problem to be solved.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a design document generation method, which aims to solve the technical problem that existing technologies cannot automatically extract information from code and generate complete design documents.

[0005] To achieve the above objectives, this application proposes a design document generation method, which includes: Obtain the project source code and generate a method call chain diagram for each document class to be generated based on the project source code; Based on the method call chain diagrams, the source code of the project is analyzed from the leaf nodes of the method call chain diagrams from bottom to top to obtain the functional logic information of each document class to be generated; Analyze the project source code from top to bottom according to the architectural hierarchy to obtain the business architecture information of each document class to be generated; Based on the functional logic information and business architecture information of each document class to be generated, the design document of each document class to be generated is obtained.

[0006] In one embodiment, the step of generating the method call chain diagram for each document class to be generated based on the project source code includes: Based on the project source code, generate the initial method call chain diagram for each document class to be generated; By using preset pruning rules, the initial call path graphs of each method are pruned to obtain the call path graphs of each method. The preset pruning rules include at least one of depth restriction rules and class package restriction rules.

[0007] In one embodiment, the step of generating the initial method call chain graph for each document class to be generated based on the project source code includes: Obtain the document classes to be generated from the project source code, and obtain the dependency classes of each document class to be generated; Based on the dependency relationships between each document class to be generated and the dependent classes, construct each dependency relationship graph; By combining the dependency graphs, the main methods of each document class to be generated are analyzed to obtain the initial method call chain graph of each document class to be generated.

[0008] In one embodiment, the depth restriction rule includes a depth threshold, and the package restriction rule includes a list of allowed packages; The step of pruning the initial call graph of each method using preset pruning rules to obtain the call graph of each method includes: For each target initial link graph in the method call initial link graph, traverse each call node in the target initial link graph. When the call depth of the call node is greater than the depth threshold, the call node is removed as a target node. And / or, when the call node is not in the allowed package list, the call node is removed as a target node. Remove the target removal node and its downstream calling nodes to obtain the method call chain graph.

[0009] In one embodiment, the project source code includes the method code of each node in the method call chain diagram; The step of analyzing the project source code from the leaf nodes of each method call chain graph from bottom to top to obtain the functional logic information of each document class to be generated includes: By analyzing the large model and the lower-level functional logic information of the nodes using the preset first code, the method code corresponding to the current node of each of the method call chain graphs is analyzed to generate the local functional logic information of the current node. The initial lower-level functional logic information of the node is empty, and the initial current node is the leaf node of each of the method call chain graphs. The upstream node of the current node is taken as the new current node, and the lower-level functional logic information of the new node is determined based on the local functional logic information. Based on the new current node and the new node's lower-level functional logic information, the process returns to the step of analyzing the method code corresponding to the current node of each method call chain graph by analyzing the large model and the node's lower-level functional logic information through the preset first code analysis, generating the local functional logic information of the current node, until the preset generation condition is met, and the local functional logic information of the current node when the preset generation condition is met is used as the functional logic information of each document class to be generated.

[0010] In one embodiment, the step of analyzing the project source code from top to bottom according to the architectural hierarchy of the project source code to obtain the business architecture information of each document class to be generated includes: The pre-defined second code analysis model analyzes the project source code from top to bottom according to the architectural hierarchy of the project source code, namely the service layer, data transmission layer, business management layer, and data access layer, to obtain the code business architecture information of each document class to be generated. Based on the code business architecture information, the business architecture information is obtained.

[0011] In one embodiment, the step of obtaining the business architecture information based on the code business architecture information includes: Obtain information about each module of the project source code, including package path prefix, module responsibility, and scenario description; The module information is input into the second code analysis model, which is then instructed to associate each document class to be generated with the module information based on the package path prefix. The model then supplements the code business architecture information by combining the module responsibilities and the scenario description, thereby obtaining the business architecture information of each document class to be generated.

[0012] In one embodiment, the step of obtaining the design document for each document class to be generated based on the functional logic information and business architecture information of each document class to be generated includes: The pre-defined document generation model combines the functional logic information and business architecture information of each document class to be generated, and generates design documents for each document class according to the pre-defined document structure. The pre-defined document structure includes a functional description part, an architecture description part, and a fusion description part generated based on the functional logic information and the business architecture information.

[0013] In one embodiment, after the step of obtaining the design document for each document class to be generated based on the functional logic information and business architecture information of each document class to be generated, the method further includes: When a change is detected in the project source code, the changed files are identified in the changed project source code; Based on the change file and the dependency graph, identify the change class; Update the design document for the aforementioned change class.

[0014] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the design document generation method as described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: In this embodiment, the project source code is first obtained and a method call chain diagram of each document class to be generated is generated. This allows the scattered method call relationships in the code to be presented in a structured way, providing a data foundation for subsequent analysis. Next, based on each method call chain diagram, the project source code is analyzed from the leaf nodes of each method call chain diagram from bottom to top. This allows for analysis from the bottom-level methods and layer by layer upwards, enabling the analysis of upper-level methods to be based on the clearly defined functional semantics of lower-level methods. This yields the functional logic information of each document class to be generated, ensuring the accuracy and completeness of the functional logic information. Then, the project source code is analyzed from top to bottom according to the architectural hierarchy. That is, starting from the overall architecture of the project source code, the analysis is performed layer by layer from top to bottom according to the architectural hierarchy, thereby determining the business architecture information of each document class to be generated at the architectural level. Finally, the design document is generated based on the fusion of functional logic information and business architecture information.

[0016] This embodiment combines bottom-up functional logic extraction with top-down business architecture supplementation, enabling the analysis results of lower-level methods to provide a basis for the analysis of upper-level methods. At the same time, it determines the business positioning of each document class to be generated layer by layer from the perspective of the overall architecture. The integration of the two ensures that the generated design document has both method-level functional descriptions and architecture-level business descriptions. This not only solves the problems of low efficiency and high cost of manual writing, but also overcomes the shortcomings of existing tools in terms of shallow code understanding and incomplete document content, providing reliable technical support for software development and maintenance. Attached Figure Description

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

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

[0019] Figure 1 This is a flowchart illustrating the first embodiment of the document generation method for this application. Figure 2 A flowchart illustrating the process of obtaining the dependency classes of the document class to be generated for this application; Figure 3 A schematic diagram illustrating the process of invoking the initial link graph pruning in this application; Figure 4 A schematic diagram of the overall processing flow of the document generation method for this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the design document generation method in this application embodiment.

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

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

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

[0023] In the current field of software development and IT (Information Technology) operations, design documents are the key link between code implementation and system architecture. Traditional document generation and maintenance mainly rely on the following modes: (1) Manual writing mode: The design documents are manually written by developers or technical documentation engineers based on the code logic. Although this method can ensure a certain degree of accuracy, it relies heavily on personal experience and is inefficient. (2) Static code analysis tools: Static analysis tools are used to extract code structure and generate documents. Although this method is fast, the generated documents often lack in-depth interpretation of business logic, have fixed formats, and are difficult to meet the requirements for generating high-quality design documents. (3) Preparation of existing vertical domain large model corpus: When training a vertical domain large model, it is usually necessary to extract code and design documents from historical projects as corpus. However, this process relies heavily on manual data cleaning, format unification, and standardization.

[0024] With the widespread application of vertical domain large models in the field of software development, the requirements for the standardization of training corpora are increasing. Vertical domain large models, such as code generation models, technical document understanding models, business expert models, etc., require their training corpora to meet the following format specifications: (1) Structured knowledge representation: The corpus should adopt a structured format (such as JSON (JavaScript Object Notation), Markdown, XML (Extensible Markup Language), etc.), containing clear field definitions, such as module name, function description, interface definition, parameter description, return value description, dependency relationship, etc., rather than pure text natural language description. (2) Code-document alignment: The corpus should establish a precise mapping relationship between code implementation and design document. Each code module corresponds to a design document, and each functional point in the document can be traced back to the specific code implementation location (class name, method name, line number). (3) Business logic explicit: The corpus should explicitly express the implicit business logic in the code, including business scenarios, business rules, exception handling logic, data flow path, etc., so that the model can understand the business meaning behind the code. (4) Unified terminology system: The corpus should use unified technical and business terms to avoid the mixing of synonyms and ensure that the model learns consistent concept representations.

[0025] In addition, the quality of the corpus is also a key factor in ensuring the training effect of large-scale models in vertical domains. The corpus quality should meet the following requirements: (1) Accuracy: The content of the document must be completely consistent with the code implementation, and there should be no contradictions or outdated descriptions. (2) Completeness: Each code module should have a corresponding design document, which should cover all functional points, interfaces, dependencies, etc. of the module. (3) Consistency: The document format, expression style, and terminology of different modules should be consistent to avoid quality fluctuations caused by manual writing. (4) Timeliness: The document should be updated in a timely manner to keep pace with the evolution of the code and avoid the disconnect between the existing document and the actual code.

[0026] However, both traditional manual coding methods, documents generated by static code analysis tools, and corpora prepared for large-scale vertical domain models have significant limitations: manual coding is inefficient and suffers from significant quality fluctuations; static code analysis tools lack a deep understanding of business semantics, resulting in documents with fixed formats and incomplete content; and the preparation of corpora for existing large-scale vertical domain models heavily relies on manual processing, making it difficult to generate standardized, structured corpora on a large scale and automatically. Therefore, there is an urgent need for a technical solution that can automatically extract business logic from code and generate standardized, structured design documents.

[0027] Based on this, embodiments of this application provide a design document generation method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the document generation method for this application.

[0028] In this embodiment, the design document generation method includes steps S1 to S4: Step S1: Obtain the project source code and generate a method call chain diagram for each document class to be generated based on the project source code; It should be noted that the class to be generated can be any class in the project source code, or it can be a class in the project source code that carries the core business logic. For example, in an enterprise Java application, the Service layer is responsible for carrying the core business logic and is the bridge connecting the Controller layer (receiving requests) and the DAO (Data Access Object) layer (data access). The preferred class to be generated is a service class, i.e., a service class, because the service class implements specific business functions and can serve as the main object for generating the design document.

[0029] Additionally, it should be noted that the method call chain graph can be a directed graph constructed with methods as nodes and the call relationships between methods as edges. It is used to describe the call hierarchy and call order between the methods involved in the execution of the main method of the document class to be generated. Each method includes the methods in the document class to be generated as well as the methods in other classes called by the document class to be generated.

[0030] Step S2: Based on the method call chain diagrams, analyze the project source code from the leaf nodes of each method call chain diagram from bottom to top to obtain the functional logic information of each document class to be generated; It should be noted that functional logic information can be information describing the business functions and execution logic of methods in the class to be generated. This can include at least one of the following: method function description, input / output description, core logic description, and exception handling description. Understandably, functional logic information enables the design document to reflect the business meaning of the code, allowing readers to understand the key aspects of each method's function, input / output, core logic, and exception handling without reading the code, thus preventing the design document from remaining at a superficial description of the code structure.

[0031] Additionally, it should be noted that leaf nodes can be method nodes in the method call chain graph that do not call other methods downwards. Bottom-up analysis can be performed from the leaf nodes of the method call chain graph towards the root node. That is, it first analyzes the lowest-level methods in the call chain, and then analyzes the upper-level methods layer by layer upwards. This allows the analysis of upper-level methods to be based on the clearly defined functional semantics of the lower-level methods, thereby improving the accuracy of the analysis.

[0032] For example, the method call chain diagram of OrderService is: createOrder() → getUserInfo() and createOrder() → checkStock(), where getUserInfo() and checkStock() are leaf nodes. The main model first analyzes getUserInfo() and checkStock(), generating functional descriptions of "querying user information based on user ID (Identifier)" and "querying inventory information based on product ID" respectively; then it analyzes createOrder(), based on the generated leaf node functional descriptions, to understand that the business logic of createOrder() is to first verify user information, then verify inventory, and finally generate and save the order, generating a functional description of "verifying user information, verifying inventory, and then creating an order", and using this description as the functional logic information of OrderService.

[0033] Step S3: Analyze the project source code from top to bottom according to the architectural hierarchy of the project source code to obtain the business architecture information of each document class to be generated; It should be noted that the architecture layer can be the hierarchical structure of code in the project's source code. For example, in enterprise-level Java applications, the architecture layer can include the service layer, data transmission layer, business management layer, data access layer, etc.

[0034] Additionally, it should be noted that the business architecture information can be the positioning and business context information of the document class to be generated at the architecture level, which may include the business scenario, functional positioning, role and responsibilities of the document class to be generated at each architecture level.

[0035] Additionally, it's important to note that top-down analysis can start with the overall architecture of the project's source code, proceeding from top to bottom and from the whole to the parts, to determine the position and responsibility of each document class to be generated within the overall architecture. In essence, through top-down analysis, the architectural description of the document classes to be generated can be gradually refined from a macro-level business positioning to micro-level responsibilities at each layer, forming a complete architectural view.

[0036] Step S4: Based on the functional logic information and business architecture information of each document class to be generated, obtain the design document for each document class to be generated.

[0037] It's important to note that a design document can be a structured document generated for a single document class to be generated, describing complete knowledge information about that class from its functionality to its architecture. It's crucial to understand that a design document is not simply a combination of functional logic information and business architecture information. Functional logic information describes the function and execution logic of each method in the document class, while business architecture information describes the document class's positioning and business context at the architectural level. The design document organically integrates these two aspects, forming a multi-layered description of the document class from its macro-level business positioning to its micro-level method implementations, while simultaneously establishing the relationship between method functionality and business scenarios.

[0038] In this embodiment, the project source code is first obtained and a method call chain diagram for each document class to be generated is generated, so that the scattered method call relationships in the code can be presented in a structured way. Then, the project source code is analyzed from bottom to top from the leaf nodes of each method call chain diagram, starting from the bottom-level methods and proceeding layer by layer upwards, so that the analysis of the upper-level methods can be based on the clearly defined functional semantics of the lower-level methods, ensuring the accuracy and completeness of the functional logic information. Then, the project source code is analyzed from top to bottom according to the architectural hierarchy, and the positioning and responsibility of each document class to be generated in each architectural layer are determined from the overall architecture, so that the business architecture information has a complete architectural view. Finally, the design document is generated by integrating the functional logic information and the business architecture information, so that the design document has both method-level functional descriptions and architecture-level responsibility descriptions, thereby realizing the automated generation of design documents. This effectively solves the problems of low efficiency and high cost of manual writing, as well as the shallow understanding of code and incomplete document content of existing tools, ensuring the completeness of the design document and its business expression capabilities.

[0039] In one feasible implementation, step S1, which generates the method call chain diagrams for each document class to be generated based on the project source code, includes steps S11 to S12: Step S11: Based on the project source code, generate the initial call chain diagram of each method of each document class to be generated; It should be noted that the initial method call chain diagram can be a complete method call chain diagram obtained directly by parsing the project's source code. The initial method call chain diagram contains the complete call relationships between all methods in the class to be generated, including calls to other classes within the project, calls to third-party dependency libraries, and calls to the Java standard library, etc.

[0040] Step S12: Prune the initial call path graph of each method using preset pruning rules to obtain the call path graph of each method. The preset pruning rules include at least one of depth restriction rules and class package restriction rules.

[0041] It's important to note that pruning refers to removing nodes and their downstream nodes from the initial method call chain graph that do not conform to preset rules. This reduces subsequent processing and the amount of information input into a large model. Understandably, a complete initial method call chain graph often contains a large amount of call information related to technical frameworks and third-party libraries. This information doesn't directly help in understanding the business logic and instead increases the contextual burden on the large model. Through pruning, the size of the call chain graph can be significantly reduced while preserving the core business call relationships.

[0042] Additionally, it should be noted that the preset pruning rules are a set of rules used to identify and remove redundant nodes from the initial method call chain graph; the depth restriction rules are rules that limit the depth of the call chain vertically based on the call depth; and the package restriction rules are rules that limit the scope of the call horizontally based on the package path to which the class belongs. These two types of rules can prune the call chain graph from different dimensions.

[0043] In this embodiment, by generating an initial call chain graph and pruning it based on preset pruning rules, the size of the call chain graph can be significantly reduced while preserving the core business call relationships. This reduces the amount of data processed by the subsequent large model, thereby saving token consumption. At the same time, it avoids a large amount of redundant information related to technical frameworks and third-party libraries from interfering with the semantic understanding of the large model, thus improving the accuracy of analysis.

[0044] In one feasible implementation, step S11: generating the initial method call chain diagram for each document class to be generated based on the project source code may include steps S111~S113: Step S111: Obtain the document classes to be generated from the project source code, and obtain the dependency classes of the document classes to be generated; It should be noted that dependency classes refer to other classes that the document class to be generated depends on in its code implementation. This includes classes that the document class to be generated directly references through import statements, as well as other classes that are further referenced by these directly dependent classes. Dependency classes record information about external types referenced by the document class to be generated in its code implementation and are the basic data for building class-level dependency graphs.

[0045] As an example, one way to obtain the class to be generated documentation is as follows: After obtaining the project source code, identify all service classes (such as classes whose names contain "Service") from the project source code using regular expression matching, and use these as the class to be generated documentation. Another way to obtain the dependent classes of the class to be generated documentation is: parse the import statements of each class to be generated documentation, extract the classes that the class directly depends on from the import statements, filter out the direct dependent classes of interest using regular expressions, and then recursively perform the same parsing operation on the direct dependent classes of interest until no new dependent classes are found. See also Figure 2 , Figure 2 The process of obtaining the dependent classes of the document class to be generated is illustrated as follows: First, the import statement of the document class to be generated is obtained. Other classes that the document class directly depends on are extracted from the import statement, resulting in a list of dependent classes. Then, it is determined whether the list of dependent classes is empty: if it is empty, the recursion terminates, and the obtained dependent class information is returned; if it is not empty, each dependent class in the list is traversed, and the same parsing operation is performed on that class, parsing the import statement in that class, obtaining the other classes that the class depends on, and adding them to the dependent class list. This process is repeated until a certain level of dependent classes no longer contains new dependent classes (i.e., there are no other new classes to parse in the import statement), at which point the recursion terminates and returns. Through the above recursive parsing process, all direct dependent classes of the document class to be generated, as well as multi-level indirect dependent classes, can be obtained, forming a complete set of dependency class information, providing a data foundation for subsequently constructing a dependency graph containing complete transitive dependencies.

[0046] As another example, dependency classes can also be obtained by parsing class reference information in the constant pool from the compiled class files through bytecode analysis; or by parsing configuration files to extract project dependencies from dependency management files (such as Maven's pom.xml) and combining this with usage in the code to determine the dependency classes. Those skilled in the art can choose the appropriate method to obtain the document class to be generated and its dependency classes according to the actual project situation and analysis needs, and no restrictions are imposed here.

[0047] Step S112: Construct dependency graphs based on the dependency relationships between each document class to be generated and the dependent classes; Optionally, a directed graph structure is constructed using each document class to be generated and its dependent classes as nodes, with directed edges from the document class to the dependent class indicating that the document class to be generated depends on the dependent class, or with directed edges from the dependent class to the document class indicating that the document class to be generated depends on the dependent class, to obtain the dependency relationship graph.

[0048] As an example, in each dependency graph, each class node records its full classpath and abbreviated name, and each directed edge records the reference relationship between the document class to be generated and its dependent classes. When the document class to be generated imports a dependent class through an import statement, the abbreviated name and full classpath of that dependent class are recorded in the dependency graph. For example, assuming that the import statement of the document class OrderService to be generated contains import com.example.service.UserService, the dependency graph records the nodes OrderService and com.example.service.UserService, establishes a directed edge from OrderService to com.example.service.UserService, and records the full classpath com.example.service.UserService corresponding to the abbreviated name UserService.

[0049] Step S113: Combining the dependency graphs, analyze the main methods of each document class to be generated to obtain the initial method call chain graph of each document class to be generated.

[0050] It should be noted that the main method can refer to the entry method in the document class to be generated that carries the core business logic. The main method is usually the main descriptive object for designing document generation.

[0051] As an example, the Abstract Syntax Tree (AST) method can be used to analyze each method node and its called lower-level methods layer by layer, starting from the main method of the document class to be generated, to obtain the initial method call chain diagram of each document class to be generated.

[0052] Furthermore, by analyzing the main method of the document class to be generated using a dependency graph, the following aspects are identified: First, the scope of the abstract syntax tree (AST) analysis is determined based on the dependency graph. AST analysis is then performed on the document class to be generated and its dependent classes to generate a method call path graph. It is understood that the dependency graph is used to determine the scope of AST analysis. The method call path graph is not generated in isolation. When a method in one document class calls a method in another class, the internal method structure of the called class needs to be known to generate a complete call path graph. The dependency graph records complete information about the document class to be generated and all its direct and indirect dependent classes through recursive parsing. The AST analysis system can determine the scope of analysis based on the dependency graph; that is, it must analyze not only the document class itself but also its dependent classes to generate an initial method call path graph containing the complete call path.

[0053] Secondly, based on the mapping relationship between abbreviated names and full class paths recorded in the dependency graph, the abbreviated names in the method call statements are replaced with the full class paths. That is, when performing Abstract Syntax Tree (AST) analysis on the main method of the class to be generated, the mapping relationship between abbreviated names and full class paths recorded in the dependency graph is used to replace the abbreviated names of the called objects in the method call statements with the full class paths. Specifically, AST analysis can parse the internal implementation of each method in the class to be generated, identify each method call statement in the method body, and when a method call statement is parsed, the dependency graph is queried to obtain the full class path corresponding to the abbreviated name, thereby generating a call chain graph containing full class path information. For example, suppose there is a method call statement `userService.getUserInfo()` in the `createOrder` method of `OrderService`. During AST analysis, the abbreviated name of the called object is parsed as `userService`, and the method name is `getUserInfo`. At this time, querying the dependency graph, the corresponding full class path is found to be `com.example.service.UserService`, and the call statement is parsed as `com.example.service.UserService.getUserInfo()`. After traversing all the call statements in the createOrder method, an initial method call chain diagram containing the complete class path is generated. This clearly distinguishes the call relationship between methods with the same name in different classes, and avoids incomplete call chain diagram information due to the inability to determine the class to which the called object belongs because of the abbreviated name. This ensures that the initial method call chain diagram can be accurately understood by subsequent analysis.

[0054] Understandably, dependency graphs and method call initialization graphs describe code structure information from two different dimensions. Dependency graphs describe static dependencies at the class level, recording the reference structure between the class to be generated and its dependent classes; method call initialization graphs describe dynamic call relationships at the method level, recording the call hierarchy and order between methods. They complement each other: dependency graphs provide dependency scope information at the class level, while method call initialization graphs provide execution path information at the method level. Their combination provides complete information support from the class level to the method level for subsequent analysis, enabling understanding both the dependency structure between classes and the call logic between methods.

[0055] In this embodiment, by obtaining the document class to be generated and its dependent classes at all levels and constructing a dependency graph, the scope of subsequent analysis can be narrowed, reducing the amount of data input to the large model and thus saving processing resources. Simultaneously, the dependency graph records the reference relationships between classes and the mapping relationship between abbreviated names and full class paths. During AST analysis, the dependency graph is used to determine the analysis scope, and the abbreviated names in method call statements are replaced with full class paths. This ensures that each call node in the generated call chain graph is identified by the called method in the form of "full class path.method name," clearly distinguishing the call relationships between methods with the same name in different classes. This avoids incomplete call chain graph information due to the inability to determine the class of the called object from the abbreviated name, ensuring that the call chain graph can be accurately understood by subsequent analysis.

[0056] In one feasible implementation, the depth restriction rule includes a depth threshold, and the package restriction rule includes a list of allowed packages; Step S12: Pruning the initial call path graph of each method according to preset pruning rules to obtain the call path graph of each method may also include steps S121~S122: Step S121: For each target initial link graph in the method call initial link graph, traverse each call node in the target initial link graph. When the call depth of the call node is greater than the depth threshold, the call node is removed as a target node. And / or, when the call node is not in the allowed package list, the call node is removed as a target node. It should be noted that the target initial call chain graph can be each individual method call initial call chain graph within the various method call initial call chain graphs, that is, the initial method call chain graph generated for a single document class to be generated. A call node can refer to a node in the method call initial call chain graph, with each call node corresponding to a method call. A target removal node can refer to a call node that is determined to need to be removed.

[0057] Additionally, it should be noted that call depth can refer to the number of call levels from the root node of the target initial call chain (i.e., the main method of the document class to be generated) to the current call node. For example, when the call depth is greater than a preset depth threshold, it indicates that the node is at a deeper level in the call chain and belongs to the technical implementation details level of the call. Removing this node and its downstream call nodes can effectively reduce the size of the call chain graph while retaining the core business logic.

[0058] Additionally, it should be noted that the allowed package list can refer to a predefined set of package paths that are allowed to be retained, used to limit the range of class package paths that are allowed to be retained in the call chain graph. Understandably, by judging based on the allowed package list, if the package path of the class containing the calling node is in the allowed package list, the node is retained; if the package path of the class containing the calling node is not in the allowed package list, the node is removed. Furthermore, the allowed package list can be flexibly configured using wildcard matching, for example, com.example. Matches all sub-packages under this package.

[0059] Additionally, it should be noted that depth restriction rules and package restriction rules can be executed individually or in combination. Understandably, through combined pruning of depth restriction rules and package restriction rules, depth restriction rules remove excessively deep technical implementation details from the vertical dimension, while package restriction rules filter calls outside the core business package path from the horizontal dimension. The combination of the two can prune the call chain graph from two dimensions, minimizing the amount of data processed subsequently while preserving the integrity of core business call relationships, and avoiding redundant information from interfering with the accuracy of analysis. See also Figure 3 , Figure 3 The process of pruning the initial method call path graph is illustrated as follows: First, the main method of the class to be generated (i.e., the Service main method) is input, and the code is parsed using AST to obtain the initial method call path graph (methodDependentMap) corresponding to the main method of the class to be generated. This graph is a complete method call path graph containing all call levels and call relationships. Then, each method node in the initial method call path graph (methodDependentMap) is traversed, and two dimensions are judged for each method node in turn: First, it is judged whether the call depth of the method is greater than the preset maximum call depth threshold (maxMethodDependentDepth). If so, the method and its downstream call nodes are determined to be redundant nodes and are pruned and removed; otherwise, the second judgment is performed. Second, it is judged whether the package path of the class containing the method is in the preset package path whitelist (projectPackageList). If not, the method and its downstream call nodes are determined to be external dependencies and are pruned and removed; if so, the method node is retained and added to the optimized method call path graph (pruneServiceMethodMap). This process is repeated until all method nodes in the initial method call chain graph (methodDependentMap) have been processed, and finally the pruned and optimized method call chain graph (pruneServiceMethodMap) is output.

[0060] In this embodiment, precise pruning is achieved through depth thresholds and allowed package lists. Depth restriction rules remove technical implementation details with excessively deep call layers from the vertical dimension, while package restriction rules filter out external calls such as third-party dependency libraries and Java standard libraries from the horizontal dimension. The combination of the two can prune the call chain graph from both vertical and horizontal dimensions. While ensuring the integrity of core business call relationships, it maximizes the compression of the data volume of the input large model, saves token consumption, and avoids redundant information from interfering with the semantic understanding of the large model, thereby improving the accuracy of analysis.

[0061] In one feasible implementation, after obtaining the design documents for each document class to be generated based on the functional logic information and business architecture information of each document class to be generated, step S41-S43 are further included: Step S41: When a change is detected in the project source code, identify the changed files in the changed project source code; It should be noted that change files refer to code files whose content or structure has changed compared to the last processing, including newly added files, modified files, and deleted files. These files are the original basis for further analysis to determine whether they affect existing design documents.

[0062] Specifically, the project source code directory can be scanned at preset intervals (e.g., daily) using a timed scanning method. The currently scanned file list is compared with the previous scan record to identify newly added, modified, or deleted code files, which are then designated as changed files. For example, the current file status is compared with the file status recorded during the last scan, or the file's hash value is calculated and compared with the hash value recorded in the previous scan. When the hash value changes, it is determined that the file has been changed.

[0063] Step S42: Based on the change file and the dependency graph, identify the change class; It should be noted that the "change class" refers to the class of documents to be generated that are affected by changes in the documents and require the design documents to be regenerated.

[0064] Specifically, first, it is determined whether the modified file itself is the document class to be generated: if so, the document class to be generated is directly identified as the modified class. Then, based on the reference relationships between the document class to be generated and its dependent classes recorded in the dependency graph, all document classes to be generated that directly or indirectly depend on the class corresponding to the modified file are found and identified as modified classes as well.

[0065] For example, suppose the UserService class changes, and the dependency graph shows that OrderService depends on UserService. In this case, OrderService is also affected by the change and needs to be updated as well. Using the above method, all affected classes can be accurately identified.

[0066] Step S43: Update the design document for the change class.

[0067] Specifically, steps S1 to S4 are re-executed for the change class to generate a new design document for that change class, replacing the original design document.

[0068] In this embodiment, incremental updates to the design document are achieved by detecting code changes and accurately locating affected classes using a dependency graph. In scenarios with frequent code iterations, compared to regenerating all design documents after each change or manually checking the scope of changes one by one, this embodiment only requires regenerating documents for the classes affected by the changes, significantly reducing the computational resources and time costs required for document updates, while ensuring that the design document always remains consistent with the code.

[0069] In one feasible implementation, the project source code includes the method code of each node in the method call chain diagram; Step S2: Based on the method call chain diagrams, analyze the project source code from the leaf nodes of each method call chain diagram from bottom to top to obtain the functional logic information of each document class to be generated. This also includes steps S21-S23: Step S21: Analyze the method code corresponding to the current node of each method call link graph by using the preset first code analysis large model and node lower-level functional logic information, and generate the local functional logic information of the current node. The initial node lower-level functional logic information is empty, and the initial current node is the leaf node of each method call link graph. It should be noted that the first code analysis large model refers to a large language model with code understanding and natural language generation capabilities. This means that by inputting the method call chain diagram into the large model, the model executes code analysis tasks according to prompts, leveraging its semantic understanding capabilities to extract business function-level information from the code, rather than merely focusing on the code structure level.

[0070] Additionally, it should be noted that leaf nodes are method nodes in the method call chain graph that do not call other methods downwards. For example, leaf nodes are typically the lowest-level methods in the call chain, such as DAO methods that directly manipulate the database or methods that call external interfaces.

[0071] Additionally, it should be noted that the local functional logic information of the current node refers to the functional logic information of the method code corresponding to the current node, which describes the function, input and output, core logic, and exception handling of the method.

[0072] Additionally, it should be noted that the lower-level functional logic information of a node is information passed from the lower-level nodes of the current node to the current node, serving as the basis for analyzing the current node's method code. In one implementation, the lower-level functional logic information can be the functional logic information of the current node's direct lower-level nodes; in another implementation, the lower-level functional logic information can be the aggregated result of the functional logic information of all lower-level nodes of the current node (including direct lower-level nodes and nodes further down to the leaf nodes). Initially, the current node is a leaf node and has no lower-level nodes, therefore the lower-level functional logic information is empty.

[0073] Step S22: Take the upstream node of the current node as the new current node, and determine the new node's lower-level functional logic information based on the local functional logic information; As an example, the local functional logic information of the current node can be used as the lower-level functional logic information of the new node.

[0074] As another example, the functional logic information of all lower-level nodes of the new current node can be combined as the lower-level functional logic information. Furthermore, when the depth of the method call chain graph exceeds a preset depth value and / or the context space occupancy of the first code analysis model exceeds a preset threshold, the functional logic information of all lower-level nodes of the new current node is merged or summarized, and the merged or summarized functional logic information is used as the analysis context of the corresponding method of the new current node, i.e., as the lower-level functional logic information of the node. It is understandable that when the method call chain graph is deep and there are many lower-level method nodes, passing the functional logic information of all lower-level methods upwards layer by layer may lead to excessive context occupancy during the analysis of upper-level methods. By merging or summarizing the functional logic information of multiple lower-level methods and using it as the analysis context of the upper-level method or directly as the functional logic information of the document class to be generated, the amount of information can be further compressed, token consumption can be saved, and key information of the core business logic can be retained, avoiding analysis interruption or information loss due to context overflow.

[0075] Step S23: Based on the new current node and the new node's lower-level functional logic information, return to the step of analyzing the method code corresponding to the current node of each method call chain graph by analyzing the large model and the node's lower-level functional logic information through the preset first code analysis, and generating the local functional logic information of the current node, until the preset generation condition is reached, and use the local functional logic information of the current node when the preset generation condition is reached as the functional logic information of each document class to be generated.

[0076] It should be noted that the preset generation condition refers to the termination condition of the bottom-up analysis. For example, when the current node has no upstream node (i.e., the current node is the top-level node in the method call chain graph), the preset generation condition is met, and the iteration terminates. It can be understood that by iteratively executing the above steps, we can analyze each method node layer by layer upwards from the leaf nodes until we reach the top-level node. By iteratively executing these steps, the analysis results of each layer of methods can be passed upwards layer by layer, allowing the analysis of upper-level methods to be based on the already defined functional semantics of lower-level methods. Ultimately, the functional logic information of the top-level node integrates the functional semantics of all lower-level nodes.

[0077] For example, suppose the method call chain diagram of OrderService is: createOrder() → getUserInfo() and createOrder() → checkStock(), where getUserInfo() and checkStock() are both leaf nodes. The main model first analyzes getUserInfo() and checkStock(), generating local functional logic information for "querying user information by user ID" and "querying inventory information by product ID" respectively, as lower-level functional logic information; then it analyzes createOrder(), and based on the lower-level functional logic information, it understands that the business logic of createOrder() is to first verify user information, then verify inventory, and finally generate and save the order, generating local functional logic information for "verifying user information, verifying inventory, and then creating the order". At this point, createOrder() has no upstream node, the preset generation conditions are met, the iteration terminates, and this local functional logic information is used as the functional logic information of OrderService.

[0078] It should be noted that preset prompts can be used to instruct the large-scale code analysis model. For example, preset prompts might include: Analysis Specification: Follow the input method call chain diagram and conduct code logic analysis from bottom to top. The analysis results of each node are summarized before being passed to the next higher-level node. In essence, by issuing bottom-up analysis instructions to the large-scale model through preset prompts, the model only needs to focus on the call relationships of the current layer's methods and the functional logic information of their dependent lower-level methods when analyzing each layer. This avoids information loss or erroneous inferences caused by excessively long context when directly analyzing the complete call chain, effectively reducing the cognitive burden on the large-scale model when processing complex code and improving the accuracy and reliability of the analysis.

[0079] In this embodiment, a bottom-up analysis command is issued to the large model through preset prompt words, enabling the large model to analyze layer by layer from the leaf nodes. When analyzing each layer, it is based on the generated lower-level functional logic information, avoiding information loss or incorrect inference caused by excessively long context when directly analyzing the complete call chain. At the same time, by iteratively executing the steps of "generating local functional logic information → obtaining the lower-level functional logic information of the node → combining the lower-level functional logic information of the node to analyze the upper-level node", the analysis results of the lower-level methods are passed up layer by layer, ensuring that the functional logic information of the top-level node integrates the functional semantics of all lower-level nodes, effectively improving the accuracy and reliability of the large model in processing complex call chains.

[0080] In a feasible implementation, step S3: analyzing the project source code from top to bottom according to the architectural hierarchy of the project source code to obtain the business architecture information of each document class to be generated may further include steps S31~S32: Step S31: Instruct the preset second code analysis model to analyze the project source code from top to bottom according to the architectural hierarchy of the project source code, namely the service layer, data transmission layer, business management layer, and data access layer, to obtain the code business architecture information of each document class to be generated; It should be noted that the second code analysis model refers to a large language model with code understanding and natural language generation capabilities. This second code analysis model can be the same as the first code analysis model, or it can be a separately deployed model. For example, the analysis first examines the business functions undertaken by each document class to be generated in the service layer, then analyzes the data structures involved in the data transmission layer, then analyzes the general business processing capabilities relied upon by the business management layer, and finally analyzes the data persistence operations involved in the data access layer. Code business architecture information can refer to the positioning and responsibility information of each document class to be generated at each architectural layer, obtained through analyzing the project source code.

[0081] Specifically, the path to the project source code is input into the preset second code analysis model, and preset prompts instruct the second code analysis model to perform top-down analysis according to the architectural hierarchy. That is, the second code analysis model starts from the overall architecture of the project source code, and analyzes the positioning and responsibility of each document class to be generated in each layer according to the architectural hierarchy of service layer → data transfer layer → business management layer → data access layer, generating the code business architecture information of each document class to be generated. For example, the preset prompts include: Analysis specification: Supplement the logic from top to bottom according to the following class call order: Service → DTO (Data Transfer Object) → Manager → DAO (using MyBatis technology, the XML file in the Mapper directory is bound to the corresponding DAO through namespace).

[0082] Step S32: Obtain the business architecture information based on the code business architecture information.

[0083] Specifically, the code business architecture information can be used as business architecture information.

[0084] In this embodiment, by instructing the large model to analyze the project source code from top to bottom according to the architectural hierarchy of the project source code—service layer, data transmission layer, business management layer, and data access layer—it is possible to determine the position and responsibility of each document class to be generated in each architectural layer from top to bottom, starting from the overall architecture of the project source code. This ensures that the generated code business architecture information has a complete hierarchical view and a description of the responsibilities of each layer. By organizing the code business architecture information into business architecture information, it can be directly used for the generation of subsequent design documents. Compared with directly analyzing fragmented code structures, this embodiment avoids the information fragmentation problem caused by the lack of an overall architectural perspective by performing top-down analysis according to the architectural hierarchy. It enables the business architecture information to completely describe the architectural positioning of each document class to be generated from macro to micro perspectives, providing an architectural-level information foundation for the generation of subsequent design documents.

[0085] In a feasible implementation, step S32: obtaining the business architecture information based on the code business architecture information may further include steps S321-S322: Step S321: Obtain the module information of the project source code, wherein the module information includes package path prefix, module responsibility and scenario description; Step S322: Input the information of each module into the second code analysis big model, instruct the second code analysis big model to associate each document class to be generated with the information of each module according to the package path prefix, and supplement the code business architecture information in combination with the module responsibility and the scenario description to obtain the business architecture information of each document class to be generated.

[0086] In a feasible implementation, step S32: obtaining the business architecture information based on the code business architecture information may further include steps S321-S322: Step S321: Obtain the module information of the project source code, wherein the module information includes package path prefix, module responsibility and scenario description; It should be noted that module information can be structured data describing the division of project modules and their business attributes. Module information can be written manually in advance or automatically generated by the model.

[0087] As an example, module information includes each module's name, responsibility, business scenario description, matching package path prefix, and a list of dependent modules. The package path prefix associates the classes to be generated in the project's source code with the module; that is, if a class's source file package path begins with a module's package path prefix, then that class belongs to that module. The module responsibility describes the module's functional role in the project, and the scenario description explains the specific business requirements supported by the module.

[0088] For example, the module information format is as follows: Module 1: Module name: 01Module, Module responsibility: Used in scenario 01, Business scenario description: To implement the login business requirement, Matching package path prefix: com.module.01, Dependent module list: 02Module, 03Module; Module 2: Module name: 02Module, Module responsibility: Used in scenario 02, Business scenario description: To implement the registration business requirement, Matching package path prefix: com.module.02, Dependent module list: None.

[0089] Step S322: Input the information of each module into the second code analysis big model, instruct the second code analysis big model to associate each document class to be generated with the information of each module according to the package path prefix, and supplement the code business architecture information in combination with the module responsibility and the scenario description to obtain the business architecture information of each document class to be generated.

[0090] Specifically, the module information is input into the second code analysis model, and preset prompts instruct the model to perform the following operations: First, determine the module corresponding to each document class to be generated based on the package path prefix, i.e., determine which module's package path prefix the document class to be generated begins with; if a match is found, the class belongs to that module. Then, supplement the code business architecture information by combining the module's responsibilities and business scenario description, so that the business architecture information includes the business scenario and functional positioning of the module to which the document class to be generated belongs. For example, the preset prompts include: supplement responsibilities and business scenario descriptions based on the input module information.

[0091] For example, assuming the package path of OrderService is com.example.order.OrderService, and the package path prefix of "Order Module" in the module information is com.example.order, then OrderService belongs to the Order module by matching the package path prefix. The large model obtains the module responsibility (responsible for the entire lifecycle management of orders) and scenario description (providing users with functions such as placing orders, querying orders, and updating order status), and supplements the above information into the code business architecture information of OrderService. This ensures that the business architecture information of OrderService not only includes its role and responsibility in each architectural layer, but also the business scenario and functional positioning of its module.

[0092] In this embodiment, the document class to be generated is associated with the module by the package path prefix in the module information, so that the module responsibilities and business scenario descriptions become the business context of the document class to be generated. The code business architecture information is supplemented by the module responsibilities and scenario descriptions, so that the business architecture information has business scenarios and functional positioning, providing complete architecture information for the subsequent generation of design documents.

[0093] In a feasible implementation, step S4: obtaining the design document for each document class to be generated based on the functional logic information and business architecture information of each document class to be generated further includes step S41: Step S41: Instruct the preset document generation model to combine the functional logic information and business architecture information of each document class to be generated, and generate the design document for each document class to be generated according to the preset document structure. The preset document structure includes a functional description part, an architecture description part, and a fusion description part generated based on the functional logic information and the business architecture information.

[0094] It should be noted that the document generation large model refers to a large language model with natural language understanding and generation capabilities. The document generation large model can be the same large model as the aforementioned first code analysis large model or second code analysis large model, or it can be a different large model deployed independently. Those skilled in the art can flexibly choose the deployment method according to actual needs.

[0095] Additionally, it should be noted that the preset document structure refers to a predefined organizational framework for design documents, used to standardize the chapter composition and content layout of design documents.

[0096] As an example, the preset document structure can be defined according to the format requirements of the training corpus for a large-scale vertical model, so that the generated design document can be directly used as training corpus. For example, the following sections can be defined in the document structure: Functional Overview (structured knowledge representation of the corresponding corpus), Step-by-Step Explanation of Business Logic (explicit business logic of the corresponding corpus), Field Change Process (description of data flow path of the corresponding corpus), Development Toolkit Method Description (interface definition and parameter description of the corresponding corpus), and Data Persistence Design (description of dependency relationships of the corresponding corpus), so that the generated document meets the corpus's specifications for structured knowledge representation, explicit business logic, and code-document alignment. It is understandable that by aligning the preset document structure with the format requirements of the training corpus for a large-scale vertical model, the design document generated by this solution can be directly used for training the large-scale vertical model without manual format conversion or data cleaning.

[0097] Additionally, it should be noted that the functional description section is generated based on functional logic information and is used to describe the functions and execution logic of each method in the document class to be generated; the architecture description section is generated based on business architecture information and is used to describe the business positioning, module responsibilities, and role and responsibilities of the document class to be generated in each architecture layer; the fusion description section is generated based on the cross-correlation of functional logic information and business architecture information and is used to describe how each method in the document class to be generated supports the business scenario of its module and the collaborative relationship between layers.

[0098] Specifically, preset prompts can be used to instruct the document to generate a large model and then generate a design document according to a preset document structure.

[0099] For example, the preset prompts include sample templates with preset document structures to help users understand the output format of the design document. In the sample template, the function overview section requires a description of the function name, input / output DTOs, and core logic, such as "Query user information based on user ID, input is UserIdRequestDTO, output is UserInfoResponseDTO, the core logic is to query the user table in the database based on user ID and return user information"; the business logic section requires a step-by-step description and explanation of exception handling, such as "Check if user ID is empty, if empty, throw IllegalArgumentException; call UserDao.selectById to query user information, if the query result is empty, throw UserNotFoundException; encapsulate the query result into UserInfoResponseDTO and return it"; the field change section requires a description of the field transition process, such as "userId is used as a query condition after being validated as input and not empty, userName is used as the returned result after being queried from the database from empty"; the SDK method description section... The requirements for the first part describe the input, output, and business logic of the called method, such as "The UserService.getUserInfo method takes userId as input and outputs UserInfoResponseDTO. The logic is to validate the parameters and then call UserDao.selectById to query. If the result is empty, an exception is thrown; otherwise, it is converted to DTO and returned." The persistence design part requires a description of the table structure and cache design, such as "The user_table table has fields including user_id (VARCHAR(32), user ID), user_name (VARCHAR(128), user name), status (TINYINT), create_time (DATETIME), update_time (DATETIME). The cache uses Redis to cache user information, with the key being user_info_{userId} and an expiration time of 30 minutes." Through the above example template, the large model can output design documents according to a unified structure, ensuring consistent document format. It can be understood that by pre-setting the document structure, the design documents of each document class to be generated have a unified format and expression style. The functional description, architecture description, and integration description sections describe the class to be generated from three dimensions: method-level functionality, module-level architecture, and the relationship between the two. This ensures that the design document has both method-level functional details and module-level architectural context, forming a complete knowledge view of the class to be generated.

[0100] It is worth noting that the first code analysis model, the second code analysis model, and the document generation model can all be the same large model, and the design document can be obtained through the following prompts: Please analyze the Java code and generate a detailed design document according to the following specifications. Input Requirements 1. Provide the path to the main project directory. 2. Provide the directory path of the SDK projects that the project depends on (if any). 3. Method call chain diagram 4. Module Information Document Requirements 1. Format: Markdown 2. Naming convention: `[Function Code]_[Function Description]_Detailed Design Document.md`, where the function code comes from the main project service. 3. Structure: Functional Overview (Function Name, Inputs / Outputs, Core Logic) Business logic (describe step by step, including exception handling) Field Change Process (Field Transfer Process) SDK method descriptions (input / output, business logic) Data persistence design (table structure, cache design) Analysis Specification 1. Scan the main project and its dependent SDKs; test classes are not included in the analysis. 2. Following the input method, call the call chain diagram and perform code logic analysis from bottom to top. Summarize the analysis results of each node before passing them to the next higher-level node.

[0101] 3. Then, supplement the logic from top to bottom according to the following class calling order: Service→DTO→Manager→DAO (using MyBatis technology, the XML files in the Mapper directory bind the corresponding DAO via namespaces) Supplement the description of responsibilities and business scenarios based on the input module information. 4. Document Requirements: Ensure all information is derived from analyzing Java code; fabrication is strictly prohibited. Technical details must be complete and not omitted; descriptions must be accurate and logic must be clear. Instead of directly pasting code, I will describe it in natural language. Business logic explained step by step (1, 2, 3.) Field change format: `Field name: [Initial value] → [Process] → [Result]` 5. Special requirements: If there are subclasses, list them and fully demonstrate their specific implementations. Distributed systems need to demonstrate transaction consistency. In high-concurrency scenarios, the locking mechanism needs to be explained. Example template #A-Function Description ###1. Function Overview -Function Name: A - Input: ARequestDTO Output: AResponseDTO -Core Logic: B ###2. Business Logic 1. Step 1 Description Exception handling: AException 2. Step 2 Description ###3. Field Changes 1. field1: [Input] → [Validation] → [Processing] 2. field2: [Empty] → [Calculate] → [Result] ###4. SDK Method Description - CService.method() Input: param1, param2 Output: ResultDTO Logic: 1. Step 1 describes the exception situation: DException handling 2. Step 2 Description ###5. Persistent Design 1. Table 1: Based on the mapping relationship between DAO and mapper XML (through namespace binding in XML). -column1 type description column2 type description In one feasible implementation, the method further includes a logging step: The entire process is logged, including success and failure logs. The success log records information about successfully generated design documents, while the failure log records information about documents that failed to generate design documents and the reasons for the failure. Furthermore, a progress bar can be used to display the processing progress.

[0102] Specifically, for each document class to be generated, after executing steps S1 to S4, depending on whether the design document was successfully generated, the corresponding document class information is recorded in a success log file (e.g., success.log) or a failure log file (e.g., failure.log). The failure log also records the reason for failure (e.g., large model call timeout, code parsing exception, etc.) for subsequent troubleshooting. Optionally, a progress bar tool (e.g., tqdm) can be used to display the overall processing progress during the process.

[0103] Understandably, recording success and failure logs facilitates the rapid identification of document types that failed to generate documents and the reasons for failure in large-scale batch generation scenarios, thereby improving troubleshooting efficiency.

[0104] To more clearly demonstrate the overall process flow of the design document generation method in this application, refer to... Figure 4 , Figure 4 This diagram illustrates the overall processing flow of the document generation method for this application. First, the project source code is processed by a code scanning and parsing module. This module, based on Python, implements file traversal capabilities, traversing all code files starting from the root path of the project source code. It identifies the class to be generated (i.e., the Service class) using regular expression matching, completing the basic data collection for static code analysis. Next, the dependency analysis module recursively analyzes the method call chain of the class to be generated based on the Abstract Syntax Tree (AST), generating an initial method call chain graph (methodDependentMap). It then prunes the call chain using preset pruning rules to obtain an optimized method call chain graph (pruneServiceMethodMap). Simultaneously, the dependency analysis module also organizes the functional logic based on the pruned and optimized call chain graph, obtaining a functional overview and dependency graph. Then, the functional overview and dependency graph are input into an AI (Artificial Intelligence) large-scale model. The large-scale model organizes the functional logic and generates the document content according to a preset document structure, including the functional overview and functional logic sections. Finally, a standardized structured design document (i.e., the design document) is output, completing the automated generation from project source code to design document. The above process automates the entire process of extracting business logic from code and generating structured design documents, effectively solving the problems of low efficiency in manual coding and the lack of business semantic understanding capabilities in existing tools.

[0105] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the method of generating design documents for this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0106] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the design document generation method in Embodiment 1 above.

[0107] The following is for reference. Figure 5 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

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

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

[0110] The electronic device provided in this application, employing the design document generation method described in the above embodiments, can solve the technical problem that existing technologies cannot automatically extract information from code and generate complete design documents. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the design document generation method provided in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

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

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

[0113] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the design document generation method in the above embodiments.

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

[0115] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

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

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

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

[0119] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described design document generation method. This solves the technical problem that existing technologies cannot automatically extract information from code and generate complete design documents. Compared with existing technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the design document generation method provided in the above embodiments, and will not be elaborated upon here.

[0120] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the design document generation method described above.

[0121] The computer program product provided in this application can solve the technical problem that existing technologies cannot automatically extract information from code and generate complete design documents. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the design document generation method provided in the above embodiments, and will not be repeated here.

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

Claims

1. A method for generating design documents, characterized in that, The design document generation method includes: Obtain the project source code and generate a method call chain diagram for each document class to be generated based on the project source code; Based on the method call chain diagrams, the source code of the project is analyzed from the leaf nodes of the method call chain diagrams from bottom to top to obtain the functional logic information of each document class to be generated; Analyze the project source code from top to bottom according to the architectural hierarchy to obtain the business architecture information of each document class to be generated; Based on the functional logic information and business architecture information of each document class to be generated, the design document of each document class to be generated is obtained.

2. The design document generation method as described in claim 1, characterized in that, The steps for generating the method call chain diagram of each document class to be generated based on the project source code include: Based on the project source code, generate the initial method call chain diagram for each document class to be generated; By using preset pruning rules, the initial call path graphs of each method are pruned to obtain the call path graphs of each method. The preset pruning rules include at least one of depth restriction rules and class package restriction rules.

3. The design document generation method as described in claim 2, characterized in that, The steps for generating the initial method call chain diagram for each document class to be generated based on the project source code include: Obtain the document classes to be generated from the project source code, and obtain the dependency classes of each document class to be generated; Based on the dependency relationships between each document class to be generated and the dependent classes, construct each dependency relationship graph; By combining the dependency graphs, the main methods of each document class to be generated are analyzed to obtain the initial method call chain graph of each document class to be generated.

4. The design document generation method as described in claim 2, characterized in that, The depth restriction rule includes a depth threshold, and the package restriction rule includes a list of allowed packages; The step of pruning the initial call graph of each method using preset pruning rules to obtain the call graph of each method includes: For each target initial link graph in the method call initial link graph, traverse each call node in the target initial link graph. When the call depth of the call node is greater than the depth threshold, the call node is removed as a target node. And / or, when the call node is not in the allowed package list, the call node is removed as a target node. Remove the target removal node and its downstream calling nodes to obtain the method call chain graph.

5. The design document generation method as described in claim 1, characterized in that, The project source code includes the method code of each node in the method call chain diagram; The step of analyzing the project source code from the leaf nodes of each method call chain graph from bottom to top to obtain the functional logic information of each document class to be generated includes: By analyzing the large model and the lower-level functional logic information of the nodes using the preset first code, the method code corresponding to the current node of each of the method call chain graphs is analyzed to generate the local functional logic information of the current node. The initial lower-level functional logic information of the node is empty, and the initial current node is the leaf node of each of the method call chain graphs. The upstream node of the current node is taken as the new current node, and the lower-level functional logic information of the new node is determined based on the local functional logic information. Based on the new current node and the new node's lower-level functional logic information, the process returns to the step of analyzing the method code corresponding to the current node of each method call chain graph by analyzing the large model and the node's lower-level functional logic information through the preset first code analysis, generating the local functional logic information of the current node, until the preset generation condition is met, and the local functional logic information of the current node when the preset generation condition is met is used as the functional logic information of each document class to be generated.

6. The design document generation method as described in claim 1, characterized in that, The step of analyzing the project source code from top to bottom according to the architectural hierarchy to obtain the business architecture information of each document class to be generated includes: The pre-defined second code analysis model analyzes the project source code from top to bottom according to the architectural hierarchy of the project source code, namely the service layer, data transmission layer, business management layer, and data access layer, to obtain the code business architecture information of each document class to be generated. Based on the code business architecture information, the business architecture information is obtained.

7. The design document generation method as described in claim 6, characterized in that, The step of obtaining the business architecture information based on the code business architecture information includes: Obtain information about each module of the project source code, including package path prefix, module responsibility, and scenario description; The module information is input into the second code analysis model, which is then instructed to associate each document class to be generated with the module information based on the package path prefix. The model then supplements the code business architecture information by combining the module responsibilities and the scenario description, thereby obtaining the business architecture information of each document class to be generated.

8. The design document generation method as described in claim 1, characterized in that, The step of obtaining the design document for each document class to be generated based on the functional logic information and business architecture information of each document class to be generated includes: The pre-defined document generation model combines the functional logic information and business architecture information of each document class to be generated, and generates design documents for each document class according to the pre-defined document structure. The pre-defined document structure includes a functional description part, an architecture description part, and a fusion description part generated based on the functional logic information and the business architecture information.

9. The design document generation method as described in claim 2, characterized in that, After the step of obtaining the design document for each document class to be generated based on the functional logic information and business architecture information of each document class to be generated, the method further includes: When a change is detected in the project source code, the changed files are identified in the changed project source code; Based on the change file and the dependency graph, identify the change class; Update the design document for the aforementioned change class.

10. An electronic device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the design document generation method as described in any one of claims 1 to 9.

Images