A method, system, device and medium for generating a software design document

Abstract

The application provides a software design document generation method, system, device and medium, the generation method comprises the following steps: obtaining source code, constructing a call tree reflecting the calling relationship between functions in the source code, and an independent root node not covered by the call tree; extracting the document segment of the independent root node, and in the direction from the leaf node to the root node of the call tree, taking each node in the call tree as the current node in turn, extracting the document segment and the function summary of each node of the call tree; and splicing the document segments of all nodes according to the call tree and the independent root node to generate the software design document of the source code. The application effectively breaks through the context window limit of the large language model and realizes the analysis of deep nesting and super large scale code.

Description

Technical Field

[0001] This invention relates to the field of project software development and application technology, and in particular to a method, system, device and medium for generating software design documents. Background Technology

[0002] Software design documents are used to describe the internal algorithmic logic, data flow, function call relationships, and processing of key variables of software from a functional perspective, providing comprehensive guidance and basis for software development, testing, and maintenance.

[0003] Currently, software design document generation technology based on large language models is widely used. This technology generates corresponding software design documents by inputting code snippets from the large language model. However, when analyzing large or deeply nested software code, the context window length of the large language model limits the ability to read the complete code snippet at once. When the complete code snippet cannot be read at once, existing practices typically involve splitting the code and processing it separately, resulting in fragmented document content, incoherent logic, and an inability to fully reflect the design intent of the code. Therefore, there is room for improvement. Summary of the Invention

[0004] This invention provides a method, system, device, and medium for generating software design documents, in order to solve the technical problem that existing large language models are limited by the length of the context window and cannot read complete code segments of software at once.

[0005] This invention proposes a method for generating software design documents, comprising: Obtain the source code, identify the functions in the source code and the calling relationships between the functions, and construct a call tree that reflects the calling relationships between the functions in the source code based on the identified functions and calling relationships, and take isolated functions not covered by the call tree as independent root nodes; Extract the document fragment of the independent root node, and sequentially extract the document fragment and function summary of each node in the call tree, taking each node in the call tree as the current node, along the direction from the leaf node to the root node: For each current node, Extract the code snippet from the source code corresponding to the current node; The code snippet and the functional summary of the child nodes of the current node are used as input data. The data are analyzed by a pre-trained large language model to generate a document snippet of the current node. The functional summary of the current node is then extracted from the generated document snippet. When the current node is a leaf node, the input data is only the code snippet of the current node. Based on the call tree and the independent root node, the document fragments of all nodes are concatenated to generate the software design document of the source code.

[0006] In one embodiment of the present invention, the step of obtaining source code, identifying functions in the source code and the call relationships between functions, and constructing a call tree reflecting the call relationships between functions in the source code based on the identified functions and call relationships includes: Obtain the source code and use an abstract syntax tree to identify the functions in the source code and the first call relationships between the functions; Determine whether the header files and / or library files of the source code are missing; When header files and library files are not missing, a call tree reflecting the call relationships between functions is constructed based on the parsed and identified functions and the first call relationship; Otherwise, based on the functions identified by the abstract syntax tree, regular expressions are used to identify the second call relationship between functions in the source code. The first and second call relationships are merged and deduplicated. Based on the identified functions and the deduplicated call relationships, a call tree reflecting the call relationship between functions is constructed.

[0007] In one embodiment of the present invention, the step of using abstract syntax tree parsing to identify functions in the source code and the first call relationship between functions includes: The source code is parsed using an abstract syntax tree, and the nodes of the resulting abstract syntax tree are traversed: When a node is a function during traversal, the corresponding function is identified. When a node is encountered that is a function call expression, the corresponding function call relationship is identified and designated as the first call relationship.

[0008] In one embodiment of the present invention, the step of using regular expressions to identify the second call relationship between functions in the source code, deduplicating the first and second call relationships, and constructing a call tree reflecting the call relationship between functions based on the identified functions and the deduplicated call relationships includes: Based on the functions identified by the abstract syntax tree, the entire text of the source code is traversed, and regular expression rules are used for matching to identify the second call relationship between functions; The first and second call relationships are compared, merged, and deduplicated. Based on the identified functions and their deduplicated call relationships, a call tree reflecting the call relationships between functions is constructed.

[0009] In one embodiment of the present invention, the step of sequentially taking each node in the call tree as the current node along the direction from the leaf node to the root node includes: Determine the maximum depth of the call tree; First, all leaf nodes at the maximum depth of the call tree are taken as the current node in sequence. Then, in order of decreasing depth from bottom to top, all nodes at each level are taken as the current node in sequence.

[0010] In one embodiment of the present invention, the step of sequentially taking each node in the call tree as the current node along the direction from the leaf node to the root node includes: First, all leaf nodes in the call tree are sequentially designated as the current node. Then, the non-leaf nodes in the call tree are processed using a post-order traversal method. For each non-leaf node, after all its child nodes have been designated as the current node, the non-leaf node is designated as the current node.

