Code logic tree for legacy systems showing systems, devices, and media

By generating stored procedure dependency graphs and using large language models to process the code logic of legacy systems, the problems of inaccurate understanding and low efficiency of code logic in legacy systems are solved, and accurate display and rapid positioning of system-level code logic are achieved.

CN120508283BActive Publication Date: 2025-09-16中信证券股份有限公司
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202511005917.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-07-22
Publication Date
2025-09-16
Estimated Expiration
2045-07-22

AI Technical Summary

Technical Problem

Existing technologies have problems with inaccurate and inefficient logic understanding when dealing with code logic understanding of legacy systems. This is especially true when the code volume is large and the logic is complex, which causes the understanding process to be stuck and time-consuming.

Method used

By obtaining the metadata, dependencies, and stored procedure sets of the legacy system, a stored procedure dependency graph is generated. The graph is decomposed using a large language model to generate a stored procedure subgraph set. The prompt information is understood in combination with the code logic to generate a system-level code logic tree, which is then displayed step by step on the page.

Benefits of technology

It achieves accurate and efficient display of legacy system code logic, can quickly locate and view code blocks and logical relationships under various businesses, and improves the accuracy and efficiency of code understanding.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120508283B_ABST
    Figure CN120508283B_ABST
Patent Text Reader

Abstract

The embodiments of the present disclosure disclose a code logic tree display system, device and medium for legacy systems. A specific implementation of the system includes: the system cache end obtains the metadata, dependency relationships and stored procedure sets corresponding to the target legacy system; the graph processing end generates a stored procedure dependency graph; the stored procedure dependency graph is decomposed to obtain a stored procedure subgraph set; for each stored procedure subgraph, the server executes the generation step: the code logic understanding prompt information is input into the target large language model to obtain code logic information; the server generates a system-level code logic tree; the display end responds to the page display information received, and gradually displays the code blocks and code logic information of the system-level code logic tree. This implementation method, through the interactive cooperation between the various terminals of the system, can achieve the understanding of the system-level code logic and the effective display of the corresponding tree structure form for the case where the code logic of the target legacy system is complex and the code volume is large.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] Embodiments of the present disclosure relate to the field of computer technology, and in particular to a code logic tree display system, device, and medium for a legacy system. Background Art

[0002] Currently, conventional large enterprises often face cumbersome business system maintenance and difficulty streamlining their operations. With the advent of the intelligent era, businesses are upgrading and updating their business systems to improve daily operational efficiency and achieve cost reduction and efficiency gains. Understanding and demonstrating system code logic is typically accomplished through code logic understanding scripts.

[0003] However, when using the above method, the following technical problems often occur:

[0004] The system has been continuously iterated and updated by different R&D personnel for a long time. The amount of code is not only massive but also the code logic is complex. As a result, the code logic understanding script cannot guarantee the accuracy of the logic understanding during the logic understanding process. Moreover, due to the large amount of code, the logic understanding process may be stuck, wasting a long time. Summary of the Invention

[0005] The content of this disclosure is used to briefly introduce concepts that will be described in detail in the detailed description section below. The content of this disclosure is not intended to identify key features or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0006] Some embodiments of the present disclosure provide a code logic tree display system, device, and medium for legacy systems to solve one or more of the technical problems mentioned in the above background technology section.

[0007] In a first aspect, some embodiments of the present disclosure provide a code logic tree display system for a legacy system, including: a system cache end obtains metadata, dependency relationships, and a stored procedure set corresponding to a target legacy system; a graph processing end generates a stored procedure dependency graph based on the metadata, dependency relationships, and stored procedure set; the graph processing end decomposes the stored procedure dependency graph based on the input byte limit corresponding to a target large language model to obtain a set of stored procedure subgraphs in which subgraphs have dependency relationships; for each stored procedure subgraph, a server executes a generation step: based on the graph structure corresponding to the stored procedure subgraph, code logic understanding prompt information corresponding to the stored procedure subgraph is generated; the code logic understanding prompt information is input into the target large language model to obtain code logic information in a target format; the server generates a system-level code logic tree based on the obtained code logic information set; and in response to receiving page display information for the system-level code logic tree, a display end displays the code blocks and code logic information of the system-level code logic tree on the target page in a cascade display manner or a hierarchical expansion manner.

[0008] In a second aspect, some embodiments of the present disclosure provide an electronic device comprising: one or more processors; a storage device on which one or more programs are stored, and when the one or more programs are executed by one or more processors, the one or more processors implement a system as described in any implementation method in the first aspect.

[0009] In a third aspect, some embodiments of the present disclosure provide a computer-readable medium having a computer program stored thereon, wherein when the program is executed by a processor, the system described in any implementation manner in the first aspect is implemented.

[0010] The above-mentioned embodiments of the present disclosure have the following beneficial effects: Through the code logic tree display system for legacy systems of some embodiments of the present disclosure, through the interactive cooperation between various system terminals, it is possible to achieve system-level code logic understanding and effective display of the corresponding tree structure in the case of complex and large code logic in the target legacy system. Specifically, the reason for the lack of accurate and efficient code logic understanding is that the system has been continuously updated by different R&D personnel for a long time, and the code volume is not only massive but also complex. As a result, the code logic understanding script cannot guarantee the accuracy of the logic understanding during the logic understanding process. Due to the large amount of code, the logic understanding process may be stuck and waste a long time. Based on this, the code logic tree display system for legacy systems of some embodiments of the present disclosure first obtains the metadata, dependency relationships, and stored procedure sets corresponding to the target legacy system. Here, using the metadata, dependency relationships, and stored procedure sets stored in the system cache, a preliminary understanding of the stored procedures can be accurately and effectively achieved, and a stored procedure dependency graph that reflects the dependencies between the stored procedures can be obtained. Then, the graph processing end can accurately generate the stored procedure dependency graph based on the metadata, dependency relationships, and stored procedure sets. By generating a stored procedure dependency graph, the subsequent effective partitioning of stored procedures based on input byte limits is facilitated. Next, the graph processing end accurately decomposes the stored procedure dependency graph based on the input byte limits of the target large language model, obtaining a set of stored procedure subgraphs with dependent subgraphs. Given the limited input bytes of the target large language model and the complex and massive code size of the target legacy system, the stored procedure dependency graph is used to effectively partition stored procedures, resulting in stored procedure subgraphs that meet the target large language model's input byte limits. Considering the target large language model's comprehension ceiling, if too much code information is input at once, the target large language model may experience comprehension issues exceeding this ceiling, resulting in lags and errors on the corresponding application pages. Thus, by rationally partitioning the stored procedure dependency graph based on the input byte limits, each resulting stored procedure subgraph corresponds to a stored procedure subset that not only meets the target large language model's input byte limits but also enables the target large language model to accurately understand the code logic within its own comprehension capabilities. Next, for each stored procedure subgraph in the stored procedure subgraph set, the server performs the following generation steps: First, based on the graph structure corresponding to the stored procedure subgraph, customized code logic comprehension prompt information for the stored procedure subgraph can be generated. Here, personalized code logic comprehension prompt information can be generated based on the graph structure of the stored procedure subgraph itself, facilitating the subsequent generation of accurate code logic information by the target large language model.In the second step, the code logic understanding prompt information is input into the target large language model, which can accurately generate code logic information in the target format while meeting the input byte limit corresponding to the target large language model and within the corresponding understanding range of the target large language model. Furthermore, the server generates a system-level code logic tree based on the obtained code logic information set. Here, through the generation and storage of the system-level code logic tree, it is convenient to view the code logic relationship corresponding to the target legacy system in real time. Through the logical understanding of the system-level code logic relationship in the form of a tree structure, the code logic under each business can be quickly located and viewed. Finally, in response to receiving the page display information for the system-level code logic tree, the display end displays the code blocks and code logic information of the system-level code logic tree on the target page in a cascade display method or a hierarchical expansion method. Here, through the display of code blocks and code logic information, the processing object can clearly understand the code blocks and code logic of the target legacy system under each business. In summary, through the interactive cooperation between various terminals in the system, the stored procedure dependency graph is accurately generated, so that the stored procedure set can be reasonably divided according to the input byte limit of the target large language model. This allows the target large language model to accurately generate the code logic information of the stored procedure subgraph within its own understanding range and input limits, so that the system-level code logic tree can be accurately generated. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The above and other features, advantages, and aspects of the various embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and that components and elements are not necessarily drawn to scale.

[0012] Figure 1 is a flowchart of some embodiments of a code logic tree display system for a legacy system according to the present disclosure;

[0013] Figure 2 is a schematic structural diagram of an electronic device suitable for implementing some embodiments of the present disclosure;

[0014] Figure 3 A schematic diagram showing the generated code logic tree and business rule description document is shown;

[0015] Figure 4 A schematic diagram of decomposing a stored procedure dependency graph is shown;

[0016] Figure 5 Shows a schematic diagram of the system-level code logic tree;

[0017] Figure 6 A schematic diagram of a business rule description document is shown;

[0018] Figure 7 A schematic diagram of generating a system-level code logic tree is shown. DETAILED DESCRIPTION

[0019] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments described herein. On the contrary, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0020] It should also be noted that, for ease of description, only the parts related to the invention are shown in the drawings. In the absence of conflict, the embodiments and features in the embodiments of the present disclosure may be combined with each other.

[0021] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0022] It should be noted that the modifications of "one" and "multiple" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, they should be understood as "one or more".

[0023] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.

[0024] The present disclosure will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments.

[0025] refer to Figure 1 , shows a process 100 of some embodiments of a code logic tree display system for legacy systems according to the present disclosure. The code logic tree display system for legacy systems includes the following steps:

[0026] Step 101: The system cache obtains metadata, dependency relationships, and stored procedure sets corresponding to the target legacy system.