[0011] In one embodiment of the present invention, The step of treating isolated functions not covered by the call tree as independent root nodes includes: Generate a flattened set of functions containing all functions from the source code; The functions in the flattened function set are compared with the function nodes in the call tree to identify isolated functions that are not covered by the call tree, and these isolated functions are designated as independent root nodes.

[0012] This invention also proposes a software design document generation system, comprising: The construction unit is used to acquire source code, identify functions in the source code and the calling relationships between functions, and construct a call tree that reflects the calling relationships between functions in the source code based on the identified functions and calling relationships, and to take isolated functions not covered by the call tree as independent root nodes; The extraction unit is used to extract the document fragment of the independent root node, and to extract the document fragment and function summary of each node in the call tree by taking each node in the call tree as the current node in the direction from the leaf node to the root node: For each current node, Extract the code snippet from the source code corresponding to the current node; The code snippet and the functional summary of the child nodes of the current node are used as input data. The data are analyzed by a pre-trained large language model to generate a document snippet of the current node. The functional summary of the current node is then extracted from the generated document snippet. When the current node is a leaf node, the input data is only the code snippet of the current node. The generation unit is used to concatenate the document fragments of all nodes according to the call tree and the independent root nodes to generate the software design document of the source code.

[0013] The present invention also proposes an electronic device, the electronic device comprising: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the method for generating software design documents as described in any of the preceding claims.

[0014] The present invention also proposes a computer-readable storage medium having a computer program stored thereon, which, when executed by a computer processor, causes the computer to perform the method for generating the software design document described above.

[0015] The beneficial effects of this invention are as follows: This invention proposes a method, system, device, and medium for generating software design documents. First, it constructs a call tree representing the function call relationships in the source code, as well as independent root nodes not covered by the call tree. Second, it extracts document fragments from the independent root nodes, and sequentially extracts document fragments and functional summaries from each node in the call tree, taking each node as the current node along the direction from the leaf nodes to the root node. Specifically, for each current node, it extracts the code fragment of the corresponding source code; the code fragment and the functional summaries of the current node's child nodes are used as input data and analyzed by a pre-trained large language model to generate the document fragment of the current node, and the functional summary of the current node is extracted from the generated document fragment. Then, according to the call tree and the independent root nodes, the document fragments of all nodes are concatenated to generate the software design document of the source code. Therefore, this invention effectively overcomes the context window limitation of large language models and achieves the parsing of deeply nested, ultra-large-scale code. Attached Figure Description

[0016] 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. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0017] In the attached diagram: Figure 1 A schematic diagram illustrating the steps of a method for generating software design documents according to an embodiment of the present invention.

[0018] Figure 2 This is a call tree diagram illustrating the function call relationships in the source code provided in an embodiment of the present invention.

[0019] Figure 3 This is a structural block diagram of a software design document generation system provided in an embodiment of the present invention.

[0020] Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0021] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0022] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. The drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0023] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0024] Please see Figures 1 to 4 This invention proposes a method, system, device, and medium for generating software design documents, applicable to the field of computer software technology. It particularly relates to a scenario where software design documents are generated recursively from bottom to top based on a call tree between functions in a large language model and source code. The software design document describes the internal algorithmic logic, data flow, function call relationships, and processing of key variables of the software from a functional perspective. It covers multiple aspects such as an introduction, background information, definitions, and references, providing comprehensive guidance and basis for software development, testing, and maintenance.

[0025] This application employs a bottom-up recursive generation strategy, prioritizing the processing of leaf nodes in the call tree and extracting functional summaries to pass upwards. This allows parent nodes to rely only on the functional summaries of child nodes when generating documents without reading the complete source code. This mechanism decomposes complex long text generation tasks into hierarchical short text tasks, effectively overcoming the context window limitations of large language models and achieving complete semantic parsing of deeply nested, ultra-large-scale code. Detailed descriptions are provided below using specific examples.

[0026] Please see Figure 1 In one embodiment of the present invention, a method for generating software design documents may be proposed, comprising the following steps.

[0027] Step S10: Obtain the source code, identify the functions in the source code and the calling relationships between the functions, and construct a call tree that reflects the calling relationships between the functions in the source code based on the identified functions and calling relationships, and take isolated functions not covered by the call tree as independent root nodes.

[0028] Specifically, the system first receives the compressed source code project package uploaded by the user via a web interface, and after decompression, obtains a complete set of source code files. Then, it starts a code parser to perform static analysis on the source code.

[0029] In one embodiment of the present invention, step S10 involves obtaining source code, identifying functions in the source code and the calling relationships between functions, and constructing a call tree reflecting the calling relationships between functions in the source code based on the identified functions and the calling relationships. This may include the following steps.

[0030] Step S110: Obtain the source code and use an abstract syntax tree to identify the functions in the source code and the first call relationship between the functions.

[0031] Specifically, the code parser employs a dual-engine hybrid strategy: the first engine is based on Abstract Syntax Tree (AST) technology, which calls the Clang interface to traverse the AST of each source file. When it traverses a function definition node, it identifies the corresponding function name, parameter list, source file path, and start and end line numbers of the code; when it traverses a call expression node, it identifies the first call relationship between functions.

[0032] In one embodiment of the present invention, step S110 may include the following steps.

[0033] Step S111: Perform abstract syntax tree parsing on the source code and traverse the nodes of the obtained abstract syntax tree.

[0034] Step S112: When a node is a function during traversal, identify the corresponding function.

[0035] Step S113: When a node is a calling expression during traversal, the corresponding function calling relationship is identified and used as the first calling relationship.

[0036] Step S120: Determine whether the header files and / or library files of the source code are missing.

[0037] Specifically, the abstract syntax tree (AST) parsing process is monitored. If parsing errors or inaccessible nodes occur due to missing header file paths, unexpanded macro definitions, or missing third-party dependencies, then header and library files are considered missing. Conversely, if all source files are parsed completely without errors, then no files are considered missing.

[0038] Step S130: When the header file and library file are not missing, construct a call tree that reflects the call relationship between functions based on the parsed and identified functions and the first call relationship.

[0039] Specifically, when it is determined that header files and library files are not missing, the abstract syntax tree parsing has obtained a complete list of functions and an accurate first call relationship. Using all identified functions as nodes, the parent-child relationship is determined by the call direction in the first call relationship, with the caller as the parent node and the callee as the child node, thus constructing a complete call tree in memory.

[0040] Step S140: Otherwise, based on the functions identified by the abstract syntax tree, regular expressions are used to identify the second call relationship between functions in the source code. The first call relationship and the second call relationship are merged and deduplicated. Based on the identified functions and the deduplicated call relationship, a call tree reflecting the call relationship between functions is constructed.

[0041] Specifically, the second engine is a regular expression scan. When it detects that the abstract syntax tree is interrupted due to missing header files, complex macro definitions, or incomplete third-party dependency libraries, it automatically executes preset regular expression matching rules on the original text of the function body to identify potential function calls that the abstract syntax tree failed to capture, and uses them as a second call relationship.

[0042] For example, existing technologies often produce industrial-grade code (especially C / C++) that fails to compile due to complex macro definitions or missing third-party dependencies. Existing tools that rely on pure ASTs (Abstract Syntax Trees) will fail to resolve in such cases, leading to broken function call chains.

[0043] When a header file or library file is determined to be missing, the abstract syntax tree (AST) can identify the function definition because function definition parsing usually does not depend on external header files. However, it may fail to fully parse the function's internal call expression, resulting in a missing element in the first call relationship. To address this, firstly, all functions identified in step S110 are saved. These functions are definite, and the absence of header files does not affect the identification of function definition nodes. Then, the original text of each function's function body is scanned and matched using predefined regular expression rules. These regular expression rules are designed for the function call syntax patterns of the target programming language (such as C / C++), for example, matching the pattern "function name (parameter list)". Through regular expression scanning, all potential function calls appearing in the function body text are extracted, and these call relationships are recorded as the second call relationship. The second call relationship completes the call relationship given the existence of the function, rather than identifying the function itself.

[0044] Subsequently, the first and second call relationships are merged and deduplicated to construct a complete and accurate function call relationship. Based on all identified functions and the deduplicated call relationships, a call tree is constructed in memory: each function corresponds to a node, with the root node being the entry function, such as the main function or an exposed interface function. The parent-child relationship is determined by the call direction, with the caller as the parent node and the callee as the child node. This call tree fully preserves the hierarchical topology of functions in the source code, providing a foundation for subsequent recursive generation.

[0045] In one embodiment of the present invention, step S140 may include the following steps.

[0046] Step S141: Based on the functions identified by the abstract syntax tree, traverse the full text of the source code, use regular expression rules for matching, and identify the second call relationship between functions.

[0047] Step S142: Compare, merge, and deduplicate the first and second call relationships.

[0048] Step S143: Based on the identified functions and the deduplicated call relationships, construct a call tree that reflects the call relationships between functions.

[0049] Therefore, this embodiment enhances parsing robustness and solves the problem of broken links in incomplete environments. By constructing a dual-engine mechanism of "AST parsing + regular expression scanning," it addresses the parsing challenges of industrial-grade code in environments with missing dependencies. When AST parsing fails, it automatically uses regular expression matching to complete weak reference relationships and merges the two results to remove duplicates, ensuring that a highly complete function call relationship tree can still be built even with an incomplete compilation environment, guaranteeing the coverage of generated documentation.