[0027] In some embodiments, the system cache in the aforementioned code logic tree display system for legacy systems can obtain metadata dependencies and stored procedure sets corresponding to the target legacy system. The target legacy system may be a legacy system for which code logic analysis is required. Complex system code logic in the target legacy system can make code maintenance difficult. The massive amount of system code in the target legacy system can also lead to excessive overhead in code logic analysis. Dependencies can represent the call dependencies between stored procedures. Metadata can be descriptive data for the stored procedure code. Specifically, metadata is structured information describing the characteristics and properties of the stored procedure. In practice, metadata may include, but is not limited to, at least one of the following: stored procedure name, creation time, modification time, creator information, stored procedure parameter information, stored procedure body code, and stored procedure access permissions. A stored procedure is a set of precompiled SQL statements stored in a database. Stored procedures are used in the target legacy system to improve performance (for example, pre-compilation reduces SQL parsing time and reduces network transmission), enhance security and integrity, and simplify complex operations (for example, legacy systems often contain complex business rules (such as financial interest calculation logic), and stored procedures centrally manage these rules to avoid code dispersion). The stored procedure itself is part of the metadata, and its definition, parameters, and dependent tables are all recorded in the system cache. When the table structure changes, the affected stored procedures (such as references to deleted fields) can be located through metadata and dependency analysis. Among them, the system cache can be a cache that stores system information related to the target legacy system. System information may include but is not limited to at least one of the following: metadata, dependencies, and stored procedure sets. After the system cache obtains the metadata, dependencies, and stored procedure sets, the system cache sends the metadata, dependencies, and stored procedure sets to the graph processing end to facilitate the subsequent generation of a stored procedure dependency graph.

[0028] Step 102: The graph processing end generates a stored procedure dependency graph based on the metadata, the dependency relationships, and the stored procedure set.

[0029] In some embodiments, the graph processing end can generate a stored procedure dependency graph based on the metadata dependencies and the stored procedure set. The stored procedure dependency graph can represent a dependency graph of call dependencies between stored procedures. Each node in the dependency graph represents a stored procedure, and the corresponding edges represent dependencies. The graph processing end can be a terminal that performs various processing on the dependency graph corresponding to the stored procedures. For example, the various processing operations include graph generation, graph decomposition, and graph replacement.

[0030] As an example, the graph processing end can generate an initial dependency graph based on the dependency relationships. Then, based on the metadata, each node and each edge in the initial dependency graph is modified to obtain a stored procedure dependency graph. The node information of each node and the edge information of each edge in the stored procedure dependency graph do not violate the description information corresponding to the metadata.

[0031] In some optional implementations of some embodiments, the graph processing end generates a stored procedure dependency graph based on the metadata, the dependency relationship, and the stored procedure set, including the following steps:

[0032] The first step is to generate an initial stored procedure dependency graph based on the metadata and dependency relationships, wherein the initial stored procedure dependency graph may be a dependency graph of the dependency relationships between the stored procedures in the stored procedure subset involved in the metadata and dependency relationships.

[0033] As an example, the graph processing end may generate an initial stored procedure dependency graph by sorting out the dependency relationships between the various stored procedures in the metadata and the dependency relationships and generating a dependency graph.

[0034] The second step is to perform a code scan on the stored procedure set to filter out the remaining code information sets that are not present in the initial stored procedure dependency graph. The remaining code information sets may be related code information not mentioned in the initial stored procedure dependency graph. The code information not present in the initial stored procedure dependency graph may be code information not mentioned in the initial stored procedure dependency graph.

[0035] As an example, the graph processing end may scan all codes corresponding to the target legacy system through a pre-written code scanning script, and scan out the remaining code information set that does not exist in the initial stored procedure dependency graph.

[0036] The third step is to divide the various remaining code information in the above-mentioned remaining code information set according to the number of bytes corresponding to each remaining code information to obtain a remaining code information group set. The remaining code information in each remaining code information group has a code association relationship, and the total number of bytes corresponding to the remaining code information group meets the above-mentioned input byte limit. Among them, there is a code dependency relationship between the various remaining code information in the remaining code information group. That is, the remaining code information in the remaining code information group can be a code information group corresponding to the same module under the same business. The total number of bytes corresponding to the remaining code information group can be the sum of the number of tokens corresponding to each remaining code information. Token is the smallest semantic unit when a large language model processes text, and is the basic unit for the model to convert natural language into a machine-processable form.

[0037] As an example, first, the various remaining code information in the remaining code information set are divided according to the business information corresponding to each remaining code information and the business module identifier to which it belongs, to obtain at least one remaining code information subset. Then, the total number of tokens corresponding to each remaining code information subset in the at least one remaining code information subset is determined. Then, the target remaining code information subset whose total number of tokens does not meet the input byte limit is filtered out from the at least one remaining code subset to obtain at least one target remaining code information subset. Then, for each target remaining code information subset, the total number of tokens corresponding to the target remaining code information subset is divided by the restriction token corresponding to the input byte limit to obtain a division value. Further, a positive integer with a size greater than the corresponding division value is taken. Then, the division value is used as the uniform division number to further split the target remaining code information set to obtain a split code information set. Finally, at least one target remaining code information subset in the at least one remaining code information subset is replaced with the corresponding at least one split code information set to obtain a remaining code information group set.

[0038] Step 4: For each remaining code information group in the remaining code information group set, perform the following input steps:

[0039] Sub-step 1, generates dependency graph prompt information based on the local business process diagram, corresponding business configuration information and initial stored procedure dependency graph corresponding to the above-mentioned remaining code information group. Among them, the local business process diagram can be an execution flow chart between some businesses in each business corresponding to the target legacy system. The local business process diagram can be a business correspondence relationship with the remaining code information group. That is, the remaining code information in the remaining code information group can reflect the business execution logic between the corresponding businesses. The business configuration information can be the configuration information of each business corresponding to the local business process diagram. In practice, the business configuration information can include: business execution conditions, business execution time, and business execution parameters. The dependency graph prompt information can be a prompt word that prompts the target large language model to generate a stored procedure dependency graph based on the local business process diagram, business configuration information and the initial stored procedure dependency graph.

[0040] As an example, the graph processing end may fill the local business process graph, business configuration information, and the initial stored procedure dependency graph into the initial dependency graph prompt template to obtain dependency graph prompt information.

[0041] Sub-step 2: input the dependency graph prompt information into the target large language model to obtain a stored procedure dependency sub-graph.

[0042] In the fifth step, the obtained stored procedure dependency subgraph set is merged with the above initial stored procedure dependency graph to obtain the above stored procedure dependency graph.

[0043] As an example, the above-mentioned graph processing end can determine the code association relationship between the code information set corresponding to the metadata dependency and the remaining code information sets, merge the stored procedure dependency subgraph set and the above-mentioned initial stored procedure dependency graph, and obtain the above-mentioned stored procedure dependency graph.

[0044] In step 103 , the graph processing end decomposes the stored procedure dependency graph according to the input byte limit corresponding to the target large language model to obtain a set of stored procedure subgraphs with subgraph dependencies.

[0045] In some embodiments, the graph processing end may decompose the stored procedure dependency graph based on the input byte limit corresponding to the target large language model to obtain a set of stored procedure subgraphs with subgraph dependencies. The input byte limit may be a token limit for the input information corresponding to the target large language model. That is, different types of target large language models have different token limits for input information. The input byte limit may be a token limit corresponding to the large language model for the business. Token limits are essentially a balance between computational efficiency and expressiveness. Dependencies exist between the stored procedure subgraphs in the stored procedure subgraph set. The number of bytes corresponding to each stored procedure subgraph satisfies the input byte limit. The number of bytes corresponding to the stored procedure subset can be converted into a corresponding number of tokens using a relevant token conversion script. Thus, the tokens corresponding to the stored procedure subset satisfy the token limit corresponding to the input byte limit. The stored procedure subgraph may be a local graph in the stored procedure dependency graph. The target large language model may be a large language model for code logic understanding of the target legacy system. In practice, the target large language model may be a commonly used large language model in the market. Furthermore, the target large language model may be pre-trained with the system knowledge corresponding to the target legacy system, so that the target large language model can clearly understand the basic system knowledge and basic system framework corresponding to the target legacy system.

[0046] In some optional implementations of some embodiments, the graph processing end may decompose the stored procedure dependency graph according to the input byte limit corresponding to the target large language model to obtain a set of stored procedure subgraphs having dependency relationships between the subgraphs, including the following steps:

[0047] In the first step, the graph processing end performs the following steps to decompose the target storage layer in each storage layer corresponding to the stored procedure dependency graph:

[0048] Sub-step 1: In response to the target storage layer being the first layer in a stored procedure dependency graph, determining that the target storage layer corresponds to at least one stored procedure. The target storage layer may be the first layer in the stored procedure dependency graph. That is, the at least one stored procedure may be the stored procedure corresponding to the first node in the stored procedure dependency graph. The at least one stored procedure may be a stored procedure that has no predecessor node.

[0049] Sub-step 2: For each stored procedure in the at least one stored procedure, perform the following determination steps:

[0050] In the first sub-step, a sub-dependency graph is filtered out from the stored procedure dependency graph, in which the stored procedure is the head stored procedure and the corresponding storage layer number is the target layer number. Among them, the stored procedure corresponding to the head node in the sub-dependency graph is the head stored procedure. The target number of layers can be a preset number. Here, by setting the target number of layers, it is possible to avoid too many nodes corresponding to the sub-dependency graph, which may lead to the problem of the upper limit of the understanding of the target large language model in the subsequent process of generating code logic information for the target large language model due to the complexity of the code logic of the stored procedures corresponding to each node, causing the display page corresponding to the target large language model to freeze or report an error. Therefore, by setting the number of layers corresponding to the sub-dependency graph not to exceed the target number of layers, the problem of the upper limit of the understanding of the target large language model can be avoided. The target number of layers can be personalized based on the stored procedure dependency graph. For example, the target number of layers can be 5 layers.