[0050] In one embodiment of the present invention, step S10, treating isolated functions not covered by the call tree as independent root nodes, may include the following steps.

[0051] Step S150: Generate a flattened function set containing all functions in the source code.

[0052] Step S151: Compare the functions in the flattened function set with the function nodes in the call tree, identify isolated functions not covered by the call tree, and treat the isolated functions as independent root nodes.

[0053] Specifically, the analysis results of the source code can be serialized into two types of standard JSON files. One type is a hierarchical call tree file, generating nested JSON that fully preserves the nesting topology between parent and child nodes of functions, used to reconstruct the call tree in the database using a recursive algorithm. The other type is a flattened function set file, generating a flat dictionary JSON containing all function definitions in the project. By comparing the nested JSON with the flattened dictionary JSON set, isolated nodes not covered by the call tree are identified and stored as independent root nodes in the database, ensuring 100% project documentation coverage of the source code.

[0054] Step S20: Extract the document fragment of the independent root node, and sequentially extract the document fragment and function summary of each node in the call tree, taking each node in the call tree as the current node along the direction from the leaf node to the root node: For each current node, Extract the code snippet from the source code corresponding to the current node; The code snippet and the functional summaries of the child nodes of the current node are used as input data. The data are analyzed by a pre-trained large language model to generate a document snippet of the current node, and the functional summaries of the current node are extracted from the generated document snippet. When the current node is a leaf node, the input data is only the code snippet of the current node.

[0055] Specifically, document fragments are extracted from the code snippets corresponding to independent root nodes based on the Large Language Model (LLM). The Large Language Model (LLM) is a pre-trained generative model with code understanding and natural language generation capabilities. It parses the syntactic structure of the code snippets corresponding to independent root nodes, identifying function signatures, parameter lists, return value types, and internal variable definitions. Subsequently, based on its pre-trained code understanding capabilities, the model infers the function's execution logic from two dimensions: control flow (conditional branches, loop structures) and data flow (variable assignment, propagation paths). Finally, the model transforms this logic into a natural language description, outputting a design document containing a functional summary, input / output descriptions, and core algorithm steps.

[0056] Specifically, a post-order traversal strategy is executed on the memory call tree constructed in step S10. Specifically, the traversal starts recursively from the root node, prioritizing the visit of all child nodes until a leaf node with no child nodes is reached. For each visited node, it is designated as the current node and processed in a "child-first, parent-later" order: all leaf nodes are treated as the current node first, and after processing, the result is returned to their parent node. The parent node must wait until all its child nodes have been processed as the current node before it is processed as the current node.

[0057] By adopting this bottom-up order, each node in the call tree is traversed sequentially, and the context environment required for generating document fragments and function summaries is prepared for each node. Throughout the traversal, the system pushes information about the currently processed node, such as the node name and processing status, to the front-end monitoring interface in real time, displaying the real-time progress of recursive generation to the user in the form of a progress bar and log list.

[0058] like Figure 2 As shown, in the call tree of source code functions, the root node is a node without a parent node, representing the entry function or top-level function of the entire call tree. In the call tree shown in the attached figure, node A has no parent node, therefore the root node is A.

[0059] Parent-child nodes refer to two nodes in a calling relationship that have a direct calling relationship. The caller is the parent node, and the callee is the child node. In the attached diagram, A is the parent node of B, C, and D, and B, C, and D are the child nodes of A. B is the parent node of E and F, and E and F are the child nodes of B. C is the parent node of G, and G is the child node of C.

[0060] A leaf node is a node with no child nodes, representing an atomic function or a low-level function that no longer calls other functions. In the attached diagram, nodes D, E, F, and G all have no child nodes, therefore they are all leaf nodes.

[0061] A non-leaf node is a node that has at least one child node, representing a composite function that calls other functions. In the attached diagram, nodes A, B, and C all have child nodes, therefore they are all non-leaf nodes.

[0062] The step S20 described as "taking each node in the call tree as the current node in sequence along the direction from the leaf node to the root node" means processing in the order from D, E, F, G (leaf nodes) to B, C (intermediate non-leaf nodes) and then to A (root node) to ensure that the document fragments and function summaries of the child nodes are generated first and then used by the parent node.

[0063] For step S20: For each current node, extract the code fragment of the source code corresponding to the current node; take the code fragment and the functional summary of the child nodes of the current node as input data, analyze them through a pre-trained large language model, generate a document fragment of the current node, and extract the functional summary of the current node from the generated document fragment; wherein, when the current node is a leaf node, the input data is only the code fragment of the current node.

[0064] Specifically, for each defined current node, firstly, based on the source file path and start and end line numbers recorded in the node, the complete code snippet corresponding to the function is precisely extracted from the original source code file. Then, it is determined whether the current node is a leaf node. If the current node is a leaf node (i.e., a node with no child nodes in the call tree), a basic prompt word is constructed using only the code snippet as input data. The pre-trained large language model is then asked to interpret the function's input, output, and core algorithm logic. The model's return result is the document snippet for that leaf node, from which a short functional summary is extracted, such as "This function is used to verify whether the input parameters are within a valid range." If the current node is not a leaf node (i.e., it has one or more child nodes), then all functional summaries generated and returned by the current node's child nodes are collected to form a sub-functional summary list.

[0065] Among them, the Large Language Model (LLM) can be a pre-trained generative model with code understanding and natural language generation capabilities. Specifically, mainstream industry models such as GPT-4, DeepSeek-Coder, CodeLlama, or Qwen-Coder can be selected.

[0066] For example, for a single code snippet input from a leaf node, the large language model first performs syntactic structure parsing on the code snippet, identifying the function signature, parameter list, return type, and internal variable definitions. Subsequently, based on its pre-trained code understanding capabilities, the model infers the function's execution logic from two dimensions: control flow (conditional branches, loop structures) and data flow (variable assignment, propagation paths). Finally, the model transforms this logic into a natural language description, outputting a design document that includes a functional summary, input / output descriptions, and core algorithm steps.

[0067] For code snippets and child node function summary lists input from non-leaf nodes, the large language model first parses the function call statements in the parent function code snippet, matching each call statement with the entries in the child node function summary list. Then, instead of analyzing the internal implementation details of the called functions, the model directly reads the corresponding function summaries to understand the tasks completed by each child call. Based on this, the model comprehensively analyzes the control flow and data flow of the parent function itself, clarifying how the parent function schedules each child function according to a specific order and conditions, as well as the data transfer and collaboration relationships between child functions, and finally outputs a design document describing the overall business process of the parent function.

[0068] The code snippet of the current node and the list of sub-function summaries are used as input data to construct a compound prompt word. This prompt word forces the large language model to describe how the current node schedules various sub-modules to implement higher-level business logic, based on the known exact functions of the sub-nodes. The generated output is the document snippet of the current node, from which a function summary is extracted. In this way, a corresponding document snippet and function summary are generated for each current node, and the function summary is returned to the parent node as input for subsequent generation.

[0069] Therefore, this embodiment can overcome the limitations of the context window and achieve complete semantic generation of deep logic. It aims to generate atomic function descriptions of leaf nodes first through a bottom-up recursive generation strategy, and then refine these descriptions into functional summaries that are passed upwards. Parent nodes only need to read the summaries of child nodes, rather than the original source code, to understand the calling logic. This method effectively reduces token (the smallest basic unit when the model processes text) consumption while ensuring semantic integrity, enabling the system to handle complex call chains of arbitrary depth.

[0070] In one embodiment of the present invention, step S20, which sequentially takes each node in the call tree as the current node along the direction from the leaf node to the root node, includes the following steps: Step S201: Determine the maximum depth of the call tree.

[0071] Step S202: First, take all the leaf nodes at the maximum depth of the call tree as the current node in turn. Then, in the order of decreasing depth from bottom to top of the call tree, take all the nodes at each level as the current node in turn.

[0072] Specifically, the depth of each node in the call tree is first calculated to determine the maximum depth of the entire tree. Then, processing is performed layer by layer in a bottom-up order: all leaf nodes at the maximum depth level are taken as the current node in turn, and the depth is decremented by one after completion. All nodes in the previous level are then taken as the current node in turn, and so on, until the root node is reached. This layered processing method ensures that when each node is processed, all its child nodes have been generated and a functional summary has been provided.

[0073] In one embodiment of the present invention, step S20, which sequentially takes each node in the call tree as the current node along the direction from the leaf node to the root node, includes the following steps: S210. First, all leaf nodes in the call tree are taken as the current node in turn. Then, the non-leaf nodes in the call tree are processed by post-order traversal. For each non-leaf node, after all its child nodes have been taken as the current node, the non-leaf node is taken as the current node.

[0074] Specifically, the entire call tree is traversed first, and all nodes without children are identified as leaf nodes. These leaf nodes are then processed as the current nodes in turn, generating a document fragment and a function summary for each leaf node.

[0075] After all leaf nodes have been processed, non-leaf nodes in the call tree are scheduled using a post-order traversal: starting from the root node, the traversal is recursively performed. For each non-leaf node, all its child nodes are processed recursively first, ensuring that each child node has been processed as the current node and a function summary has been returned. Then, the current non-leaf node is used as the current node, and the document is generated using the collected child node function summaries. In this way, the entire call tree is traversed from bottom to top in the order of leaf nodes first, and non-leaf nodes are processed sequentially after all their child nodes have been processed.

[0076] Step S30: According to the call tree and the independent root node, concatenate the document fragments of all nodes to generate the software design document of the source code.