[0051] In a second sub-step, in response to determining that the number of bytes of each code block corresponding to the sub-dependency graph meets the input byte limit, the sub-dependency graph is determined to be a stored procedure sub-graph corresponding to the above-mentioned stored procedure. The sub-dependency graph corresponds to each stored procedure. Each stored procedure has a corresponding code block. The number of bytes of each code block can be the total number of tokens corresponding to each code block.

[0052] In the third sub-step, in response to determining that the number of bytes of each code block corresponding to the sub-dependency graph does not meet the input byte limit and there is no pre-planned key code block binding information, the number of bytes corresponding to the code blocks are sequentially added according to the dependency order of the sub-dependency graph, until the total number of added bytes reaches the nearest number less than the number corresponding to the above-mentioned input byte limit, and the pruned sub-dependency graph is obtained. The key code block binding information can be the binding information for binding each key code block for subsequent synchronous code logic analysis and processing. In practice, the key code block binding information can be the configuration information for binding analysis of each key code block. For example, the configuration information corresponding to the key code block binding information can be "key code block A and key code block B perform code block synchronous binding analysis". The key code block binding information can be flexibly set on the relevant page. The key code block can be the code block corresponding to the key business. Among them, the pruned sub-dependency graph includes: the calling relationship between the node of the last layer and the next node (that is, the calling relationship between the stored procedure of the last layer and the stored procedure of the next call). As Figure 4 As shown, the pruned sub-dependency graph A can be "stored procedure A -> stored procedure B1, stored procedure A -> code block, stored procedure A -> code block, stored procedure A -> stored procedure B2." Here, "stored procedure A -> stored procedure B1" and "stored procedure A -> stored procedure B2" mentioned in the pruned sub-dependency graph A refer to the calling relationships between stored procedure A and stored procedure B1 and stored procedure B2, respectively. This allows the subsequent target large language model to understand the calling logic between the two.

[0053] Here, by setting the key code block binding information, the subsequent target large language model can be supported to perform targeted analysis on each code block corresponding to the key code block binding information, so as to improve the accuracy of the code logic under each code block. It should be noted that the key code block binding information corresponding to each key code block allows the subsequent target large language model to perform code logic analysis synchronously, and does not perform synchronous code logic analysis with other code blocks. The dependency order of the sub-dependency graph can be the flow relationship between the head node and the tail node in the sub-dependency graph. The sequential addition of the number of bytes corresponding to the code block can be the sequential superposition of the number of tokens corresponding to the code block. The nearest number of the number corresponding to the above-mentioned input byte limit can be the number of the sequential superposition of the number of tokens that is closest to the token limit corresponding to the input byte limit and is smaller than the token limit.

[0054] The fourth sub-step is to determine the pruned sub-dependency graph as the stored procedure sub-graph corresponding to the above-mentioned stored procedure.

[0055] Sub-step 3: removing the obtained at least one stored procedure sub-graph from the stored procedure dependency graph to obtain a post-removal stored procedure dependency graph.

[0056] In the second step, in response to determining that the total number of bytes corresponding to the removed stored procedure dependency graph does not meet the above-mentioned input byte limit, the graph processing end uses the removed stored procedure dependency graph as the stored procedure dependency graph and continues to execute the disassembly step.

[0057] Optionally, the above-mentioned adding of the number of bytes corresponding to the code blocks is performed in sequence according to the dependency order of the sub-dependency graph until the total number of added bytes reaches the nearest number that is less than the number corresponding to the above-mentioned input byte limit, thereby obtaining a pruned sub-dependency graph, including:

[0058] In the first step, in response to determining that the byte count of the code block corresponding to the first-level stored procedure at the first storage level in the sub-dependency graph does not meet the input byte limit, the code block in the first-level stored procedure is split to obtain a sequence of split code blocks. The splitting of the entire code block corresponding to the first-level stored procedure can be performed according to a predetermined code splitting logic.

[0059] The second step is to sequentially add the corresponding bytes of the split code blocks in the order of the split code block sequence until the total number of added bytes reaches the nearest number less than the number corresponding to the input byte limit. This generates a graph of the call relationships between the first-level stored procedure and the superimposed code block subsequence and subsequent stored procedures, which serves as the pruned sub-dependency graph. The superimposed code block subsequence can be a code block subsequence obtained by sequentially superimposing the split code blocks in the order of the sequence.

[0060] In some optional implementations of some embodiments, the key code block binding information is key code block binding information corresponding to at least one key business with a binding relationship. Each key business corresponds to at least one key code block. The key business can be set on a business configuration page, and the corresponding at least one key code block will also be displayed on the business configuration page.

[0061] Optionally, before determining the pruned sub-dependency graph as the stored procedure sub-graph corresponding to the stored procedure, the system further includes:

[0062] In the first step, in response to determining that the number of bytes of each code block corresponding to the sub-dependency graph does not meet the input byte limit and that pre-planned key code block binding information exists, the stored procedure group corresponding to the key code binding information is determined as a key dependency graph. The key dependency graph may be a dependency graph composed of stored procedure groups corresponding to each key business, representing the dependency relationships between the corresponding stored procedures. The stored procedure groups corresponding to the key code binding information may be each stored procedure involved in each key business.

[0063] Here, the stored procedure groups corresponding to the key dependency graphs are processed independently, so that the target large language model can subsequently accurately output the corresponding code logic information.

[0064] The second step is to remove the key dependency graph from the above sub-dependency graph to obtain the remaining dependency graph set.

[0065] As an example, each node and each edge in the key dependency graph can be removed from the sub-dependency graph to obtain a set of remaining dependency graphs.

[0066] In the third step, in response to determining that the number of bytes corresponding to the target residual dependency graph meets the input byte limit, the target residual dependency graph is determined as the stored procedure subgraph corresponding to the stored procedure, and the key dependency graph is used as the stored procedure subgraph corresponding to the next storage layer, wherein the target residual dependency graph is the residual dependency graph with the highest storage layer in the above residual dependency graph set.

[0067] In the fourth step, in response to determining that the number of bytes corresponding to the target residual dependency graph does not meet the input byte limit, the number of bytes corresponding to the code blocks are added sequentially according to the dependency order of the target residual dependency graph until the total number of added bytes reaches the nearest number that is less than the number corresponding to the above-mentioned input byte limit, thereby obtaining a pruned sub-dependency graph after being pruned from the above-mentioned target residual dependency graph.

[0068] In the fifth step, the pruned sub-dependency graph is determined as the stored procedure sub-graph corresponding to the above stored procedure.

[0069] Step 104: For each stored procedure subgraph, the server executes the generation steps:

[0070] Step 1041: Generate code logic understanding prompt information corresponding to the above-mentioned stored procedure subgraph according to the graph structure corresponding to the above-mentioned stored procedure subgraph.

[0071] In some embodiments, the server may generate code logic understanding prompt information corresponding to the stored procedure subgraph based on the graph structure corresponding to the stored procedure subgraph. The graph structure may be an identifier association structure of identifiers corresponding to each stored procedure included in the stored procedure subgraph. The code logic understanding prompt information may be text content that prompts the large language model to understand the code logic information of each stored procedure corresponding to the stored procedure subgraph. The stored procedure subgraph may be a subgraph within a stored procedure subgraph set. The server may be a server storing the large language model. The server is responsible for generating the prompt information and invoking the large language model.

[0072] As an example, the server can automatically select corresponding code logic comprehension prompt templates for different graph structure types. Then, the stored procedure subset corresponding to the stored procedure subgraph is input into the code logic comprehension prompt template to obtain code logic comprehension prompt information.

[0073] In some optional implementations of some embodiments, the code logic understanding prompt information corresponding to the above-mentioned stored procedure subgraph includes: the outer stored procedure corresponding to the stored procedure subgraph, the referenced stored procedure corresponding to the stored procedure subgraph, code logic understanding guide words, the code logic output example corresponding to the stored procedure, and the code block corresponding to the stored procedure subgraph. Among them, the outer stored procedure can be the stored procedure in the outermost layer of the subgraph corresponding to the highest storage layer level in the stored procedure subgraph. The referenced stored procedure can be the various stored procedures referenced by the stored procedure with the highest storage layer level (that is, the various subnodes under the node corresponding to the stored procedure with the highest storage layer level). The code logic understanding guide words can be guiding information for guiding the target large language model to perform code logic understanding of each stored procedure corresponding to the stored procedure subgraph. The code logic output example can be an example of how to output the corresponding code logic based on the stored procedure. The code block corresponding to the stored procedure subgraph can be the code block involved in each stored procedure corresponding to the stored procedure subgraph.

[0074] In some optional implementations of some embodiments, the server may generate code logic understanding prompt information corresponding to the stored procedure subgraph according to the graph structure corresponding to the stored procedure subgraph, including the following steps:

[0075] The first step is to query the prompt template cache to see if there is a prompt template corresponding to the above graph structure. The prompt template cache can cache various types of prompt templates.

[0076] In the second step, in response to determining that the image does not exist, a prompt content of a prompt template is generated according to the graph structure.

[0077] In the third step, the prompt content is input into the target large language model to generate a prompt template corresponding to the graph structure.

[0078] The fourth step is to store the prompt template and the corresponding graph structure in the prompt template cache.

[0079] The fifth step is to fill the stored procedure subgraph into the prompt template corresponding to the graph structure to obtain prompt information for understanding the code logic.

[0080] Step 1042: input the code logic understanding prompt information into the target large language model to obtain the code logic information in the target format.

[0081] In some embodiments, the server may input the code logic understanding prompt information into the target large language model to obtain code logic information in a target format. The target format may be JSON. The code logic information may represent the code logic of the stored procedure subset corresponding to the stored procedure subgraph. In practice, the code logic information may be textually representing the logic information of the execution content corresponding to the stored procedure subgraph.