[0077] Specifically, after step S20 is completed, each node in the call tree has a corresponding document fragment. Based on the parent-child hierarchy between nodes in the call tree, the subordinate and sequential relationships between the document fragments are determined: the root node's document fragment serves as the summary of the document, and the document fragments of all its child nodes are arranged sequentially under each parent node's document fragment. Nodes at the same level are arranged according to their natural order of appearance in the source code.

[0078] Starting from the root node, a depth-first traversal is used to recursively concatenate the document fragments of each node into a complete Markdown text according to the aforementioned hierarchical structure. During the concatenation process, corresponding levels of heading tags are added based on the node depth; for example, first-level headings correspond to the root node, and second-level headings correspond to child nodes, resulting in a clear hierarchical structure in the final document. After concatenation, a complete software design document is obtained, which comprehensively describes the design intent and implementation details of every function in the source code, from top-level business logic to bottom-level atomic functions. This document is then stored in the document table of the corresponding tenant schema in a relational database and made available for users to preview, download, or further manually correct via a web interface.

[0079] In one embodiment of the present invention, step S30 may include the following steps.

[0080] Step S310: Determine the hierarchical relationship between document fragments of each node based on the hierarchical relationship of each node in the call tree.

[0081] Step S320: Based on the hierarchical relationship between the document fragments of each node, the document fragments of all nodes are spliced ​​together to generate the software design document of the source code.

[0082] Specifically, the hierarchical relationship between document fragments is first determined based on the node hierarchy of the call tree, and then a database transaction is initiated. Document fragments for each node are inserted into the database record one by one in a depth-first order, and the call tree structure is restored through foreign key relationships with parent nodes. If all nodes are successfully inserted, the transaction is committed, and a complete software design document is dynamically generated based on the hierarchical relationship in the database. If any node insertion fails, the transaction is rolled back, ensuring that all data changes are undone, thereby guaranteeing the integrity of the document fragments and the consistency of the call tree structure.

[0083] Therefore, this embodiment can eliminate the logical illusion of a large language model and improve document accuracy. By utilizing a hierarchical context fusion mechanism, when generating upper-level documents, it forces the confirmed list of lower-level sub-functions to be used as context input. This ensures that the large language model has solid underlying logic support when analyzing top-level business logic, thereby eliminating the illusion caused by guessing the functions of sub-functions and generating logically rigorous and highly accurate design documents.

[0084] In addition, in order to solve the problems of data confusion among multiple projects, leakage of source code and document data, inability to retain generated results for a long time, and consistency issues in large-scale node database entry, the following embodiments can be provided in this invention.

[0085] A document generation system based on B / S architecture is proposed, which may include a backend processing subsystem, a human-computer interaction visualization subsystem, and a data storage subsystem.

[0086] Specifically, the backend processing subsystem is responsible for computationally intensive tasks and process scheduling. For example, the code parsing module of the backend processing subsystem is used to perform AST parsing and regular expression matching. The recursive control module of the backend processing subsystem is used to schedule LLM requests, manage context windows, and prevent token overflow. The database interaction module of the backend processing subsystem is responsible for mapping JSON intermediate data to database model objects and handling multi-tenant routing.

[0087] Specifically, the data storage subsystem is the core of data persistence and is built using a relational database. The multi-tenant architecture can employ a shared database, separate schemas strategy, ensuring that each software project has its own independent database schema.

[0088] Specifically, the human-computer interaction visualization subsystem consists of web pages and front-end scripts, and interacts with the back-end processing subsystem and the data storage subsystem.

[0089] The human-computer interaction visualization subsystem includes an engineering import and configuration unit, a full-process monitoring unit, an interactive call tree view unit, a document workshop and collaborative editing unit, and a project insight unit. The functions of each unit are as follows.

[0090] (1) The Project Import and Configuration Unit is used to provide a drag-and-drop upload area and parameter configuration panel. The Project Name configured by the user will directly determine which database schema the backend creates or reuses.

[0091] (2) The front end of the full-process monitoring unit requests the interface at regular intervals, and the back end reads the task status in memory or database logs, returns the progress percentage, and dynamically renders the progress bar.

[0092] (3) The interactive call tree view unit has the functions of interactive logic, topology display and details loading.

[0093] The interaction logic involves the front-end initiating a request, and the back-end routing the request to the corresponding schema based on the project parameter, retrieving hierarchical data from the table, and returning JSON.

[0094] The topology display renders the left sidebar as a collapsible DOM (Document Object Model) tree.

[0095] Detail loading involves the front-end using the node ID to request the database again when a tree node is clicked, retrieving the complete source code and documentation for that node, thus achieving "on-demand loading" and improving browsing performance for large projects.

[0096] (4) The document workshop and collaborative editing unit have the functions of two-column comparison, data synchronization and block locking.

[0097] The two-column comparison features a Markdown preview on the left and an editing box on the right.

[0098] Data synchronization occurs when a user modifies a document and clicks "save," and the front-end sends a request to update the corresponding table record's content fields in the database.

[0099] Block locking refers to storing the lock status as a field in the database to ensure data consistency when multiple people are collaborating.

[0100] (5) The Project Insight Unit aggregates and queries tables in the database to count metadata such as lines of code and document coverage, and generates statistical dashboards.

[0101] This demonstrates that by executing tenant routing based on the project identifier, switching to the corresponding database schema, and recursively mapping the JSON tree in memory to relational database records, physical isolation of source code and document data from different projects is achieved.

[0102] Please see Figure 3 In one embodiment of the present invention, a software design document generation system 100 may be proposed, which may include a construction unit 110, an extraction unit 120, and a generation unit 130.

[0103] The construction unit 110 is used to acquire source code, identify functions in the source code and the calling relationships between functions, and construct a call tree that reflects the calling relationships between functions in the source code based on the identified functions and calling relationships, and take isolated functions not covered by the call tree as independent root nodes.

[0104] Extraction unit 120 is used to extract the document fragment of the independent root node, and sequentially extract the document fragment and function summary of each node in the call tree, taking each node in the call tree as the current node, along the direction from the leaf node to the root node: For each current node, Extract the code snippet from the source code corresponding to the current node; The code snippet and the functional summaries of the child nodes of the current node are used as input data. The data are analyzed by a pre-trained large language model to generate a document snippet of the current node, and the functional summaries of the current node are extracted from the generated document snippet. When the current node is a leaf node, the input data is only the code snippet of the current node.

[0105] The generation unit 130 is used to splice together the document fragments of all nodes according to the call tree and the independent root node to generate the software design document of the source code.

[0106] Therefore, this embodiment can overcome the limitations of the context window and achieve complete semantic generation of deep logic. It aims to use a bottom-up recursive generation strategy to prioritize the generation of atomic function descriptions for leaf nodes and extract them into functional summaries for upward transmission. Parent nodes only need to read the summaries of child nodes, rather than the original source code, to understand the calling logic.

[0107] Please see Figure 4 The present invention proposes an electronic device 200, which may include a memory 210, a processor 220 and a bus, and may also include a computer program stored in the memory 210 and executable on the processor 220, such as a software design document generation program.

[0108] The memory 210 includes at least one type of readable storage medium, such as flash memory, portable hard drive, multimedia card, card-type memory (e.g., SD or DX memory), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 210 can be an internal storage unit of the electronic device 200, such as the portable hard drive of the electronic device 200. In other embodiments, the memory 210 can be an external storage device of the electronic device 200, such as a plug-in portable hard drive, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on the electronic device 200. Furthermore, the memory 210 can include both internal and external storage units of the electronic device 200. The memory 210 can be used not only to store application software and various types of data installed on the electronic device 200, such as the code generated from software design documents, but also to temporarily store data that has been output or will be output.

[0109] In some embodiments, processor 220 may be composed of integrated circuits, such as a single packaged integrated circuit or multiple integrated circuits packaged with the same or different functions, including combinations of one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and various control chips. Processor 220 is the control unit of the electronic device 200, connecting various components of the electronic device 200 via various interfaces and lines. It executes programs or modules stored in the memory 210 (e.g., software design document generation programs) and calls data stored in the memory 210 to perform various functions of the electronic device 200 and process data.

[0110] The processor 220 executes the operating system and various installed applications of the electronic device 200. The processor 220 executes the applications to implement the steps in the above-described method for generating software design documents.

[0111] For example, the computer program may be divided into one or more modules, which are stored in the memory 210 and executed by the processor 220 to complete this application. The one or more modules may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the electronic device 200. For example, the computer program may be divided into a building unit 110, an extraction unit 120, a document generation unit 130, and a splicing unit 140.

[0112] The integrated units implemented as software functional modules described above can be stored in a computer-readable storage medium, which can be non-volatile or volatile. The software functional modules stored in the storage medium include several instructions to cause a computer device (which may be a personal computer, computer equipment, or network device, etc.) or processor to execute some functions of the software design document generation method described in the various embodiments of this application.

[0113] In summary, this invention proposes a method, system, device, and medium for generating software design documents. First, a call tree representing the function call relationships in the source code is constructed. Second, each node in the call tree is sequentially taken as the current node, and its document fragment and functional summary are extracted. Specifically, for each current node, a code fragment corresponding to that node's source code is extracted. The code fragment and the functional summaries of the current node's child nodes are used as input data and analyzed by a pre-trained large language model to generate the current node's document fragment, from which the functional summary is extracted. Then, following the call tree, the document fragments of all nodes are concatenated to generate the software design document of the source code. Therefore, this invention effectively overcomes the context window limitation of large language models, enabling the parsing of deeply nested, ultra-large-scale code.