[0082] In some optional implementations of some embodiments, the target large language model generates code logic information through the following steps:

[0083] The first step is to filter out at least one code block corresponding to the stored procedure subgraph from the above code logic prompt information.

[0084] In the second step, for each code block in at least one code block, perform the following generation steps:

[0085] Sub-step 1, query from the model input and output cache whether the set of code blocks understood in the historical time includes the above code block. The model input and output cache stores the code blocks and code block analysis information understood and analyzed by the target large language model in the historical time period. In addition, each understood and analyzed code block has a corresponding understanding and analysis frequency. The understanding and analysis frequency can characterize the frequency of the target large language model understanding and analyzing the code block. The understanding and analysis frequency corresponding to the corresponding code block is different according to the importance of the business. The more important the business is, the higher the corresponding understanding and analysis frequency. The correspondence between the importance of the business and the understanding and analysis frequency can be set by relevant technical personnel based on historical experience.

[0086] Here, the purpose of setting the understanding analysis frequency is to avoid the situation where the target large language model performs a single analysis on the code block and then experiences analysis hallucinations, which leads to unstable accuracy of the code logic information analysis.

[0087] Sub-step 2: In response to determining that the code block's corresponding understanding analysis frequency has not reached the corresponding frequency, setting the code block as the first code block to be re-understood and the understanding content verified. The understanding content verification can be performed by analyzing and verifying the understanding content (i.e., the code block understanding information) output by the target large language model to avoid the problem of analysis hallucination corresponding to the target large language model.

[0088] Sub-step 3: In response to determining that the code block includes and the understanding analysis frequency corresponding to the code block reaches the corresponding frequency, querying the model input and output cache for code block understanding information corresponding to the code block. The code block understanding information can be the result of the target large language model analyzing and understanding the code block at a historical time.

[0089] Sub-step 4: setting a second code block that does not need to be understood again and is understood based on the code block understanding information.

[0090] In the third step, for each first code block in the at least one first code block, perform the following replacement steps:

[0091] Sub-step 1: determine the calling functions in the first code block to obtain a calling function set.

[0092] Sub-step 2, for each calling function, search the model input and output cache to see whether there is a calling result corresponding to the calling function in the public function set. Among them, the model input and output cache also includes: the standard calling results of multiple executions of the calling function in historical time. Similarly, before the corresponding calling frequency of the calling function reaches the corresponding frequency, it is also necessary to call it to avoid the occurrence of calling hallucinations. After the corresponding calling frequency of the calling function reaches the corresponding frequency, the corresponding calling result of the calling function can be directly searched from the model input and output cache. When the corresponding calling frequency of the calling function reaches the frequency, the calling function can be set as a public function.

[0093] Sub-step 3: In response to determining that the function exists, add the calling result corresponding to the calling function to the comment corresponding to the calling function in the first code block to obtain the added first code block.

[0094] In the fourth step, the at least one added first code block and the at least one second code block are combined to obtain at least one combined code block.

[0095] In the fifth step, at least one code block in the code logic comprehension prompt information is replaced with at least one combined code block to obtain replaced code logic comprehension prompt information.

[0096] In the sixth step, the replaced code logic understanding prompt information is input into the target large language model to obtain the code logic information.

[0097] The above-mentioned "first step to sixth step" as one of the inventive points of the present disclosure solves another technical problem: "The target legacy system has a complex amount of code and complex code logic. In the process of analyzing the code logic information corresponding to each stored procedure subgraph, the target large language model has multiple understandings and multiple calls to the same code content or the same calling function, resulting in frequent and multiple waste of large model resources and low efficiency in generating code logic information." Based on this, the present disclosure can effectively achieve effective caching of large model input and output content by setting a model input and output cache. In the subsequent analysis of code blocks and calling functions, the query cache can be used to search first, avoiding multiple frequent analyses and multiple calls by the target large language model, and can efficiently and accurately generate code logic information.

[0098] Optionally, the server may generate code logic understanding prompt information corresponding to the stored procedure subgraph according to the graph structure corresponding to the stored procedure subgraph, including:

[0099] The first step is to determine a set of common code blocks and a set of common functions based on the stored procedure dependency graph and metadata. A common code block may be a code block with a higher call frequency than a first call frequency. A common function may be a function with a higher call frequency than a second call frequency. The first call frequency may indicate that the code block is frequently called multiple times. The second call frequency may indicate that the function is frequently called multiple times.

[0100] As an example, the server can use a script to count the call frequencies of each code block and each function based on the stored procedure dependency relationships reflected in the stored procedure dependency graph and the description information of each code block included in the metadata. Finally, the server selects code blocks with a call frequency greater than or equal to a first frequency from each code block as common code blocks, thereby obtaining a common code block set. The server also selects code blocks with a call frequency greater than or equal to a second frequency from each function as common functions, thereby obtaining a common function set.

[0101] In the second step, for each common code block in the common code block set, the following logic information generation steps are performed:

[0102] Sub-step 1: Generate code block logic generation prompt information, wherein the code block logic generation prompt information may represent prompt words for generating code block logic information corresponding to a common code block.

[0103] Sub-step 2: inputting the code block logic generation prompt information into the target large language model to obtain the common code block logic information.

[0104] Sub-step 3: Bind the code block identifier corresponding to the common code block with the common code block logic information to obtain common code block binding information.

[0105] The third step is to generate public function binding information corresponding to each public function in the public function set. The generation of public function binding information can refer to the generation of public code block binding information.

[0106] The fourth step is to determine at least one common code block identifier and at least one common function identifier corresponding to the above-mentioned stored procedure subgraph.

[0107] Step 5: Generate the code logic comprehension prompt information based on the at least one common code block binding information corresponding to the at least one common code block identifier, the at least one common function binding information corresponding to the at least one common function identifier, and the graph structure corresponding to the target stored procedure subgraph. The code logic comprehension prompt information includes at least one common code block binding information and at least one common function binding information.

[0108] Alternatively, as another inventive aspect of the present disclosure, another technical problem is addressed: "The target legacy system has complex code volume and code logic. When analyzing the code logic information corresponding to each stored procedure subgraph, the target large language model may interpret and call the same code content or the same calling function multiple times, resulting in frequent and multiple waste of large model resources and inefficient code logic information generation." Based on this, the present disclosure first accurately determines the common code block set and common function set in the target legacy system through metadata and stored procedure dependency graphs. Then, through separate logical analysis and call processing of the public code block set and the public function set, a common code block binding information set and a common function binding information set for direct subsequent use are generated. Finally, at least one common code block binding information and at least one common function binding information corresponding to the stored procedure subgraph are determined and subsequently incorporated into the code logic understanding prompt information. This allows the target large language model to generate code logic information quickly and efficiently without having to reinterpret the at least one common code block and at least one common function involved.

[0109] Step 105: The server generates a system-level code logic tree based on the obtained code logic information set.

[0110] In some embodiments, the server may generate a system-level code logic tree based on the obtained code logic information set. The system-level code logic tree may be a system-level tree representing the code logic for each business. In practice, each node in the system-level code logic tree may correspond to at least one stored procedure. The nodes in the system-level code logic tree may be code interpretation information for each business.

[0111] As an example, the server may construct each code logic information in the obtained code logic information set in a tree structure according to the dependencies of the stored procedures in the stored procedure subgraph and the graph dependencies between the stored procedure subgraphs to obtain a system-level code logic tree.

[0112] Optionally, the server may generate a system-level code logic tree based on the obtained code logic information set, which may include the following steps:

[0113] The first step is to generate a code block information matrix corresponding to each code block in the code logic information set based on the code block call information corresponding to the code logic information set. The matrix elements in the code block information matrix represent code block information. Adjacent code block information in a row of code block information vectors in the code block information matrix represents the sequential calling relationship of the corresponding code blocks. Adjacent code block information in a column of code block information vectors in the code block information matrix represents the parallel relationship of the code blocks. The code logic information is in JSON format. The code logic information may include call information for at least one code block corresponding to at least one code block logic and between code blocks. The call information may represent the call information of the code block corresponding to the prompt process. One piece of code logic information may be multiple code block elements in the code block information matrix. The code block information may be the identifier of a code block. The vector order of a row of code block information vectors corresponding to the code block information matrix may represent the sequential calling order. For example, if the vector order is from left to right, for two adjacent code block information, the code block corresponding to the code block information on the left will call the code block corresponding to the code block information on the right. Each adjacent code block information in a column of code block information vectors corresponds to a parallel code block in various calling situations corresponding to the previous code block.

[0114] like Figure 7 As shown, Figure 7 The call path matrix in is a code block information matrix. In the call path matrix, the code block in row 1, column 1 calls the code block in row 1, column 2. The code blocks in row 3, column 5, row 4, column 5, and row 6, column 5 are in parallel order. White matrix elements in the call path matrix represent corresponding code blocks, while gray matrix elements can be empty or white matrix elements above gray matrix elements.

[0115] The second step is to construct a system-level code logic tree corresponding to the code block information matrix according to the code block sequential calling relationship and code block parallel relationship corresponding to the code block information matrix.

[0116] Optionally, the server constructs a system-level code logic tree corresponding to the code block information matrix according to the code block sequential calling relationship and the code block parallel relationship corresponding to the code block information matrix, including the following steps:

[0117] In the first step, in response to determining that the code block calling relationship is the order from left to right corresponding to the code block information matrix, at least one code block information in the rightmost column is obtained. Figure 7 , the corresponding at least one code block information is "code block information at row 1 and column 6".

[0118] The second step is to generate at least one subtree corresponding to at least one code block information. For example, the at least one subtree may be "a subtree corresponding to the code block information at row 1 and column 6".