[0114] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A method for generating software design documents, characterized in that, include: Obtain the source code, identify the functions in the source code and the calling relationships between the functions, and construct a call tree that reflects the calling relationships between the functions in the source code based on the identified functions and calling relationships, and take isolated functions not covered by the call tree as independent root nodes; Extract the document fragment of the independent root node, and sequentially extract the document fragment and function summary of each node in the call tree, taking each node in the call tree as the current node, along the direction from the leaf node to the root node: For each current node, Extract the code snippet from the source code corresponding to the current node; The code snippet and the functional summary of the child nodes of the current node are used as input data. The data are analyzed by a pre-trained large language model to generate a document snippet of the current node. The functional summary of the current node is then extracted from the generated document snippet. When the current node is a leaf node, the input data is only the code snippet of the current node. Based on the call tree and the independent root node, the document fragments of all nodes are concatenated to generate the software design document of the source code.

2. The method for generating software design documents according to claim 1, characterized in that, The process of obtaining source code, identifying functions in the source code and their call relationships, and constructing a call tree reflecting these call relationships based on the identified functions and their call relationships includes: Obtain the source code and use an abstract syntax tree to identify the functions in the source code and the first call relationships between the functions; Determine whether the header files and / or library files of the source code are missing; When header files and library files are not missing, a call tree reflecting the call relationships between functions is constructed based on the parsed and identified functions and the first call relationship; Otherwise, based on the functions identified by the abstract syntax tree, regular expressions are used to identify the second call relationship between functions in the source code. The first and second call relationships are merged and deduplicated. Based on the identified functions and the deduplicated call relationships, a call tree reflecting the call relationship between functions is constructed.

3. The method for generating software design documents according to claim 2, characterized in that, The process of using abstract syntax tree parsing to identify functions in the source code and the first call relationships between functions includes: The source code is parsed using an abstract syntax tree, and the nodes of the resulting abstract syntax tree are traversed: When a node is a function during traversal, the corresponding function is identified. When a node is encountered that is a function call expression, the corresponding function call relationship is identified and designated as the first call relationship.

4. The method for generating software design documents according to claim 2, characterized in that, The step of using regular expressions to identify the second call relationship between functions in the source code, removing duplicates from the first and second call relationships, and constructing a call tree reflecting the call relationships between functions based on the identified functions and the deduplicated call relationships includes: Based on the functions identified by the abstract syntax tree, the entire text of the source code is traversed, and regular expression rules are used for matching to identify the second call relationship between functions; The first and second call relationships are compared, merged, and deduplicated. Based on the identified functions and their deduplicated call relationships, a call tree reflecting the call relationships between functions is constructed.

5. The method for generating software design documents according to claim 1, characterized in that, The step of sequentially taking each node in the call tree as the current node along the direction from the leaf node to the root node includes: Determine the maximum depth of the call tree; First, all leaf nodes at the maximum depth of the call tree are taken as the current node in sequence. Then, in order of decreasing depth from bottom to top, all nodes at each level are taken as the current node in sequence.

6. The method for generating software design documents according to claim 1, characterized in that, The step of sequentially taking each node in the call tree as the current node along the direction from the leaf node to the root node includes: First, all leaf nodes in the call tree are sequentially designated as the current node. Then, the non-leaf nodes in the call tree are processed using a post-order traversal method. For each non-leaf node, after all its child nodes have been designated as the current node, the non-leaf node is designated as the current node.

7. The method for generating software design documents according to claim 1, characterized in that, The step of treating isolated functions not covered by the call tree as independent root nodes includes: Generate a flattened set of functions containing all functions from the source code; The functions in the flattened function set are compared with the function nodes in the call tree to identify isolated functions that are not covered by the call tree, and these isolated functions are designated as independent root nodes.

8. A software design document generation system, characterized in that, include: The construction unit is used to acquire source code, identify functions in the source code and the calling relationships between functions, and construct a call tree that reflects the calling relationships between functions in the source code based on the identified functions and calling relationships, and to take isolated functions not covered by the call tree as independent root nodes; The extraction unit is used to extract the document fragment of the independent root node, and to extract the document fragment and function summary of each node in the call tree by taking each node in the call tree as the current node in the direction from the leaf node to the root node: For each current node, Extract the code snippet from the source code corresponding to the current node; The code snippet and the functional summary of the child nodes of the current node are used as input data. The data are analyzed by a pre-trained large language model to generate a document snippet of the current node. The functional summary of the current node is then extracted from the generated document snippet. When the current node is a leaf node, the input data is only the code snippet of the current node. The generation unit is used to concatenate the document fragments of all nodes according to the call tree and the independent root nodes to generate the software design document of the source code.

9. An electronic device, characterized in that, The electronic device includes: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the method for generating a software design document as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by the computer's processor, causes the computer to perform the method for generating the software design document as described in any one of claims 1 to 7.

Images