[0119] The third step is to execute the first tree generation step for at least one code block information:

[0120] Sub-step 1: For each code block information in the at least one code block information, perform the following second tree generation step:

[0121] In the first sub-step, in response to determining that the code block information has corresponding called code block information, has a code block calling relationship in sequence, and is in the previous column, and determining that the code block information does not have parallel code block information in a code block parallel relationship, the calling code block information is added to the subtree corresponding to the code block information to obtain the added subtree.

[0122] In the second sub-step, in response to determining that the code block information does not have corresponding called code block information, has a code block calling relationship in sequence, and is in the previous column, the subtree corresponding to the code block information is determined as the added subtree.

[0123] In the third sub-step, in response to determining that the code block information has corresponding called code block information, a code block calling relationship, or a previous column calling code block information, and determining that the code block information has parallel code block information, the calling code block information and at least one parallel code block information are added to the subtree corresponding to the code block information to obtain a subtree after addition. The child nodes of the node corresponding to the calling code block information in the subtree after addition are the node corresponding to the code block information and at least one child node corresponding to the at least one parallel code block information. Figure 7 , shows a schematic diagram of generating a system-level code logic tree. For the code block information in the fifth column, there are three parallel code block information. Then the child nodes of the node corresponding to the calling code block information in the fourth column are the three child nodes corresponding to the three parallel code block information.

[0124] Sub-step 2: in response to the previous column corresponding to at least one code block information being the first column, adding a common root node before the root node corresponding to at least one added subtree to obtain a system-level code logic tree.

[0125] In the fourth step, in response to the previous column corresponding to the at least one code block information being not the first column, at least one previous column of code block information corresponding to the at least one code block information is determined as the at least one code block information, and the first tree generation step is continued.

[0126] Optionally, the server may construct a system-level code logic tree corresponding to the code block information matrix according to the code block sequential calling relationship and the code block parallel relationship corresponding to the code block information matrix, which may include the following steps:

[0127] In the first step, the server may obtain a first node configuration corresponding to a sequential calling relationship of code blocks and a second node configuration corresponding to a parallel relationship of code blocks to generate an initial tree set. The first node configuration may be to use two code blocks in a preceding and following calling relationship as tree nodes, with the code block in the preceding column serving as the parent node of the code block in the following column. The second node configuration may be to use at least one parallel code block as three child nodes, with the corresponding code block in the preceding column serving as the parent node.

[0128] The second step is to add a common root node before the root node of each initial tree in the initial tree set to obtain a system-level code logic tree. The common root node can be the root node of each subtree corresponding to the common parent node.

[0129] In step 106 , in response to receiving the page display information for the system-level code logic tree, the display terminal displays the code blocks and code logic information of the system-level code logic tree on the target page in a cascade display manner or a hierarchical expansion manner.

[0130] In some embodiments, in response to receiving page display information for the system-level code logic tree, a display terminal progressively displays code blocks and code logic information from the system-level code logic tree on a target page in a cascading display or hierarchical expansion manner. The page display information may be a request for displaying the entire code logic system corresponding to the target legacy system. That is, the page display information may be a request to display the entire tree structure corresponding to the system-level code logic tree. Cascading display is a dynamic interactive mode where, after a user selects an option at a previous level, the system automatically updates the options at the next level based on the selection, forming a hierarchical dependency relationship. Hierarchical expansion displays parent-child relationships in a tree structure, allowing users to freely expand and collapse nodes to view sub-level content without requiring a fixed order of operations. The code blocks may be code blocks corresponding to stored procedures. It should be noted that by clicking a target node in the system-level code logic tree on the target page, the target-level child nodes under the target node can be expanded, displaying the code blocks and code logic information corresponding to the target node. The display terminal may be a display terminal that displays the system-level code logic tree or a business rule specification document. The display terminal will obtain the tree information of the system-level code logic tree sent by the server for subsequent display.

[0131] In some optional implementations of some embodiments, after step 106, the steps further include:

[0132] The first step is to parse the key code search information and / or key business search information in response to receiving the key code search information and / or key business search information entered into the corresponding search box on the target page to obtain key search information. The key search information may include, but is not limited to, at least one of the following: key code description terms and key business description terms. The key code description terms may be descriptive information about the key code logic corresponding to the node. The key code description terms may include: key code call information and key code logic. The key business description terms may be descriptive information about the business corresponding to the node. The key business description terms may include: business execution content and business execution scenario. The search box may be an input box set on the target page for searching nodes or code blocks. The key code search information may be the search text entered regarding the key code. The key business search information may be the search text entered regarding the key business.

[0133] The second step is to traverse the nodes in the system-level code logic tree to determine the node corresponding to the key search information as the target node.

[0134] In the third step, a subtree including at least one parent node and at least one child node centered on the target node is displayed on the target page.

[0135] Optionally, performing node traversal in the system-level code logic tree to determine a node corresponding to the key search information as a target node includes the following steps:

[0136] In the first step, for each node in the system-level code logic tree, perform the following embedding steps:

[0137] Sub-step 1: generating a key code description word set and a key business description word set corresponding to the node according to the node information and metadata corresponding to the node.

[0138] Sub-step 2: storing the association relationship between the key code description word set, the key business description word set, and the node identifier in a target cache.

[0139] The second step is to query the node identifier corresponding to the key search information from the target cache.

[0140] The third step is to determine the node corresponding to the node identifier as the target node.

[0141] This, as one of the inventive aspects of this disclosure, addresses another technical issue: the large number of nodes in the system-level code logic tree leads to inefficient node searches. Based on this, this disclosure provides a search box that supports input of information about key code blocks and key business operations. This allows for rapid search of target nodes based on the associations stored in the target cache, significantly improving tree search efficiency.

[0142] In some optional implementations of some embodiments, after step 106, the steps further include:

[0143] In the first step, the server selects at least one tree node from the system-level code logic tree for a key business or code block that meets the target code interpretation criteria. The key business can be configured on the business configuration page. The target code interpretation criteria can be a tree node for a code block whose corresponding interpretation information is unclear or whose semantic expression is inaccurate.

[0144] As an example, the user may select at least one tree node in the system-level code logic tree on the target configuration page through relevant operations to generate a business rule description document.

[0145] In the second step, the server obtains a set of business rule formula data tables, wherein the business rule formula data tables may be data tables storing rule formulas under different parameters and scenarios for various businesses.

[0146] In a third step, in response to determining that the code type corresponding to at least one tree node is a dynamic parameter type, the server performs the following document generation steps for each of the at least one tree node:

[0147] Sub-step 1: Query the corresponding data table information from the code block corresponding to the tree node. The data table information may represent the table identity information corresponding to the business rule formula data table. In practice, the data table information may be a data table identifier. The code type may be one of the following: dynamic parameter type or static parameter type. The dynamic parameter type may represent a code type that is dynamic SQL. The static parameter type may represent a code type that is static SQL.

[0148] In practice, a pre-written code type determination script can be used to determine the code type of the code block corresponding to at least one tree node. The code type determination script is a script set based on compilation timing, structural certainty, implementation method, and runtime behavior.

[0149] Sub-step 2: determining the business rule formula data table corresponding to the above data table information from the above business rule formula data table set as the target formula data table.

[0150] Sub-step 3: Generate prompt information for business rule description documents for the target formula data table and the code block. The prompt information for business rule description documents can prompt the target large language model to generate description documents for each rule under the business corresponding to the tree node and the business content based on the code logic corresponding to each rule formula and code block in the target formula data table.

[0151] Sub-step 4: inputting the prompt information for generating the business rule description document into the target large language model to obtain the business rule description document corresponding to the tree node.

[0152] In some optional implementations of some embodiments, after obtaining the business rule formula data table set, the steps further include:

[0153] In the first step, in response to determining that there is a tree node whose corresponding code type is a static parameter type in at least one tree node, at least one static tree node whose corresponding code type is a static parameter type is determined. The static tree node is a tree node whose corresponding code type is a static parameter type.

[0154] In the second step, at least one business rule description document corresponding to the at least one static tree node is generated using a business rule description document generation script.

[0155] Optionally, the target large language model parses the business rule description document to generate a formula in a target formula data table corresponding to the prompt information through the following steps:

[0156] The first step is to extract multiple formula application scenario identifiers from the code block as target formula application scenario identifiers.

[0157] The second step is to determine the formula representation information corresponding to the target formula application scenario identifier.

[0158] In the third step, in response to determining that the parsing frequency corresponding to the formula representation information is higher than the target frequency, the actual formula corresponding to the formula representation information is obtained from the formula parsing cache. The formula parsing cache may be a cache of parsed formulas for a period of time.

[0159] In the fourth step, in response to determining that the parsing frequency corresponding to the formula representation information is lower than or equal to the target frequency, the target large language model is used to perform formula parsing for the formula representation information to obtain the current formula.

[0160] The fifth step is to determine the actual formula corresponding to the formula represented by the above formula based on the historical formula sequence and the current formula obtained under the historical analysis frequency.

[0161] As an example, the formula with the highest occurrence frequency may be selected from the historical formula sequence and the current formula as the actual formula.

[0162] The sixth step is to store the corresponding identifier of the above formula representation information and the actual formula in the formula parsing cache.

[0163] Optionally, each actual formula in the formula parsing cache supports visual adjustment and supports iterative update as a formula template.

[0164] The above "Steps 1-6 and optionally" as another inventive point of this disclosure solves another technical problem: "The same formula may be called multiple times in different businesses, and the formula is written in database statement format. Multiple parsing by the target large language model will waste a lot of parsing resources." Based on this, the present disclosure sets a formula parsing cache and a parsing frequency corresponding to the formula representation information. After the parsing frequency corresponding to the formula representation information reaches a certain frequency, the actual corresponding formula can be generated for the formula representation information. Subsequent parsing does not need to be performed, which can greatly reduce the parsing resources of the target large language model for formula parsing and improve the efficiency of generating business rule documents.

[0165] In some optional implementations of some embodiments, the columns in the business rule formula data table include: multiple business rule formula identifiers and multiple formula application scenario identifiers. The column corresponding to each business rule formula identifier contains formula representation information in a database statement format for different formula application scenarios. Based on different combinations of formula application scenario identifiers, specific formula representation information is selected from the column corresponding to the business rule formula identifier. The business rule description document generation prompt information for the code block includes: prompt information for determining the business rule corresponding to the code block based on the business rule formula data table, examples of converting formula representation information in different database statement formats to a target formula text format, and the code block. The columns corresponding to the business rule formula identifier include: different calculation formulas for each formula application scenario. That is, the calculation formula for the corresponding application scenario can be located using the business rule formula identifier and the formula application scenario identifier. In practice, the formula application scenario identifier can represent the application scenario of the rule formula. The business rule formula identifier can represent the identity information of the business rule formula. Different database statement formats can include: NVL statement format, DECODE statement format, and CASE WHEN statement format. The target formula text format can be a LaTeX formula format. In practice, compound statements containing multiple layers of judgments are converted into nested LaTeX formula format. Addition and subtraction operations consisting of multiple judgment statements are converted into LaTeX formula format containing a combination of judgment conditions.

[0166] In some optional implementations of some embodiments, the server may generate prompt information for the target formula data table and the business rule description document for the code block, including the following steps:

[0167] The first step is to obtain an initial business rule description document generation prompt template, wherein the initial business rule description document generation prompt template may include: conversion examples that reflect the conversion of various types of database statement formats at the current time.

[0168] The second step is to generate a prompt template based on the above-mentioned formula data table, code block and the above-mentioned initial business rule description document, and use the target large language model to generate a prompt template for the business rule description document corresponding to the above-mentioned tree node. Among them, the target large language model supports determining the conversion example corresponding to at least one type of database statement format involved in the initial business rule description document generation prompt template according to the formula data table and code block. That is, the business rule description document generation prompt template includes: a conversion example corresponding to at least one type of database statement format. In addition, the target large language model can also support the generation of a corresponding conversion example of the target type of database statement format that does not exist in the initial business rule description document generation prompt template according to the formula data table and code block. The conversion example can be an example of converting the content of the database statement format.

[0169] As an example, the server may generate first prompt information to determine whether a formula data table and a code block correspond to at least one type of database statement format. The first prompt information and the initial business rule description document generation prompt template are input into the target large language model to obtain a preliminary business rule description document generation prompt template corresponding to the at least one type of database statement format. Subsequently, in response to determining that each type of database statement format in the preliminary business rule description document generation prompt template has a corresponding conversion example, the preliminary business rule description document generation prompt template is determined as the business rule description document generation prompt template corresponding to the tree node. Furthermore, in response to determining that each type of database statement format in the preliminary business rule description document generation prompt template does not have a corresponding conversion example, at least one type of database statement format that does not exist is determined as a target database statement format set. Furthermore, second prompt information is generated for examples corresponding to the target database statement format set. The second prompt information is input into the target large language model to obtain a conversion example set corresponding to the target database statement format set. The conversion example set is then added to the preliminary business rule description document generation prompt template to obtain an added template, which serves as the business rule description document generation prompt template corresponding to the tree node.

[0170] The third step is to fill the target formula data table and code block into the business rule description rule document to generate a prompt template.

[0171] The fourth step is to add the conversion example of the target type's database statement format that does not exist in the initial business rule description document generation prompt template to the above initial business rule description document generation prompt template as the added initial business rule description document generation prompt template.

[0172] In the fifth step, the added initial business rule description document generation prompt template is determined as the initial business rule description document generation prompt template.

[0173] The aforementioned "Steps 1-5," as one of the inventive features of this disclosure, address another technical issue: "The prompt template contains a large amount of redundant content, which may affect the output efficiency of the target large language model during subsequent output." Based on this, this disclosure customizes the prompt word template based on the target formula data table and code block, ensuring that the final matching prompt word template only includes conversion examples of at least one corresponding database statement format. This allows the target large language model to understand the content without excessive redundant information, thereby improving output efficiency.

[0174] In some optional implementations of some embodiments, after step 106, the steps further include:

[0175] The first step is to obtain system-level code update information from the code repository in response to receiving system iterative update information for the target legacy system. The system iterative update information may be information for updating the overall code performance of the target legacy system. The code repository is used to store code-related information in the target legacy system. For example, the code repository stores code information and incremental code information for each iterative version. The system-level code update information may include: stored procedure update information and code update transformation. The stored procedure update information may include at least one updated stored procedure in which the code has been transformed. The code update transformation may include: code transformation information corresponding to each updated stored procedure.

[0176] In the second step, for each update stored procedure corresponding to at least one update stored procedure in the stored procedure update information, perform the following generation steps:

[0177] Sub-step 1: Determine the code update transformation corresponding to the above-mentioned update stored procedure as the target code update transformation.

[0178] Sub-step 2: In response to determining that the target code update transformation involves replacing node relationships within the update stored procedure, obtaining at least one tree node dependency graph associated with the update stored procedure in the system-level code logic tree. The tree node dependency graph may represent dependency relationships between tree nodes. Each tree node in the tree node dependency graph is a tree node associated with the update stored procedure.

[0179] Sub-step 3: Obtain at least one impacting stored procedure corresponding to the target code update transformation. An impacting stored procedure may be a stored procedure that is affected by the code update transformation during the transformation of the updated stored procedure. For example, stored procedure A is a child node of stored procedure B. The code update transformation corresponding to stored procedure A adds stored procedure C to stored procedure A and stored procedure B. Therefore, stored procedure B increases the impact of stored procedure C. Therefore, stored procedure B is an impacting stored procedure.

[0180] Sub-step 4: Generate at least one impact node dependency graph corresponding to the at least one impact stored procedure. Here, if the impact stored procedure changes, the tree node corresponding to the impact stored procedure will also change. The impact node is the tree node affected by the change in the impact stored procedure. The impact node dependency graph can represent the dependency relationships between the various impact nodes involved. Similarly, the node directly affected by the impact stored procedure is the impact node. To ensure accuracy, each child node of the corresponding impact node is also determined to be an impact node.

[0181] Sub-step 5: Determine the dependency graph differences between at least one tree node dependency graph and at least one impact node dependency graph, and obtain a set of difference dependency graphs. The difference dependency graph can represent the dependency graph of difference nodes. A difference node is a node that requires code logic information adjustment and has a different code logic transformation from the corresponding historical node.

[0182] In the third step, each difference dependency graph in the obtained at least one difference dependency graph set is fused to obtain at least one fused graph, wherein the at least one fused graph can represent the association relationship between each node that undergoes transformation before and after the system iteration.

[0183] The fourth step is to determine the total number of bytes corresponding to each fusion graph in the at least one fusion graph. The total number of bytes corresponding to the fusion graph may be the total number of tokens corresponding to each impact storage process of the fusion graph.

[0184] In the fifth step, a first fused atlas whose total number of sub-nodes does not meet the input byte limit and a second fused atlas that meets the input byte limit are screened out from the at least one fused atlas.

[0185] Step 6: For each first fusion image, perform the following first information generation steps:

[0186] Sub-step 1: Generate code logic understanding prompt information corresponding to the first fusion graph according to the graph structure corresponding to the first fusion graph as first code logic understanding prompt information. The specific implementation method will not be repeated here.

[0187] Sub-step 2: input the above-mentioned first code logic understanding prompt information into the above-mentioned target large language model to obtain the code logic information corresponding to the above-mentioned first fusion graph as the first fusion code logic information.

[0188] Step 7: For each second fusion image, perform the following second information generation steps:

[0189] Sub-step 1: Decompose the second fusion graph according to the input byte limit corresponding to the target large language model to obtain a set of influencing storage process subgraphs where dependencies exist between the subgraphs.

[0190] Sub-step 2: For each impact stored process sub-graph in the impact stored process sub-graph set, perform the following third information generation step:

[0191] The first sub-step is to generate second code logic understanding prompt information according to the graph structure corresponding to the above-mentioned stored procedure sub-graph.

[0192] In the second sub-step, the second code logic understanding prompt information is input into the target large language model to obtain the second fusion code logic information corresponding to the affected stored procedure subgraph.

[0193] In step 8, at least one corresponding local-level code logic subtree is generated based on the first fused code logic information set and the second fused code logic information set. The local-level code logic subtree may be a subtree after system iteration that adjusts the local content in the system-level code logic tree.

[0194] In the ninth step, the subtree with changes in the system-level code logic tree is replaced with the at least one local-level code logic subtree, thereby obtaining a system-level code logic tree after system iteration.

[0195] The aforementioned "Steps 1-9," as one of the inventive features of this disclosure, address another technical problem: "When the target legacy system undergoes system iterations, regenerating the system-level code logic tree can be time-consuming due to the complex code size of the iterations. Furthermore, the target large language model may need to comb through the same code block multiple times, resulting in wasted model computation." Based on this, this disclosure first determines at least one tree node dependency graph and at least one impact node dependency graph to accurately identify at least one fusion graph representing the relationships between nodes that actually influence each other during the system iteration process. Then, based on the total number of bytes corresponding to each fusion graph, it further determines whether to perform graph segmentation to prevent the total number of bytes corresponding to the fusion graph from exceeding the input requirements and understanding limit of the target large language model, thereby facilitating the subsequent efficient and accurate generation of the corresponding fusion code logic information. Furthermore, based on the first fusion code logic information tree and the second fusion code logic information set, at least one local-level code logic subtree can be generated to represent each module that has changed during the system iteration process. Finally, by replacing at least one local-level code logic subtree, a system-level code logic tree can be accurately generated.

[0196] In some optional implementations of some embodiments, a jump control for a business rule description document is included in the tree node corresponding to the key business in the system-level code logic tree displayed on the target page. That is, by clicking the jump control, you can jump to the document display page corresponding to the key business, which displays the business rule description document. The document display page is a page that displays the business rule description document corresponding to the key business. The document display page displays, but is not limited to, at least one of the following: the code block corresponding to the key business, the business calculation logic corresponding to the key business, the business parameters corresponding to the key business, and the Chinese explanation of the business parameters. The business rule description document displayed on the document display page supports modification and saving. The document display page also displays a local subtree corresponding to the tree node corresponding to the key business. The local subtree can be a subtree within the system-level code logic tree. The node levels corresponding to the local subtree are predetermined. The target key business corresponding tree node is located at the middle node level within each node level. On the document display page, the content corresponding to the local subtree can be zoomed in and out by rotating the middle mouse wheel. By double-clicking the left button of the mouse, you can jump to the target page displaying the local subtree, that is, to display the focus of the corresponding area of ​​the local subtree in the system-level code logic tree.

[0197] After step 106, the steps further include:

[0198] In the first step, in response to clicking the business rule description document jump control of the tree node corresponding to the target key business in the system-level code logic tree displayed on the target page, the business rule description document corresponding to the target key business is displayed on the document display page.

[0199] In the second step, in response to the adjustment and save operation on the business computing logic corresponding to the target key business on the document display page, an impact node set corresponding to the business computing logic adjustment information is determined. The impact node set may be an empty set. The impact node may be a tree node affected by the business computing logic adjustment.

[0200] In a third step, in response to determining that the impact node set is empty, a code-related information generation prompt is generated for the business calculation logic and the original code block corresponding to the target key business. The code-related information generation prompt may be prompt content that prompts the target large language model to generate code-related information based on the business calculation logic and the original code block. The code-related information may include: the adjusted code block and the adjusted code logic information.

[0201] The fourth step is to input the prompt words generated by the above code-related information into the target large language model to obtain code-related information.

[0202] In the fifth step, the tree nodes corresponding to the target key business in the system-level code logic tree are adjusted to contain the code-related information, thereby obtaining an adjusted system-level code logic tree as the system-level code logic tree.

[0203] Step 6: Display the updated local tree with the target key business corresponding tree node as the center node in the updated system-level code logic tree in the area corresponding to the local subtree on the document display page.

[0204] The above-mentioned "first step to sixth step" as one of the inventive points of the present disclosure solves another technical problem "the problem of independent page interaction between the display page corresponding to the system-level code logic tree and the display page corresponding to the business rule description document, resulting in the system-level code logic tree and the business rule description document being maintained independently of each other." Based on this, the present disclosure, by developing a series of page interactions between target pages and the display pages corresponding to the business rule description documents, can increase the interaction between the two pages to achieve information synchronization between the business description information corresponding to the key business and the system-level code logic tree. In addition, after receiving the information for adaptive adjustment of the business calculation logic, it supports the use of the target large language model to adaptively and accurately update the calculation logic and code blocks of the business description document corresponding to the key business, and synchronize information on the system-level code logic tree, which can greatly improve the business maintenance efficiency of the key business.

[0205] like Figure 3 As shown in FIG, a schematic diagram of generating a code logic tree and a business rule description document is shown. Figure 3 As shown, first, for the target legacy system, we can analyze the stored procedures through metadata, dependencies, and stored procedure sets to obtain a stored procedure dependency graph. Then, based on the token restriction problem, we can subdivide the stored procedure dependency graph to obtain individual stored procedure dependency subgraphs. Then, for each stored procedure dependency subgraph, we generate a corresponding personalized code logic prompt (i.e., Figure 3 The resulting code logic prompts are input into the local LLM model (i.e., the target large language model) to generate a code logic information set in JSON format. Next, based on this code logic information set, code logic relationships are constructed to obtain a system-level code logic tree. Next, for key business and business rule formula data tables, business rule understanding prompts (i.e., business rule description document generation prompts) are generated. Using the local LLM model, business rule description documents corresponding to key business operations can be generated.

[0206] like Figure 4 As shown, a schematic diagram of graph decomposition of a stored procedure dependency graph is shown.

[0207] For the overall stored procedure dependency graph, the stored procedure dependency graph can be divided into: the stored procedure dependency subgraph corresponding to "stored procedure A, stored procedure B1, code block, code block and stored procedure B2", the stored procedure dependency subgraph corresponding to "stored procedure B1, code block and stored procedure C1", the stored procedure dependency subgraph corresponding to "stored procedure B2, code block and code block", and the stored procedure dependency subgraph corresponding to "stored procedure C1, code block, code block and stored procedure D1".

[0208] Figure 5 A schematic diagram of the system-level code logic tree is shown.

[0209] Figure 6 A schematic diagram showing a business rule description document is shown.

[0210] The above-mentioned embodiments of the present disclosure have the following beneficial effects: Through the code logic tree display system for legacy systems of some embodiments of the present disclosure, through the interactive cooperation between various system terminals, it is possible to achieve system-level code logic understanding and effective display of the corresponding tree structure in the case of complex and large code logic in the target legacy system. Specifically, the reason for the lack of accurate and efficient code logic understanding is that the system has been continuously updated by different R&D personnel for a long time, and the code volume is not only massive but also complex. As a result, the code logic understanding script cannot guarantee the accuracy of the logic understanding during the logic understanding process. Due to the large amount of code, the logic understanding process may be stuck and waste a long time. Based on this, the code logic tree display system for legacy systems of some embodiments of the present disclosure first obtains the metadata, dependency relationships, and stored procedure sets corresponding to the target legacy system. Here, using the metadata, dependency relationships, and stored procedure sets stored in the system cache, a preliminary understanding of the stored procedures can be accurately and effectively achieved, and a stored procedure dependency graph that reflects the dependencies between the stored procedures can be obtained. Then, the graph processing end can accurately generate the stored procedure dependency graph based on the metadata, dependency relationships, and stored procedure sets. By generating a stored procedure dependency graph, the subsequent effective partitioning of stored procedures based on input byte limits is facilitated. Next, the graph processing end accurately decomposes the stored procedure dependency graph based on the input byte limits of the target large language model, obtaining a set of stored procedure subgraphs with dependent subgraphs. Given the limited input bytes of the target large language model and the complex and massive code size of the target legacy system, the stored procedure dependency graph is used to effectively partition stored procedures, resulting in stored procedure subgraphs that meet the target large language model's input byte limits. Considering the target large language model's comprehension ceiling, if too much code information is input at once, the target large language model may experience comprehension issues exceeding this ceiling, resulting in lags and errors on the corresponding application pages. Thus, by rationally partitioning the stored procedure dependency graph based on the input byte limits, each resulting stored procedure subgraph corresponds to a stored procedure subset that not only meets the target large language model's input byte limits but also enables the target large language model to accurately understand the code logic within its own comprehension capabilities. Next, for each stored procedure subgraph in the stored procedure subgraph set, the server performs the following generation steps: First, based on the graph structure corresponding to the stored procedure subgraph, customized code logic comprehension prompt information for the stored procedure subgraph can be generated. Here, personalized code logic comprehension prompt information can be generated based on the graph structure of the stored procedure subgraph itself, facilitating the subsequent generation of accurate code logic information by the target large language model.In the second step, the code logic understanding prompt information is input into the target large language model, which can accurately generate code logic information in the target format while meeting the input byte limit corresponding to the target large language model and within the corresponding understanding range of the target large language model. Furthermore, the server generates a system-level code logic tree based on the obtained code logic information set. Here, through the generation and storage of the system-level code logic tree, it is convenient to view the code logic relationship corresponding to the target legacy system in real time. Through the logical understanding of the system-level code logic relationship in the form of a tree structure, the code logic under each business can be quickly located and viewed. Finally, in response to receiving the page display information for the system-level code logic tree, the display end displays the code blocks and code logic information of the system-level code logic tree on the target page in a cascade display method or a hierarchical expansion method. Here, through the display of code blocks and code logic information, the processing object can clearly understand the code blocks and code logic of the target legacy system under each business. In summary, through the interactive cooperation between various terminals in the system, the stored procedure dependency graph is accurately generated, so that the stored procedure set can be reasonably divided according to the input byte limit of the target large language model. This allows the target large language model to accurately generate the code logic information of the stored procedure subgraph within its own understanding range and input limits, so that the system-level code logic tree can be accurately generated.

[0211] Reference below Figure 2 , which shows a structural diagram of an electronic device 200 suitable for implementing some embodiments of the present disclosure. Figure 2 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0212] like Figure 2 As shown, electronic device 200 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 201, which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 202 or programs loaded from a storage device 208 into a random access memory (RAM) 203. Various programs and data required for the operation of electronic device 200 are also stored in RAM 203. Processing device 201, ROM 202, and RAM 203 are connected to each other via a bus 204. An input / output (I / O) interface 205 is also connected to bus 204.

[0213] Typically, the following devices may be connected to the I / O interface 205: an input device 206 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 207 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 208 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 209. The communication device 209 may allow the electronic device 200 to communicate with other devices wirelessly or by wire to exchange data. Figure 2 The electronic device 200 is shown with various devices, but it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed instead. Figure 2 Each block shown in the figure may represent one device, or may represent multiple devices as needed.

[0214] In particular, according to some embodiments of the present disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the system shown in the flowchart. In some such embodiments, the computer program can be downloaded and installed from a network via the communication device 209, or installed from the storage device 208, or installed from the ROM 202. When the computer program is executed by the processing device 201, the above-mentioned functions defined in the system of some embodiments of the present disclosure are performed.

[0215] It should be noted that in some embodiments of the present disclosure, the computer-readable medium described above may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable storage media may include, but are not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or components, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more conductors, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In some embodiments of the present disclosure, a 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, device, or component. Furthermore, in some embodiments of the present disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. This propagated data signal may take a variety of forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wire, optical cable, RF (radio frequency), or any suitable combination thereof.

[0216] In some embodiments, the client and server can communicate using any currently known or later developed network protocol, such as HTTP (HyperText Transfer Protocol), and can be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or later developed network.

[0217] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device. The computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: obtain metadata, dependencies, and stored procedure sets corresponding to the target legacy system; generate a stored procedure dependency graph based on the metadata, dependencies, and stored procedure sets; decompose the stored procedure dependency graph based on the input byte limit corresponding to the target large language model to obtain a stored procedure subgraph set in which each subgraph has a dependency relationship; for each stored procedure subgraph in the stored procedure subgraph set, execute a generation step: generate code logic understanding prompt information corresponding to the stored procedure subgraph based on the graph structure corresponding to the stored procedure subgraph; input the code logic understanding prompt information into the target large language model to obtain code logic information in a target format; generate a system-level code logic tree based on the obtained code logic information set; and, in response to receiving page display information for the system-level code logic tree, gradually display the code blocks and code logic information of the system-level code logic tree on the target page in a cascade display manner or a hierarchical expansion manner.

[0218] Computer program code for performing the operations of some embodiments of the present disclosure may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone 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 a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0219] The flow charts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, systems and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the prescribed logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the prescribed function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0220] The units described in some embodiments of the present disclosure may be implemented in software or in hardware. The described units may also be provided in a processor. For example, they may be described as follows: a processor includes an acquisition unit, a first generation unit, a disassembly unit, a second generation unit, a third generation unit, and a display unit. The names of these units do not, in some cases, constitute a limitation on the units themselves. For example, the acquisition unit may also be described as a "unit for acquiring metadata, dependencies, and stored procedure sets corresponding to the target legacy system."

[0221] The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, and without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0222] The above descriptions are merely some preferred embodiments of the present disclosure and illustrate the underlying technical principles. Those skilled in the art should understand that the scope of the invention encompassed by the embodiments of the present disclosure is not limited to technical solutions formed by specific combinations of the aforementioned technical features. It also encompasses other technical solutions formed by any combination of the aforementioned technical features or their equivalents, without departing from the aforementioned inventive concept. For example, a technical solution formed by replacing the aforementioned features with (but not limited to) technical features with similar functions disclosed in the embodiments of the present disclosure.

Claims

1. A code logic tree display system for legacy systems, comprising: The system cache obtains metadata, dependencies, and stored procedure sets corresponding to the target legacy system; The graph processing end generates a stored procedure dependency graph according to the metadata, the dependency relationship and the stored procedure set; The graph processing end performs graph disassembly on the stored procedure dependency graph according to the input byte limit corresponding to the target large language model to obtain a set of stored procedure subgraphs with subgraphs having dependency relationships. The graph processing end performs graph disassembly on the stored procedure dependency graph according to the input byte limit corresponding to the target large language model to obtain a set of stored procedure subgraphs with subgraphs having dependency relationships, including: for the target storage layer in each storage layer corresponding to the stored procedure dependency graph, the graph processing end performs a disassembly step: in response to the target storage layer being the first layer in the stored procedure dependency graph, determining that the target storage layer corresponds to at least one stored procedure; for each stored procedure in the at least one stored procedure, performing a determination step: filtering out a sub-dependency graph whose storage layer number is the target number of layers and whose stored procedure is the head stored procedure from the stored procedure dependency graph; in response to determining that the number of bytes of each code block corresponding to the sub-dependency graph meets the input In response to determining that the number of bytes of each code block corresponding to the sub-dependency graph does not meet the input byte limit and there is no pre-planned key code block binding information, the number of bytes corresponding to the code blocks is sequentially added according to the dependency order of the sub-dependency graph until the total number of added bytes reaches the nearest number less than the number corresponding to the input byte limit, thereby obtaining a pruned sub-dependency graph; determining the pruned sub-dependency graph as the stored procedure sub-graph corresponding to the stored procedure; removing at least one obtained stored procedure sub-graph from the stored procedure dependency graph to obtain a post-removal stored procedure dependency graph; in response to determining that the total number of bytes corresponding to the post-removal stored procedure dependency graph does not meet the input byte limit, the graph processing end uses the post-removal stored procedure dependency graph as the stored procedure dependency graph and continues to execute the disassembly step; For each stored procedure subgraph, the server performs the following build steps: Generate code logic understanding prompt information corresponding to the stored procedure subgraph according to the graph structure corresponding to the stored procedure subgraph; Inputting the code logic understanding prompt information into the target large language model to obtain the code logic information in the target format; The server generates a system-level code logic tree based on the obtained code logic information set; In response to receiving the page display information for the system-level code logic tree, the display end gradually displays the code blocks and code logic information of the system-level code logic tree on the target page in a cascade display manner or a hierarchical expansion manner.

2. The system according to claim 1, wherein: The system further comprises: The server selects at least one tree node of a key business or code block that meets the target code interpretation condition from the system-level code logic tree; The server obtains a business rule formula data table set; In response to determining that the code type corresponding to at least one tree node is a dynamic parameter type, the server performs a document generation step for each of the at least one tree node: Query the corresponding data table information from the code block corresponding to the tree node; Determine the business rule formula data table corresponding to the data table information from the business rule formula data table set as the target formula data table; Generate prompt information for generating the target formula data table and the business rule description document of the code block; The business rule description document generation prompt information is input into the target large language model to obtain the business rule description document corresponding to the tree node.

3. The system according to claim 1, wherein: The code logic understanding prompt information corresponding to the stored procedure subgraph includes: the outer stored procedure corresponding to the stored procedure subgraph, the referenced stored procedure corresponding to the stored procedure subgraph, code logic understanding guide words, the code logic output example corresponding to the stored procedure, and the code block corresponding to the stored procedure subgraph.

4. The system according to claim 2, wherein: The columns in the business rule formula data table include: multiple business rule formula identifiers and multiple formula application scenario identifiers. The column content corresponding to each business rule formula identifier is the formula representation information in the database statement format under different formula application scenarios. Based on different combinations of formula application scenario identifiers, specific formula representation information in the column content corresponding to the business rule formula identifier is selected. The business rule description document of the code block generates prompt information including: determining the prompt information of the business rule corresponding to the code block based on the business rule formula data table, examples and code blocks for converting the formula representation information in different types of database statement formats into the target formula text format.

5. The system according to claim 1, wherein: The server generates a system-level code logic tree according to the obtained code logic information set, including: The server generates a code block information matrix corresponding to each code block in the code logic information set based on the code block call information corresponding to the code logic information set, wherein the matrix elements in the code block information matrix are code block information, adjacent code block information in a row of code block information vectors in the code block information matrix represents a sequential calling relationship of corresponding code blocks, and adjacent code block information in a column of code block information vectors in the code block information matrix represents a parallel relationship of code blocks; The server constructs a system-level code logic tree corresponding to the code block information matrix according to the code block sequential calling relationship and the code block parallel relationship corresponding to the code block information matrix.

6. The system according to claim 1, wherein: The graph processing end generates a stored procedure dependency graph according to the metadata, the dependency relationship, and the stored procedure set, including: Generate an initial stored procedure dependency graph based on the metadata and the dependency relationship; Performing code scanning on the stored procedure set to filter out remaining code information sets that do not exist in the initial stored procedure dependency graph; Dividing each piece of residual code information in the residual code information set according to the number of bytes corresponding to each piece of residual code information to obtain a residual code information group set, wherein the residual code information in each residual code information group has a code association relationship, and the total number of bytes corresponding to the residual code information group meets the input byte limit; For each remaining code information group, perform the following entry steps: Generate dependency graph prompt information according to the local business process graph corresponding to the remaining code information group, the corresponding business configuration information and the initial stored procedure dependency graph; Inputting the dependency graph prompt information into the target large language model to obtain a stored procedure dependency subgraph; The obtained stored procedure dependency subgraph set and the initial stored procedure dependency graph are merged to obtain the stored procedure dependency graph.

7. The system according to claim 1, wherein: The key code block binding information is key code block binding information corresponding to at least one key business having a binding relationship; as well as Before determining the pruned sub-dependency graph as the stored procedure sub-graph corresponding to the stored procedure, the system further includes: In response to determining that the number of bytes of each code block corresponding to the sub-dependency graph does not meet the input byte limit and there is pre-planned key code block binding information, determining the stored procedure group corresponding to the key code binding information as a key dependency graph; Remove the key dependency graph from the sub-dependency graph to obtain a set of remaining dependency graphs; In response to determining that the number of bytes corresponding to the target residual dependency graph satisfies the input byte limit, determining the target residual dependency graph as a stored procedure subgraph corresponding to the stored procedure, and using the key dependency graph as a stored procedure subgraph corresponding to a next storage layer, wherein the target residual dependency graph is a residual dependency graph with the highest storage layer in the residual dependency graph set; In response to determining that the number of bytes corresponding to the target residual dependency graph does not meet the input byte limit, sequentially adding the number of bytes corresponding to the code blocks according to the dependency order of the target residual dependency graph until the total number of added bytes reaches the nearest number less than the number corresponding to the input byte limit, thereby obtaining a pruned sub-dependency graph pruned from the target residual dependency graph; The pruned sub-dependency graph is determined as the stored procedure sub-graph corresponding to the stored procedure.

8. An electronic device comprising: one or more processors; a storage device having one or more programs stored thereon, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 6.

9. A computer-readable medium having a computer program stored thereon, wherein: When the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Citation Information

Patent Citations

  • Business scene dependency graph generation method and computer equipment

    CN117251202A

  • Big language model logical reasoning method and device, equipment, storage medium and product

    CN119378691A