Multi-page linkage code generation system and method based on decision tree and dependency graph

Abstract

This invention relates to a multi-page interactive code generation system based on decision trees and dependency graphs. The system includes a requirements parsing module, which is connected to both a decision tree construction module and a dependency graph construction module. The decision tree construction module is connected to a rule mapping module, the dependency graph construction module is connected to the rule mapping module, the rule mapping module is connected to a code generation module, and the code generation module is connected to a template library storage module. The multi-page interactive code generation method based on decision trees and dependency graphs includes: constructing a structured requirements model; decomposing interaction logic and generating decision tree execution rules; clarifying page relationships, defining dependency constraints, and constructing a dependency graph; and combining rules and dependencies to generate code. This multi-page interactive code generation system and method, by decomposing interaction logic using decision trees and managing page dependencies using dependency graphs, achieves automated generation of multi-page interactive code, significantly reducing manual coding workload and shortening the development cycle.

Description

Technical Field

[0001] The present invention belongs to the technical field of code generation, and relates to a multi-page linkage code generation system based on a decision tree and a dependency graph, and also relates to a multi-page linkage code generation method based on a decision tree and a dependency graph. Background Art

[0002] With the increasing complexity of front-end applications, multi-page linkage scenarios are becoming more and more common. For example, the linkage between the product list page, product details page, and shopping cart page of an e-commerce platform, and the linkage between the form filling page, review page, and result display page of an e-government system. The traditional multi-page linkage code development method mainly relies on developers to write manually, and there are the following problems: low development efficiency: the multi-page linkage logic is complex, and developers need to write page interaction, data transmission, and status synchronization code line by line, resulting in a long development cycle; high logical coupling degree: the linkage logic between pages is scattered in the code of each page, lacking structured control, and modifying the logic of one page may affect multiple associated pages; high maintenance cost: the code lacks unified logical sorting, and when troubleshooting problems and modifying requirements later, a lot of time is required to sort out the dependency relationships between pages; poor consistency: the coding styles and logical implementation methods of different developers are different, making it difficult to ensure the consistency of multi-page linkage code and prone to logical conflicts.

[0003] In the prior art, some code generation tools can only generate the basic code of a single page and cannot handle multi-page linkage logic; some code generation methods based on flowcharts are difficult to accurately disassemble complex conditional branch interaction logic and cannot effectively control the dependency relationships between pages. Therefore, there is an urgent need for a code generation method that can structurally disassemble multi-page linkage logic and control page dependency relationships to improve the generation efficiency and maintainability of multi-page linkage code. Summary of the Invention

[0004] The purpose of the present invention is to provide a multi-page linkage code generation system based on a decision tree and a dependency graph, which solves the problems of low development efficiency, high logical coupling degree, and high maintenance cost existing in the traditional multi-page linkage code development in the prior art.

[0005] Another purpose of the present invention is to provide a multi-page linkage code generation method based on a decision tree and a dependency graph.

[0006] The technical solution adopted by the present invention is that a multi-page linkage code generation system based on a decision tree and a dependency graph includes a requirement analysis module, the requirement analysis module is respectively connected to a decision tree construction module and a dependency graph construction module, the decision tree construction module is connected to a rule mapping module, the dependency graph construction module is connected to the rule mapping module, the rule mapping module is connected to a code generation module, and the code generation module is connected to a template library storage module.

[0007] The invention is further characterized by:

[0008] The requirement parsing module includes a requirement receiving unit and a structured parsing unit connected in sequence; the requirement receiving unit is used to receive multi-page linkage business requirements from external input, and the structured parsing unit parses and processes the original requirement data.

[0009] The decision tree construction module includes a node construction unit, a pruning optimization unit, and a rule output unit connected in sequence. The node construction unit is connected to the structured parsing unit. The node construction unit includes: a page identification subunit that extracts all page nodes from the structured requirement model and determines the root node of the decision tree and candidate page nodes at each level; a condition extraction subunit that extracts all interaction trigger conditions from the requirement model as branch features of the decision tree; a branch generation subunit that generates decision branches according to whether the conditions are met or not, and binds corresponding linkage behaviors to each branch; and a tree structure generation subunit that recursively generates a complete initial decision tree structure according to the hierarchical relationship of the root node, intermediate nodes, and leaf nodes. The pruning and optimization unit includes: a redundant branch identification subunit that traverses the decision tree and identifies redundant branches that have no actual linkage effect or corresponding page behavior; a conflict branch detection subunit that detects logically contradictory and mutually exclusive condition branches in the decision tree; and a tree structure simplification subunit that deletes redundant branches, merges duplicate conditions, and corrects conflicting logic to form a simplified and executable decision tree. The rule output unit includes: a tree traversal subunit that reads each complete path from the root node to a leaf node; a rule formatting subunit that converts each path into a structured rule, in the format of trigger page + trigger condition + action + target page; and a rule output interface subunit that organizes all rules into a unified format and outputs them to the rule mapping module.

[0010] The dependency graph construction module includes a dependency extraction unit, a dependency verification unit, and a topology sorting unit connected in sequence. The dependency extraction unit includes: a page node parsing subunit that reads all page identifiers from the structured requirement model and establishes a set of page nodes for the dependency graph; a trigger dependency identification subunit that extracts trigger relationships between pages from interactive behaviors and decision tree branches, identifying which page's behavior triggers which page's linkage, forming trigger dependency edges; a data dependency identification subunit that extracts data transfer relationships between pages from the data flow rules of the requirement model, determining the data source page, data target page, transfer fields, and direction, forming data dependency edges; a rendering dependency identification subunit that identifies rendering order constraints between pages, determining which pages must complete operations on another page before they can be loaded or updated, forming rendering dependency edges; and a dependency graph initialization subunit that combines the above page nodes with the three types of dependency edges to construct an initial multi-page dependency graph. The dependency verification unit includes: a loop detection subunit that traverses the dependency graph's dependency edges to detect the existence of circular dependencies between pages, marking them as abnormal dependencies if they exist; an isolated node detection subunit that checks for isolated page nodes that have no dependencies and do not participate in the interaction, marking or filtering isolated nodes; a dependency validity determination subunit that determines the reasonableness of dependency relationships: whether triggering dependencies have corresponding interactive behaviors, whether data dependencies have clear fields and transmission directions, and whether rendering dependencies conform to page loading logic; and an anomaly correction subunit that removes or corrects detected loops, conflicts, and illegal dependencies, outputting a valid dependency graph that is legal and conflict-free. The topology sorting unit includes: an in-degree calculation subunit that calculates the in-degree of each page node in the legal dependency graph to determine the dependency priority of the node; a topology sequence generation subunit that uses the topology sorting algorithm to generate the execution sequence of pages according to the principle of prioritizing dependent pages and reserving dependent pages; a code generation order determination subunit that converts the topology sequence into the code generation order; and a sorting result output subunit that encapsulates the legal dependency graph and the topology sorting result into unified dependency relationship data for output.

[0011] The rule mapping module includes a multi-source data receiving unit, a mapping relationship establishment unit, a code generation rule definition unit, a rule verification unit, and a rule output unit connected in sequence. The multi-source data receiving unit includes: a decision tree rule receiving subunit, which receives a set of structured interactive logic execution rules from the rule output unit of the decision tree construction module, parses the core parameters of each rule, and converts the rule format into a unified JSON format, where each parameter corresponds to a clear key-value pair. It also filters invalid rules and outputs a standardized set of decision tree rules. A dependency relationship data receiving subunit receives the final dependency relationship data containing the topological order from the topology sorting unit of the dependency graph construction module. It extracts two types of core information—dependency type, dependency direction, and associated parameters between pages—and the code generation order generated by the topology sorting, performs structured processing, and associates and binds the dependency relationships with the page order to form a three-dimensional mapping table of page identifier, dependency relationship, and sorting priority. A code template information receiving subunit receives front-end framework code template metadata from the template classification and retrieval unit of the template library storage module. It extracts the core information of the template—template identifier, adapting framework, template type, replaceable parameters, and parameter placeholders—and establishes a template metadata index table. The mapping relationship establishment unit includes: a decision tree and dependency mapping subunit that uses page identifier and interaction action as dual primary keys to bind standardized decision tree rules with dependencies in the three-dimensional mapping table, clarifying the dependency constraints that the interaction rule must follow, and generating decision tree rule-dependency mapping pairs; a mapping pair and code template matching subunit that retrieves the code template metadata index table based on the core parameters of the decision tree rule-dependency mapping pair and matches the corresponding code template; if no matching template is found, a template missing prompt is output; and a mapping relationship storage subunit that stores the matched decision tree rule-dependency-code template three-dimensional mapping relationship to a temporary database within the module, establishes a mapping relationship index, and records mapping matching logs.

[0012] The code generation rule definition unit includes: a basic rule definition subunit that defines general basic rules for code generation, including rules for calling code templates, parameter substitution rules, and code formatting specifications; an interaction logic rule definition subunit that defines specific interaction logic generation rules for each decision tree rule-dependency-code template mapping pair; an execution order rule definition subunit that defines the execution order rules for code generation based on the page order generated by topological sorting; and a rule standardization subunit that organizes the defined basic rules, interaction logic rules, and execution order rules into a unified JSON format code generation rule set. The rule validation unit includes: a rule validity validation subunit that checks whether the format of the code generation rules conforms to standardization requirements, whether the rule content is valid, and whether the associated mapping relationship exists. If an anomaly is found, the anomaly type is marked and a correction suggestion is output; a rule logic validation subunit that checks whether there are logical conflicts between rules and the compatibility between rules and code templates; a validation result processing subunit that marks the validated code generation rules and organizes them into a set of valid code generation rules; and for rules that fail validation, an anomaly report is output and fed back to the mapping relationship establishment subunit and the rule definition subunit for correction and re-validation until all rules pass validation. The rule output unit includes: a rule formatting output subunit that converts the set of valid code generation rules into a format that the code generation module can directly parse, and adds auxiliary information; and a rule backup and log subunit that backs up the output valid code generation rules and records the rule output log.

[0013] The code generation module includes an input data receiving unit, a rule parsing unit, a template calling unit, a parameter replacement unit, a code integration unit, and a code output unit, which are connected in sequence. The input data receiving unit includes: a rule generation receiving subunit that receives a standardized and parsable valid code generation rule set from the rule output unit of the rule mapping module, verifies whether the rule format is compatible with the module interface and whether the rule parameters are complete, marks incomplete rules, converts the format of rules that do not match, and outputs a set of adapted valid code generation rules; and a code template receiving subunit that receives front-end framework code templates from the template classification and retrieval unit of the template library storage module, verifies the integrity of the templates, extracts the core structure of the templates, classifies and stores them according to template type, and outputs a set of standardized code templates that can be directly called. The rule parsing unit includes: an execution order parsing subunit that parses the execution order parameters in the code generation rules, extracts the page generation order determined by the topology sorting, and establishes a page identifier-generation priority mapping table; an interaction logic parsing subunit that parses the interaction logic parameters in each rule, extracts core information, and organizes it into an interaction logic parameter table; and a template matching parsing subunit that parses the template identifier parameters in each rule, associates them with the categorized and stored code template sets, determines the specific code template corresponding to each interaction logic, and generates a rule identifier-template identifier-template path association table. The template invocation unit includes: a template retrieval and invocation subunit that, based on the rule identifier-template identifier-template path association table, retrieves and invokes the corresponding code templates sequentially according to the page generation priority order; simultaneously, for each interaction logic, it invokes the corresponding interaction template and loads the template into the module's temporary memory for subsequent parameter replacement; and a template compatibility verification subunit that, after invoking the code template, verifies the compatibility between the template and the interaction logic parameters. If the compatibility fails, it outputs a compatibility exception report and feeds it back to the rule parsing subunit for re-matching the template.

[0014] The parameter replacement unit includes: a placeholder recognition subunit that traverses the loaded code template, identifies all replaceable placeholders in the template, and establishes a placeholder-template position mapping table; a parameter matching and replacement subunit that, based on the placeholder-template position mapping table and the interaction logic parameter table, replaces the corresponding parameter values ​​into the placeholders in the template; and a replacement result verification subunit that, after the replacement is completed, verifies the accuracy of the replacement result, marks code segments that fail verification, and feeds back to the placeholder recognition subunit for re-replacement. The code integration unit includes: a page order integration subunit that generates a priority mapping table based on page identifiers and integrates single-page code snippets in order; a linkage logic association subunit that adds linkage logic association code between pages based on the interaction logic parameter table; and a code format standardization subunit that standardizes the format of the integrated multi-page code, unifies code indentation, comment format, variable naming conventions, and removes redundant code. The code output unit includes: the code packaging subunit, which packages a standardized collection of complete multi-page cascading code according to front-end project specifications to generate a code package that can be directly deployed. The code package includes page files, style files, and interaction files, and also generates code package documentation; the output log and backup subunit records the code output log; and also backs up the generated code package.

[0015] Another technical solution adopted in this invention is a multi-page linkage code generation method based on decision trees and dependency graphs, comprising the following steps: Step 1: Construct a structured requirements model; Step 2: Decompose the interaction logic and generate decision tree execution rules; Step 3: Analyze page relationships, clarify dependency constraints, and build a dependency graph; Step 4: Combine rules and dependencies to automatically generate code.

[0016] Another feature of the technical solution of this invention is that: Step 1 includes: Step 1.1, Requirement Input: The requirement receiving unit receives multi-page linkage business requirements and performs preliminary screening of the input requirements. Step 1.2, Requirements Extraction: The original input requirements are structured and parsed through the structured parsing unit. The page recognition subunit, interaction behavior extraction subunit, and data flow parsing subunit within this unit work together to extract key information one by one and organize the structured key information into a structured requirement model in a unified format. The model output unit will synchronously distribute the completed structured requirement model to the decision tree construction module and the dependency graph construction module. Key information includes: page set, interaction behavior, data flow rules, rendering constraints, and structured requirement model including page node set, interaction behavior set, trigger condition set, data dependency set, and rendering constraint set; Step 2 includes: Step 2.1, Node Definition and Initialization: The page identification subunit, condition extraction subunit, branch generation subunit, and tree structure generation subunit within the node construction unit work together to complete the initial node definition of the decision tree, with the triggering page of multi-page linkage as the root node, the interaction triggering condition as the intermediate branch node, and the linkage behavior of the target page as the leaf node. Step 2.2, Branch Rule Generation and Pruning Optimization: The node construction unit extracts all interaction trigger conditions from the structured requirement model as candidate branch features. Based on the execution logic correlation of the interaction behavior, it determines the optimal trigger conditions at each level and generates corresponding intermediate nodes. According to the binary branch logic of the trigger conditions being met / not met, it splits the branches of each intermediate node, maps the page linkage behavior matched by each branch to leaf nodes, and recursively executes this process to generate an unpruned initial interaction decision tree. The redundant branch identification subunit, conflict branch detection subunit, and tree structure simplification subunit within the pruning optimization unit work together to traverse the initial decision tree, identify and delete redundant branches, detect and correct conflict branches, merge duplicate conditions, and generate an optimized decision tree. Step 2.3, Rule Standardization and Output: The tree traversal subunit, rule formatting subunit, and rule output interface subunit within the rule output unit work together to perform a depth-first traversal of the optimized decision tree, read each complete path from the root node to the leaf node, transform each path into a set of structured interactive logic execution rules in the format of trigger page + trigger condition + execution action + target page, and output the rule set to the subsequent rule mapping module. Step 3 includes: Step 3.1, Node and Dependency Edge Extraction: The page node parsing subunit, trigger dependency identification subunit, data dependency identification subunit, and rendering dependency identification subunit within the dependency extraction unit work together to extract the trigger dependency relationship, data dependency relationship, and rendering dependency relationship between pages as dependency edges, using the set of pages in the structured requirement model as nodes in the dependency graph. Step 3.2, Dependency Graph Initialization: The dependency graph initialization sub-unit of the dependency extraction unit combines the extracted page nodes with the three types of dependency edges to construct an initial multi-page dependency graph, clarifies the association parameters of each dependency edge, and presents it in the form of a directed graph; Step 3.3, Dependency Validation and Topology Sorting: The loop detection subunit, isolated node detection subunit, dependency validity determination subunit, and anomaly correction subunit within the dependency validation unit work together to validate the initial dependency graph, detect the existence of circular dependencies, isolated nodes, and illegal dependencies, remove or correct detected abnormal dependencies, and generate a valid and conflict-free final dependency graph. The in-degree calculation subunit, topology sequence generation subunit, code generation order determination subunit, and sorting result output subunit within the topology sorting unit work together to perform topology sorting based on the final dependency graph, calculate the in-degree of each page node, generate the execution sequence of pages, and output the final dependency relationship data containing the topology order to the rule mapping module. Step 4 includes: Step 4.1, Rule Mapping and Template Matching: The multi-source data receiving unit of the rule mapping module receives decision tree rules, dependency data, and code template metadata. After standardized processing, it is passed to the mapping relationship establishment subunit; the mapping relationship establishment subunit establishes a three-dimensional mapping relationship of decision tree rules - dependencies - code templates; the code generation rule definition subunit defines basic rules, interaction logic rules, and execution order rules based on the mapping relationship. After being verified by the rule verification subunit, the valid code generation rules are output to the code generation module by the rule output unit; the input data receiving unit of the code generation module receives the valid code generation rules and at the same time receives the standardized code templates stored in the template library, stores them classified by function, and matches the corresponding templates. Step 4.2, Parameter Substitution: The rule parsing subunit of the code generation module parses the valid code generation rules, extracts the core parameters and passes them to the template calling subunit. The template calling subunit loads the adapted code templates in sequence; the placeholder recognition subunit, parameter matching and substitution subunit, and substitution result verification subunit inside the parameter substitution subunit work together to identify the replaceable placeholders in the template, and replace the core parameters in the decision tree rules and the dependency constraint parameters in the dependency graph into the matching code template placeholders, and at the same time add auxiliary logic to ensure that the code can execute normally. Step 4.3, Code Integration: The page sequence integration subunit, linkage logic association subunit, and code format standardization subunit inside the code integration subunit of the code generation module work together. According to the page generation order determined by topological sorting, the single-page code fragments after replacement are integrated, add the linkage logic association code between pages, unified the code format, and remove redundant code to form a complete multi-page linkage code set.

[0017] The beneficial effects of the present invention are as follows: Improve development efficiency: By disassembling the interaction logic with a decision tree and controlling the page dependencies with a dependency graph, automatic generation of multi-page linkage code is achieved, greatly reducing the manual coding workload and shortening the development cycle; Reduce logical coupling: Structurally disassemble the scattered linkage logic into decision tree branch rules, and visually manage the page dependencies as a dependency graph to achieve unified management of the linkage logic and reduce the code coupling; Reduce maintenance costs: The decision tree and dependency graph provide a clear basis for logical sorting of the code. When modifying requirements and troubleshooting problems later, the associated pages and logical branches can be quickly located, reducing the maintenance time; Ensure code consistency: Based on a unified code template and generation rules, the generated code styles and logical implementation methods are consistent, avoiding logical conflicts caused by differences among developers. Brief Description of the Drawings

[0018] Figure 1 It is a schematic diagram of the overall architecture and data flow of the multi-page linkage code generation system of the present invention; Figure 2This is a schematic diagram of the internal structure and workflow of the requirements analysis module in this invention; Figure 3 This is a schematic diagram of the internal structure and processing flow of the decision tree construction module of the present invention; Figure 4 This is a schematic diagram of the internal structure and processing flow of the dependency graph construction module in this invention; Figure 5 This is a flowchart illustrating the rule mapping module, its internal structure, and processing flow in this invention. Figure 6 This is a flowchart illustrating the internal structure and processing flow of the code generation module in this invention. Detailed Implementation

[0019] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0020] Example 1 This embodiment proposes a multi-page linked code generation system based on decision trees and dependency graphs, such as... Figure 1 As shown, it includes a requirement parsing module, which is connected to the decision tree construction module and the dependency graph construction module. The decision tree construction module is connected to the rule mapping module, the dependency graph construction module is connected to the rule mapping module, the rule mapping module is connected to the code generation module, and the code generation module is connected to the template library storage module.

[0021] Example 2 Based on Example 1, combined with Figure 2 As shown, this embodiment proposes a requirement parsing module including a requirement receiving unit and a structured parsing unit connected in sequence; the requirement receiving unit is used to receive multi-page linkage business requirements input from the outside, and the structured parsing unit parses and processes the original requirement data.

[0022] Example 3 Based on Example 2, combined with Figure 3 As shown, this embodiment proposes a decision tree construction module including a node construction unit, a pruning optimization unit, and a rule output unit connected in sequence, with the node construction unit connected to the structured parsing unit; The node construction unit includes: a page identification subunit that extracts all page nodes from the structured requirement model and determines the root node of the decision tree and candidate page nodes at each level; a condition extraction subunit that extracts all interaction trigger conditions from the requirement model as branch features of the decision tree; a branch generation subunit that generates decision branches according to whether the conditions are met or not, and binds corresponding linkage behaviors to each branch; and a tree structure generation subunit that recursively generates a complete initial decision tree structure according to the hierarchical relationship of the root node, intermediate nodes, and leaf nodes. The pruning and optimization unit includes: a redundant branch identification subunit that traverses the decision tree and identifies redundant branches that have no actual linkage effect or corresponding page behavior; a conflict branch detection subunit that detects logically contradictory and mutually exclusive condition branches in the decision tree; and a tree structure simplification subunit that deletes redundant branches, merges duplicate conditions, and corrects conflicting logic to form a simplified and executable decision tree. The rule output unit includes: a tree traversal subunit that performs a depth-first traversal of the optimized decision tree and reads each complete path from the root node to the leaf node; a rule formatting subunit that converts each path into a structured rule with the format of trigger page + trigger condition + action + target page; and a rule output interface subunit that organizes all rules into a unified format and outputs them to the rule mapping module.

[0023] Example 4 Based on Example 3, combined with Figure 4 As shown, this embodiment proposes a dependency graph construction module including a dependency extraction unit, a dependency verification unit, and a topology sorting unit connected in sequence; The dependency extraction unit includes: a page node parsing subunit that reads all page identifiers from the structured requirement model and establishes a set of page nodes for the dependency graph; a trigger dependency identification subunit that extracts trigger relationships between pages from interactive behaviors and decision tree branches, identifying which page's behavior triggers which page's linkage, forming trigger dependency edges; a data dependency identification subunit that extracts data transfer relationships between pages from the data flow rules of the requirement model, determining the data source page, data target page, transfer fields, and direction, forming data dependency edges; and a rendering dependency identification subunit that identifies rendering order constraints between pages, determining which pages must complete operations on another page before they can be loaded or updated, forming rendering dependency edges; and a dependency graph initialization subunit that combines the above page nodes with the three types of dependency edges to construct an initial multi-page dependency graph. The dependency verification unit includes: a loop detection subunit that traverses the dependency graph to detect the existence of circular dependencies between pages (e.g., A depends on B, B depends on A), and marks them as abnormal dependencies if they exist; an isolated node detection subunit that checks for isolated page nodes that have no dependencies and do not participate in the interaction, and marks or filters isolated nodes; a dependency validity determination subunit that determines the rationality of the dependency relationship: whether the triggering dependency has a corresponding interactive behavior; whether the data dependency has clear fields and transmission direction; and whether the rendering dependency conforms to the page loading logic; and an anomaly correction subunit that removes or corrects detected loops, conflicts, and illegal dependencies, and outputs a valid dependency graph that is legal and conflict-free. The topology sorting unit includes: an in-degree calculation subunit that calculates the in-degree (i.e., the number of times a node is depended on by other pages) for each page node in the legal dependency graph to determine the dependency priority of the node; a topology sequence generation subunit that uses a topology sorting algorithm (such as the Kahn algorithm) to generate a sequence of page execution according to the principle of prioritizing dependent pages and ordering dependent pages; a code generation order determination subunit that converts the topology sequence into a code generation order, clarifying the linkage logic of which page to build first and which page to build next; and a sorting result output subunit that encapsulates the legal dependency graph and the topology sorting result into unified dependency relationship data for output.

[0024] Example 5 Based on Example 4, combined with Figure 5 As shown, this embodiment proposes a rule mapping module comprising a multi-source data receiving unit, a mapping relationship establishment subunit, a code generation rule definition subunit, a rule verification subunit, and a rule output unit connected in sequence. The multi-source data receiving unit, as the entry point for the rule mapping module, is specifically responsible for receiving input data from external related modules and standardizing its format to ensure that subsequent mapping and rule definition can proceed normally. The multi-source data receiving unit includes: a decision tree rule receiving subunit that receives a set of structured interactive logic execution rules from the rule output unit of the decision tree construction module, parses the core parameters of each rule (trigger page identifier, trigger condition expression, execution action type, target page identifier, data transmission fields and types), and uniformly converts the rule format into JSON (JavaScript Object Notation). The object representation format is used, where each parameter corresponds to a clear key-value pair (e.g., "triggerPage":"list", "condition":"goodsIdValid===true") to avoid mapping failures caused by format confusion; it also filters invalid rules (such as rules without a target page or action) and outputs a standardized decision tree rule set; the dependency data receiving subunit receives the final dependency data containing the topological order from the topology sorting unit of the dependency graph construction module, and focuses on extracting two types of core information and performing structured processing: first, the dependency type between pages (trigger dependency, data dependency, rendering dependency), dependency direction (source page → target page), and associated parameters (data The code template information receiving subunit receives front-end framework code template metadata from the template library storage module's template classification retrieval unit. It extracts the core information of the template (template identifier, adapting framework, template type, replaceable parameters, parameter placeholders) and establishes a template metadata index table to facilitate the rapid matching of the corresponding code template based on decision tree rules and dependencies. Among them, replaceable parameters need to clearly define the specific content of the corresponding page interaction (such as page jump parameters, data transmission field placeholders). The mapping relationship establishment subunit establishes a precise mapping between decision tree rules, dependencies, and code templates, ensuring that each interaction rule matches its corresponding dependency constraints and code template. This subunit includes: a decision tree and dependency mapping subunit that uses page identifiers and interaction actions as dual primary keys to bind standardized decision tree rules to dependencies in a three-dimensional mapping table; for example, the decision tree rule "clicking a product card on the list page triggers a jump to the detail page" is associated with "the triggering dependency and data dependency (passing goodsId) of list→detail," clarifying the dependency constraints that this interaction rule must follow (such as ensuring the validity of data dependency fields before the jump), generating a "decision tree rule-dependency" mapping pair; and a mapping pair and code template matching subunit that matches the decision tree rule-dependency pair. The core parameters of the mapping pair (action type, page type, and adaptation framework) are retrieved from the code template metadata index table to match the corresponding code template. For example, for the interaction rule of "page jump + data transfer", the template of "page jump with parameters" in the template library is matched; for the interaction rule of "data refresh", the template of "component data update" is matched to ensure the compatibility of the template with the interaction rule and dependency relationship. If no corresponding template is matched, a template missing prompt is output (to facilitate the subsequent supplementation of the template library). The mapping relationship storage sub-unit stores the matched decision tree rule-dependency relationship-code template three-dimensional mapping relationship in the module's internal temporary database (a lightweight SQLite database can be used), establishes a mapping relationship index, supports quick query and call when defining subsequent rules, and records mapping matching logs to facilitate subsequent troubleshooting. The code generation rule definition unit, based on the established three-dimensional mapping relationship, defines standardized rules that can be directly used for code generation, clarifying the logic of code generation, parameter replacement rules, and execution order. The code generation rule definition unit includes: the basic rule definition subunit, which defines the general basic rules for code generation, including the rules for calling code templates (such as calling the corresponding template based on the template identifier), parameter replacement rules (such as replacing "goodsId" in the decision tree rule with the placeholder "{dataField}" in the template), and code format specifications (such as indentation, comment format, and variable naming specifications), to ensure that the generated code conforms to front-end development standards; and the interaction logic rule definition subunit, which defines specific interaction logic generation rules for each decision tree rule-dependency-code template mapping pair. For example, for the mapping pair "list→detail trigger dependency + data transfer", the rule is defined as "call the page jump template, pass the goodsId field of the list page to the detail page, and verify the validity of goodsId (in accordance with dependency constraints) before the jump"; for the mapping pair "detail→cart rendering dependency", the rule is defined as "before the cart page template is rendered, execute the add-to-cart completion event of the detail page to ensure the accuracy of the rendered data"; the execution order rule defines the execution order rule of code generation based on the page order generated by the sub-unit combined with the topological sorting; for example, according to the topological order of "list→detail→cart", the rule is defined as "first generate the list page code, then generate the detail page code (including the linkage logic with the list page), and finally generate the cart page code (including the linkage logic with the detail page)", to ensure that the code generation order is consistent with the page dependency order and avoid linkage logic conflicts. The rule standardization subunit organizes the defined basic rules, interaction logic rules, and execution order rules into a unified JSON format code generation rule set. Each rule contains parameters such as a unique identifier, rule type, association mapping relationship identifier, specific rule content, and execution priority, ensuring that the code generation module can directly parse and call it. The rule validation subunit performs a comprehensive validation of the defined code generation rules to ensure their legality, logic, and executability, preventing code generation failures due to rule errors. The rule validation subunit includes: a rule legality validation subunit that checks whether the code generation rule format conforms to standardization requirements (e.g., whether the JSON format is correct and parameters are complete), whether the rule content is valid (e.g., no syntax errors, no invalid parameters), and whether associated mapping relationships exist (e.g., whether the template identifier and decision tree rule identifier associated with the rule are valid). If an anomaly is found, the anomaly type is marked and correction suggestions are output. The rule logic validation subunit checks whether there are any discrepancies between the rules. Logical conflicts (such as contradictions between execution order rules and topological sorting order, and conflicts between interaction logic rules and dependency constraints), and the adaptability of rules and code templates (such as whether parameter replacements in rules match template placeholders) are addressed to ensure that the rules are logically coherent, without contradictions, and conform to the business logic of multi-page linkage. The validation result processing subunit marks the validated code generation rules and organizes them into a set of valid code generation rules. For rules that fail validation, an exception report (including exception rule identifier, exception type, and correction suggestions) is output and fed back to the mapping relationship establishment subunit and the rule definition subunit for correction and re-validation until all rules pass validation. The rule output unit, as the exit unit of the rule mapping module, is responsible for outputting validated and effective code generation rules to the code generation module in a standardized format. It also stores rule backups for later traceability and modification. The rule output unit includes: a rule formatting output subunit, which converts the set of valid code generation rules into a format that the code generation module can directly parse (consistent with the interface protocol of the code generation module), adding auxiliary information such as rule version number, generation time, and associated mapping relationship identifiers to ensure that the code generation module can accurately identify and call each rule; and a rule backup and logging subunit, which backs up the output valid code generation rules (storing them in the module's temporary database) and records rule output logs (including output time, number of output rules, and receiving module identifier) ​​for later rule modification, traceability, and recovery in case of system failure.

[0025] Example 6 Based on Example 5, combined with Figure 6 As shown, this embodiment proposes a code generation module comprising an input data receiving unit, a rule parsing subunit, a template calling subunit, a parameter replacement subunit, a code integration subunit, and a code output subunit connected in sequence. The input data receiving unit, as the entry point for the code generation module, is responsible for receiving input data from external related modules and performing format verification and preprocessing to ensure the subsequent code generation process can proceed normally. The input data receiving unit includes: a generation rule receiving subunit that receives a standardized, parsable, and valid set of code generation rules from the rule output unit of the rule mapping module; verifies whether the rule format is compatible with the module interface and whether the rule parameters are complete (such as associated template identifiers, execution order, and interaction logic parameters); marks incomplete rules (which will not participate in code generation); performs format conversion on rules with incorrect formats; and outputs a set of adapted, valid code generation rules. The code template receiving subunit receives "front-end framework code templates" from the template classification and retrieval unit of the template library storage module (matched and called according to the template identifier in the code generation rules); verifies the integrity of the templates (such as whether the template contains a complete page structure and whether replaceable parameter placeholders are complete); extracts the core structure of the templates (HTML structure, CSS styles, JavaScript interaction logic); classifies and stores them according to template type (page templates, interaction templates, data transfer templates); and outputs a set of standardized code templates that can be directly called. The rule parsing subunit performs in-depth analysis of the adapted valid code generation rules, extracting all core parameters required for code generation, providing a clear basis for subsequent template calls and parameter replacements. The rule parsing subunit includes: an execution order parsing subunit that parses the execution order parameters in the code generation rules, extracts the page generation order determined by topological sorting (e.g., list→detail→cart), establishes a "page identifier-generation priority" mapping table, clarifies the generation order of code for each page, and ensures that the generated code conforms to dependency graph constraints; and an interaction logic parsing subunit that parses the interaction logic parameters in each rule, extracting core information such as the triggering page, triggering condition, execution action, target page, data transmission fields and types, and organizing them into "interaction logic parameters". The table, for example, parses "Click on a product card on the list page → redirect to the detail page, passing goodsId" as: Triggering page = list, Triggering event = click, Triggering condition = goodsIdValid===true, Target page = detail, Data field = goodsId, Data type = string; The template matching and parsing subunit parses the template identifier parameter in each rule, associates it with the code template collection stored in categories, determines the specific code template corresponding to each interaction logic (such as "Page Redirect Template" for page redirection logic, and "Data Transfer Template" for data transfer), and generates an association table of "Rule Identifier - Template Identifier - Template Path" for easy and quick template calling later; The template invocation subunit calls the corresponding code templates sequentially according to the rule parsing results and the page generation order, ensuring the accuracy and order of template invocation. The template invocation subunit includes: a template retrieval and invocation subunit that retrieves and calls the corresponding code templates sequentially according to the rule identifier-template identifier-template path association table and the page generation priority order, for example, calling the list page template first, then the detail page template, and finally the cart page template; at the same time, for each interaction logic, the corresponding interaction template (such as page jump template, data transfer template) is called and loaded into the module's temporary memory for subsequent parameter replacement; after calling the code template, the template adaptability verification subunit verifies the adaptability of the template and the interaction logic parameters, for example, whether the placeholders in the template are consistent with the fields in the interaction logic parameter table (such as whether {dataField} in the template corresponds to goodsId in the parameter table), and whether the front-end framework adapted by the template is consistent with the system's preset framework. If the adaptation fails, an adaptation exception report is output and fed back to the rule parsing subunit for re-matching the template. The parameter replacement subunit replaces the parameters in the interaction logic parameter table into the loaded code template, combining the template and parameters to generate page code with specific interaction logic. The parameter replacement subunit includes: a placeholder recognition subunit that iterates through the loaded code template, identifies all replaceable placeholders (such as {triggerPage}, {dataField}, {condition}), establishes a placeholder-template position mapping table, and clarifies the specific position of each placeholder in the template to ensure the accuracy of parameter replacement and avoid errors; and a parameter matching and replacement subunit that, based on the placeholder-template position mapping table and the interaction logic parameter table, replaces the corresponding parameter values ​​into the placeholders in the template. For example, it replaces {triggerPage} with {dataField} with {condition}. Replace `ggerPage}` with `list`, `{dataField}` with `goodsId`, and `{condition}` with `goodsIdValid===true`. Simultaneously, for data dependency-related parameters, add data type validation logic (e.g., ensuring `goodsId` is a string type) to ensure the generated code runs correctly. After replacement, the result validation subunit verifies the accuracy of the replacement results. For example, it verifies whether all placeholders have been replaced (no omissions), whether parameter values ​​are correct (no incorrect replacements), and whether the replaced code has syntax errors (e.g., missing quotes, mismatched parentheses). Code snippets that fail validation are marked and fed back to the placeholder recognition subunit for re-replacement.

[0026] The code integration subunit integrates the single-page code snippets with replaced parameters according to the page generation order, adding inter-page linkage logic to form a complete multi-page linkage code set. The code integration subunit includes: a page order integration subunit that arranges and integrates single-page code snippets in the order of list→detail→cart based on a page identifier-generated priority mapping table, ensuring the order of page code matches the topological order of the dependency graph and avoiding confusion in linkage logic; an inter-page linkage logic association subunit that adds inter-page linkage logic association code based on the interaction logic parameter table, for example, adding association code for "clicking a product card triggers a jump to the detail page" in the list page code, and adding association code for "after adding to cart, triggers a data refresh on the cart page," ensuring that the inter-page linkage logic conforms to decision tree rules and dependency graph constraints; and a code format standardization subunit that standardizes the format of the integrated multi-page code, unifying code indentation (e.g., 4 spaces) and comment format (e.g., / / ). Page linkage logic: list→detail navigation), variable naming conventions (such as using camelCase), removal of redundant code (such as placeholder comments in the template), ensuring that the generated code is clean, standardized, and can be directly used for front-end deployment; The code output subunit, as the output unit of the code generation module, is responsible for packaging the integrated multi-page linkage code, outputting a directly deployable code package, and recording output logs for future traceability. The code output subunit includes: a code packaging subunit that packages the standardized, complete multi-page linkage code set according to front-end project specifications, generating a directly deployable code package (supporting zip format), containing page files (HTML), style files (CSS), and interaction files (JavaScript), and also generating code package documentation that clarifies the code package structure, page relationships, and deployment steps; and an output log and backup subunit that records the code output log, including output time, code package size, number of pages, associated code generation rule version, template version, etc.; and a backup of the generated code package (stored in a system-specified directory) for future code version traceability, modification, or regeneration. If needed, the code package can be directly downloaded by the user.

[0027] In this invention, the requirement parsing module synchronously outputs the parsed structured requirement model to the decision tree construction module and the dependency graph construction module, providing a unified data source for both. The decision tree construction module sends the generated interaction logic branch rules to the rule mapping module. The dependency graph construction module sends the completed inter-page dependency relationship data to the rule mapping module. The rule mapping module outputs the fused code generation rules to the code generation module. The template library storage module provides front-end framework code templates to the code generation module. The code generation module directly outputs the final multi-page linkage code. Through the above data flow and module connection relationships, this system forms a complete data flow link from requirement input to code output. Each module has a clear division of labor and clear data transmission, forming an executable and reproducible complete technical solution.

[0028] In this invention, the requirement parsing module receives and parses multi-page linkage requirements, constructing a structured requirement model. Clear data transfer and calling relationships exist between the various units: the requirement receiving unit receives externally input multi-page linkage business requirements, including visual configuration information and form configuration information; the output is raw requirement data. The structured parsing unit, connected to the requirement receiving unit, processes the raw requirement data, including: extracting the page set, determining the identifier, name, and page type of each page; extracting interactive components and behaviors within the pages, including clicks, inputs, selections, submissions, and page jumps; extracting trigger relationships between pages, determining which behavior on which page triggers the linkage of another page; extracting data flow rules, determining the field names, data types, and transmission directions passed between pages; and outputting standardized, structured intermediate requirement data.

[0029] In this invention, the decision tree construction module constructs an interactive decision tree based on a requirement model, decomposing the multi-page linkage logic into conditional branch execution rules. This module includes a node construction unit, a pruning optimization unit, and a rule output unit. The output of the node construction unit is connected to the input of the pruning optimization unit; the output of the pruning optimization unit is connected to the input of the rule output unit. The three units are connected sequentially, and data is passed level by level to jointly complete the construction and output of the interactive decision tree. The processing within the decision tree construction module is as follows: structured requirement model → node construction unit (generating the initial tree) → pruning optimization unit (removing redundancy and conflicts) → rule output unit (generating executable rules) → rule mapping module. The internal structure of the node construction unit includes: a page identification subunit, a condition extraction subunit, a branch generation subunit, and a tree structure generation subunit. The input of the node construction unit is the structured requirement model from the requirement parsing module; the output is the complete initial interactive decision tree without pruning; the output direction is to pass it to the pruning optimization unit. The internal structure of the pruning optimization unit includes: a redundant branch identification subunit, a conflict branch detection subunit, and a tree structure simplification subunit. The input to the pruning optimization unit is the initial decision tree from the node construction unit; the output is the final decision tree after simplification and optimization; the output direction is to pass it to the rule output unit; the internal structure of the rule output unit includes a tree traversal subunit, a rule formatting subunit, and a rule output interface subunit. The input to the rule output unit is the optimized decision tree from the pruning optimization unit; the output is a set of structured interaction logic execution rules; the output direction is to output to the rule mapping module. In this invention, the dependency graph construction module is used to construct a multi-page dependency graph, clarifying various dependencies and execution priorities between pages. This module includes a dependency extraction unit, a topology sorting unit, and a dependency validation unit. The three units are connected sequentially according to the data order and process data step by step to jointly complete the construction, validation, and sorting output of the multi-page dependency graph. The input of the dependency extraction unit is a structured requirement model from the requirement parsing module; the output is an unvalidated and unsorted initial dependency graph; the output direction is to pass it to the dependency validation unit. The input of the dependency validation unit is the initial dependency graph from the dependency extraction unit; the output is a validated and corrected valid dependency graph; the output direction is to pass it to the topology sorting unit. The input of the topology sorting unit is a valid dependency graph from the dependency validation unit; the output is the final dependency data containing the topological order; the output direction is to output to the rule mapping module. The overall connection relationship between the three units is as follows: the output of the dependency extraction unit is connected to the input of the dependency validation unit; the output of the dependency validation unit is connected to the input of the topology sorting unit. The overall data flow is as follows: Structured requirement model → Dependency extraction unit (builds the initial dependency graph) → Dependency verification unit (removes loops, eliminates conflicts, and corrects anomalies) → Topology sorting unit (generates the page execution order) → Outputs dependency data to the rule mapping module.

[0030] The core function of the rule mapping module in this invention is to establish the mapping relationship between decision trees, dependency graphs, and code templates, and to define standardized code generation rules, providing a clear execution basis for the subsequent code generation module. It mainly includes a multi-source data receiving unit, a mapping relationship establishment unit, a code generation rule definition unit, a rule verification unit, and a rule output unit. The multi-source data receiving unit takes as input a set of structured interaction logic execution rules, final dependency relationship data including topological order, and code template metadata; its output is a standardized JSON format decision tree rule set, a three-dimensional mapping table of page identifier-dependency-sorting priority, and a code template metadata index table; the output direction is to be passed to the mapping relationship establishment unit. The mapping relationship establishment unit takes as input a standardized JSON format decision tree rule set, a three-dimensional mapping table of page identifier-dependency-sorting priority, and a code template metadata index table; its output is a three-dimensional mapping relationship set of decision tree rules-dependency-code templates and a mapping matching log; the output direction is to be passed to the code generation rule definition unit. The code generation rule definition unit takes as input a three-dimensional mapping relationship set of decision tree rules-dependency-code templates; its output is a standardized JSON format code generation rule set; the output direction is to be passed to the rule verification unit. The rule validation unit takes a standardized JSON-formatted set of code generation rules as input and outputs a set of valid code generation rules and an exception rule report. The output direction is from valid rules to the rule output unit. The rule output unit takes a set of valid code generation rules as input and outputs a standardized, parsable set of valid code generation rules. The output direction is from the code generation module. Each sub-unit is connected sequentially in the order of "multi-source data receiving unit → mapping relationship establishment unit → code generation rule definition unit → rule validation unit → rule output unit," forming a complete processing chain. The specific data flow is as follows: The multi-source data receiving unit receives three types of data from external modules, processes them according to standardization, and then passes them to the mapping relationship establishment unit. The mapping relationship establishment unit establishes a three-dimensional mapping relationship based on the input data and passes it to the code generation rule definition unit. The code generation rule definition unit defines standardized code generation rules based on the mapping relationship and passes them to the rule validation unit. The rule validation unit validates the rules, passes valid rules to the rule output unit, and feeds back exception rules to the preceding related units for correction. The rule output unit formats the valid rules and outputs them to the code generation module, while simultaneously backing up the rules and recording logs.

[0031] In this invention, the code generation module combines decision trees and dependency graphs to generate multi-page linked code. Internal data is processed according to the logic of "data reception → rule parsing → template invocation → parameter replacement → code integration → code output". The input data receiving unit receives a standardized, parsable set of valid code generation rules and a standardized code template set; the output is a adapted set of valid code generation rules and a categorized set of standardized code templates; the output direction is to pass to the rule parsing subunit. The rule parsing subunit receives the adapted set of valid code generation rules and a categorized set of standardized code templates; the output is a page identifier-generation priority mapping table, an interaction logic parameter table, and a rule identifier-template identifier-template path association table; the output direction is to pass to the template invocation unit. The template invocation subunit receives the page identifier-generation priority mapping table, an interaction logic parameter table, a rule identifier-template identifier-template path association table, and a categorized set of standardized code templates; the output is sequentially loaded code templates (in memory), template adaptation verification results, and adaptation exception reports (if any); the output direction is to pass adapted templates to the parameter replacement subunit, and to feed back exception reports to the rule parsing subunit. The parameter replacement subunit takes sequentially loaded code templates, an interaction logic parameter table, and a placeholder-template position mapping table as input; its output is a single-page code snippet with parameter replacement completed and a replacement result verification report; the output direction is to be passed to the code integration subunit. The code integration subunit takes single-page code snippets with parameter replacement completed, a page identifier-generation priority mapping table, and an interaction logic parameter table as input; its output is a standardized, complete set of multi-page cascading code; the output direction is to be passed to the code output subunit. The code output subunit takes a standardized, complete set of multi-page cascading code as input; its output is a directly deployable multi-page cascading code package, code package documentation, and output logs; the output direction is either directly to the user or stored in a system-specified directory for user download.

[0032] Example 7 This embodiment proposes a multi-page cascading code generation method based on decision trees and dependency graphs, including the following steps: Step 1: Construct a structured requirements model; This step serves as the foundation of the entire method. Its core is to transform unstructured multi-page linkage requirements into structured data that can be recognized and decomposed by subsequent algorithms, providing a unified data source for decision tree construction and dependency graph construction. Step 2: Decompose the interaction logic and generate decision tree execution rules; The core of this step is to utilize decision tree algorithms (this paper preferably uses mature algorithms such as C4.5 (Classifier 4.5) and ID3 (Iterative Dichotomiser 3). The core is to decompose complex interaction logic into a hierarchical condition judgment process of "root node → intermediate branch node → leaf node". The root node corresponds to the initial triggering scenario of the linkage, the intermediate nodes correspond to the interaction triggering conditions, and the leaf nodes correspond to the specific linkage actions). Through the collaborative work of the node construction unit, pruning optimization unit, and rule output unit of the decision tree construction module, the complex interaction logic in the structured requirement model is decomposed into hierarchical and executable conditional branch rules, so as to realize the structured control of the interaction logic. Step 3: Analyze page relationships, clarify dependency constraints, and build a dependency graph; This step is executed synchronously with the decision tree construction step. The core is to build a multi-page dependency graph by having the dependency extraction unit, dependency verification unit, and topology sorting unit of the dependency graph construction module work together to clarify the dependency relationships and constraints between pages, and ensure that the order of code generation conforms to the page linkage logic to avoid linkage conflicts. Step 4: Combine rules and dependencies to automatically generate code; This step is the core execution stage of the entire method. The core is that the various building units of the rule mapping module and the code generation module work together to combine the interaction rules generated by the decision tree, the dependency relationships generated by the dependency graph, and the topological order, and call the preset code template to automatically generate multi-page code with complete linkage logic.

[0033] Example 8 This embodiment proposes a multi-page cascading code generation method based on decision trees and dependency graphs, including the following steps: Step 1: Construct a structured requirements model; This step serves as the foundation of the entire method. Its core is to transform unstructured multi-page linkage requirements into structured data that can be recognized and decomposed by subsequent algorithms, providing a unified data source for decision tree construction and dependency graph construction. The specific implementation process is as follows: Step 1.1, Requirements Input: The requirements receiving unit receives multi-page linkage business requirements. The input forms include, but are not limited to, visual configuration information, form configuration files, natural language requirements descriptions, page relationship definition documents, etc. The requirements receiving unit performs preliminary screening of the input requirements to ensure that the requirements cover the three core elements of "page set, interactive behavior, and data flow", and eliminates invalid and ambiguous requirements. Step 1.2, Requirements Extraction: The original input requirements are structured and parsed using the structured parsing unit. Within this unit, the page identification subunit, interaction behavior extraction subunit, and data flow parsing subunit work together to extract key information, including: page set (identifying all participating page identifiers, names, and page types), interaction behavior (triggering events within each page, such as clicks, input, and submissions, and corresponding actions), data flow rules (field names, data types, transmission direction, and constraints passed between pages), and rendering constraints (the order of page loading and updating). This structured key information is organized into a unified structured requirements model (preferably using JSON format). The structured requirements model contains at least five core modules: page node set, interaction behavior set, triggering condition set, data dependency set, and rendering constraint set. Each module contains clearly defined parameters and data formats. The model output unit synchronously distributes the completed structured requirements model to the decision tree construction module and dependency graph construction module, ensuring that subsequent steps can directly call for parsing. Step 2: Decompose the interaction logic and generate decision tree execution rules; The core of this step is to utilize decision tree algorithms (this paper preferably uses mature algorithms such as C4.5 (Classifier 4.5) and ID3 (Iterative Dichotomiser 3). The core is to decompose complex interaction logic into a hierarchical condition judgment process of "root node → intermediate branch node → leaf node". The root node corresponds to the initial triggering scenario of the linkage, the intermediate nodes correspond to the interaction triggering conditions, and the leaf nodes correspond to the specific linkage actions). Through the collaborative work of the node construction unit, pruning optimization unit, and rule output unit of the decision tree construction module, the complex interaction logic in the structured requirement model is decomposed into hierarchical and executable conditional branch rules, realizing the structured control of the interaction logic. The specific implementation process is as follows: Step 2.1, Node Definition and Initialization: The page recognition subunit, condition extraction subunit, branch generation subunit, and tree structure generation subunit within the node construction unit work together to define the initial nodes of the decision tree, with the triggering page of multi-page linkage as the root node, the interaction triggering conditions as intermediate branch nodes, and the linkage behavior of the target page as leaf nodes. The root node clarifies the initial triggering scenario (e.g., "clicking a product card on the product list page"), the intermediate nodes clarify the condition judgment logic (e.g., "is goodsId valid?" "is buyCount greater than 0?"), and the leaf nodes clarify the specific linkage behavior when the conditions are met / not met (e.g., page jump, data transfer, no linkage action). Step 2.2, Branch Rule Generation and Pruning Optimization: The node construction unit extracts all interaction trigger conditions from the structured requirement model as candidate branch features. Based on the execution logic correlation of the interaction behavior, it determines the optimal trigger conditions at each level and generates corresponding intermediate nodes. According to the binary branch logic of "trigger condition satisfied / not satisfied", it splits the branches of each intermediate node and maps the page linkage behaviors (including page jump, data transmission, event triggering, etc.) matched by each branch to leaf nodes. This process is executed recursively to generate an unpruned initial interaction decision tree. The redundant branch identification subunit, conflict branch detection subunit, and tree structure simplification subunit within the pruning optimization unit work together to traverse the initial decision tree, identify and delete redundant branches, detect and correct conflict branches, merge duplicate conditions, and generate a simplified and executable optimized decision tree.

[0034] Step 2.3, Rule Standardization and Output: The tree traversal subunit, rule formatting subunit, and rule output interface subunit within the rule output unit work together to perform a depth-first traversal of the optimized decision tree, reading each complete path from the root node to the leaf node. Each path is transformed into a structured set of interactive logic execution rules in the format of trigger page + trigger condition + execution action + target page, such as "product list page (list) + click on product card and goodsId is valid + jump to product details page (detail) and pass goodsId + product details page (detail)". The rule set is then output to the subsequent rule mapping module to ensure that the rules can be directly called by the subsequent code generation steps.

[0035] Step 3: Analyze page relationships, clarify dependency constraints, and build a dependency graph; This step is executed concurrently with the decision tree construction step. Its core is to construct a multi-page dependency graph through the collaborative work of the dependency extraction unit, dependency validation unit, and topology sorting unit of the dependency graph construction module. This clarifies the dependency relationships and constraints between pages, ensuring that the code generation order conforms to the page linkage logic and avoiding linkage conflicts. The specific implementation process is as follows: Step 3.1, Node and Dependency Edge Extraction: The page node parsing subunit, trigger dependency identification subunit, data dependency identification subunit, and rendering dependency identification subunit within the dependency extraction unit work together to extract three types of core dependency relationships between pages as dependency edges, using the set of pages in the structured requirement model as nodes in the dependency graph: trigger dependency (an interactive behavior on one page triggers a linkage on another page), data dependency (one page passes data to another page, and subsequent linkages can only be executed after the data transfer is completed), and rendering dependency (one page can only be loaded or updated after an operation is completed on another page).

[0036] Step 3.2. Dependency graph initialization: The dependency graph initialization subunit of the dependency extraction unit combines the extracted page nodes with three types of dependency edges to construct an initial multi-page dependency graph, clarifies the association parameters of each dependency edge (such as the transfer field of data dependency, the trigger event of trigger dependency, the constraint condition of rendering dependency), and presents it in the form of a directed graph (the arrow points to the dependency direction, e.g., list → detail indicates that the list page depends on the relevant data or actions of the detail page).

[0037] Step 3.3. Dependency verification and topological sorting: The loop detection subunit, isolated node detection subunit, dependency legality determination subunit, and exception correction subunit inside the dependency verification unit work together to verify the initial dependency graph, detect whether there are circular dependencies (such as A depends on B and B depends on A), isolated nodes (pages with no dependency relationships), and illegal dependencies (such as trigger dependencies without corresponding interaction behaviors), eliminate or correct the detected abnormal dependencies, and generate a legal and conflict-free final dependency graph; The in-degree calculation subunit, topological sequence generation subunit, code generation order determination subunit, and sorting result output subunit inside the topological sorting unit work together. Based on the final dependency graph, the Kahn algorithm is used for topological sorting, calculate the in-degree of each page node, generate the sequence of page execution, determine the code generation order of the pages, ensure that the code generation order conforms to the dependency constraints, and output the final dependency relationship data including the topological order to the rule mapping module; Step 4. Combine rules and dependencies to automatically generate code; This step is the core execution link of the entire method. The core is to work together with each construction unit of the rule mapping module and the code generation module, combine the interaction rules generated by the decision tree, the dependency relationship and topological order generated by the dependency graph, call the preset code template, and automatically generate multi-page code with complete linkage logic. The specific implementation process is as follows: Step 4.1. Rule mapping and template matching: The multi-source data receiving unit of the rule mapping module receives the decision tree rules, dependency relationship data, and code template metadata, and after standardization processing, transfers them to the mapping relationship establishment subunit; The mapping relationship establishment subunit establishes a three-dimensional mapping relationship of "decision tree rules - dependency relationship - code template"; The code generation rule definition subunit defines the basic rules, interaction logic rules, and execution order rules based on the mapping relationship. After being verified by the rule verification subunit, the rule output unit outputs the valid code generation rules to the code generation module; The input data receiving unit of the code generation module receives the valid code generation rules, and at the same time receives the standardized code templates stored in the template library, stores them classified by function, and matches the corresponding templates (such as page jump logic matching the "page jump template"); Step 4.2, Parameter Replacement: The rule parsing subunit of the code generation module parses valid code generation rules, extracts core parameters, and passes them to the template calling subunit. The template calling subunit loads the adapted code templates in sequence. The placeholder recognition subunit, parameter matching and replacement subunit, and replacement result verification subunit within the parameter replacement subunit work together to identify replaceable placeholders in the template. They replace the core parameters (trigger page, trigger condition, data field, etc.) in the decision tree rules and the dependency constraint parameters in the dependency graph into the matching code template placeholders. For example, {triggerPage} is replaced with "list", {dataField} is replaced with "goodsId", and {condition} is replaced with "goodsIdValid===true". At the same time, auxiliary logic such as data type validation and dependency constraint validation is added to ensure that the code can be executed normally.

[0038] Step 4.3, Code Integration: The page order integration subunit, linkage logic association subunit, and code format standardization subunit within the code generation module work together to integrate the replaced single-page code snippets according to the page generation order determined by the topology sort. They add linkage logic association code between pages (such as the association between trigger events and target pages, and the interface logic for data transmission), standardize the code format (indentation, comments, variable naming conventions), remove redundant code, and form a complete set of multi-page linkage code.

[0039] In one embodiment of this invention, three typical multi-page interactive development scenarios (e-commerce multi-page interactive scenario, management system multi-page interactive scenario, and portal system multi-page interactive scenario) were selected for testing and verification. Ten test cases were selected for each scenario, and each case contained 5-8 interactive pages and 12-20 interaction rules. The implementation data and technical effect data are as follows: 1. Implementation of basic data: (1) Requirements analysis steps: The average time for single-case requirements analysis is 2.3 minutes, the accuracy rate of structured requirements model construction is 100%, and there are no problems such as missing requirements information or incorrect parameters; Decision tree construction steps: The average time for single-case decision tree initialization is 1.8 minutes, the redundant branch deletion rate after pruning optimization is 92%, the accuracy rate of conflict branch correction is 100%, and the generated structured interaction rules match the requirements by 98.5%; (2) Dependency graph construction steps: Single case dependency extraction takes an average of 1.5 minutes, the initial dependency graph anomaly detection accuracy is 99%, the efficiency of circular dependency and isolated node correction is 100%, the topology sorting takes an average of 0.8 minutes, and the generated code generation order matches the dependency constraints 100%; (3) Code generation steps: The average time for single-case template calling and parameter replacement was 3.2 minutes, with a parameter replacement accuracy rate of 99.8% and no issues such as missing placeholders or incorrect parameters; the average time for code integration, verification and optimization was 2.2 minutes, with a code syntax verification pass rate of 100% and a linkage logic verification pass rate of 99%. (4) Overall implementation efficiency: The average time for generating complete code for a single case (from requirement input to code package output) is 11.8 minutes, and the success rate of running the code package on the first run after deployment is 99%.

[0040] 2. Comparison data of technical effects (compared with traditional manual development methods): (1) Development efficiency: The traditional manual development of a single case takes an average of 85 minutes, while the method of this invention takes an average of 11.8 minutes, which is 73.2 minutes more efficient, representing an efficiency improvement of 86%. (2) Code quality: The average syntax error rate of traditional manually developed code is 3.8%, and the average error rate of linkage logic is 4.2%; the syntax error rate of the code generated by the method of this invention is 0.2%, and the error rate of linkage logic is 0.1%, which reduces the error rate by more than 95%. (3) Maintenance cost: The code developed manually in the traditional way takes an average of 12.5 minutes to modify a single linkage logic; the code generated by the method of this invention, based on structured rules and dependencies, takes an average of 1.3 minutes to modify a single linkage logic, reducing maintenance cost by 89.6%; (4) Adaptability: The method of this invention is compatible with mainstream front-end frameworks such as Vue and React, with a 100% success rate; traditional manual development requires writing code separately for different frameworks, and the adaptation efficiency is improved by more than 90%.

[0041] The above implementation data fully demonstrates that the technical solution of the present invention can effectively improve the development efficiency and code quality of multi-page linkage code, reduce maintenance costs, and has good adaptability, fully achieving the preset technical goals, solving the core pain points of traditional development, and possessing extremely high practicality and scalability.

Claims

1. A multi-page interactive code generation system based on decision trees and dependency graphs, characterized in that, It includes a requirement parsing module, which is connected to a decision tree construction module and a dependency graph construction module. The decision tree construction module is connected to a rule mapping module, the dependency graph construction module is connected to a rule mapping module, the rule mapping module is connected to a code generation module, and the code generation module is connected to a template library storage module.

2. The multi-page linked code generation system based on decision tree and dependency graph according to claim 1, characterized in that, The requirement parsing module includes a requirement receiving unit and a structured parsing unit connected in sequence; the requirement receiving unit is used to receive multi-page linkage business requirements from external input, and the structured parsing unit parses and processes the original requirement data.

3. The multi-page interactive code generation system based on decision tree and dependency graph according to claim 1, characterized in that, The decision tree construction module includes a node construction unit, a pruning optimization unit, and a rule output unit connected in sequence, and the node construction unit is connected to the structured parsing unit; The node construction unit includes: a page identification subunit that extracts all page nodes from the structured requirement model and determines the root node of the decision tree and candidate page nodes at each level; a condition extraction subunit that extracts all interaction trigger conditions from the requirement model as branch features of the decision tree; a branch generation subunit that generates decision branches according to whether the conditions are met or not, and binds corresponding linkage behaviors to each branch; and a tree structure generation subunit that recursively generates a complete initial decision tree structure according to the hierarchical relationship of the root node, intermediate nodes, and leaf nodes. The pruning and optimization unit includes: a redundant branch identification subunit that traverses the decision tree and identifies redundant branches that have no actual linkage effect or corresponding page behavior; a conflict branch detection subunit that detects logically contradictory and mutually exclusive condition branches in the decision tree; and a tree structure simplification subunit that deletes redundant branches, merges duplicate conditions, and corrects conflicting logic to form a simplified and executable decision tree. The rule output unit includes: a tree traversal subunit that reads each complete path from the root node to the leaf node; a rule formatting subunit that converts each path into a structured rule, in the format of trigger page + trigger condition + execution action + target page; and a rule output interface subunit that organizes all rules into a unified format and outputs them to the rule mapping module.

4. The multi-page interactive code generation system based on decision tree and dependency graph according to claim 1, characterized in that, The dependency graph construction module includes a dependency extraction unit, a dependency verification unit, and a topology sorting unit connected in sequence. The dependency extraction unit includes: a page node parsing subunit that reads all page identifiers from the structured requirement model and establishes a set of page nodes for the dependency graph; a trigger dependency identification subunit that extracts the trigger relationships between pages from interactive behaviors and decision tree branches, identifies which page's behavior triggers which page's linkage, and forms trigger dependency edges; a data dependency identification subunit that extracts the data transfer relationships between pages from the data flow rules of the requirement model, determines the data source page, data target page, transfer fields, and direction, and forms data dependency edges; a rendering dependency identification subunit that identifies the rendering sequence constraints between pages, determines which pages need to complete operations on another page before they can be loaded or updated, and forms rendering dependency edges; and a dependency graph initialization subunit that combines the above page nodes with the three types of dependency edges to construct an initial multi-page dependency graph. The dependency verification unit includes: a loop detection subunit that traverses the dependency edges of the dependency graph to detect whether there are circular dependencies between pages, and marks them as abnormal dependencies if they exist; an isolated node detection subunit that checks whether there are isolated page nodes that have no dependencies and do not participate in the linkage, and marks or filters isolated nodes; a dependency validity determination subunit that determines the rationality of the dependency relationship: whether the triggering dependency has a corresponding interactive behavior, whether the data dependency has clear fields and transmission direction, and whether the rendering dependency conforms to the page loading logic; and an anomaly correction subunit that removes or corrects detected loops, conflicts, and illegal dependencies, and outputs a valid dependency graph that is legal and conflict-free. The topology sorting unit includes: an in-degree calculation subunit that calculates the in-degree of each page node in the legal dependency graph to determine the dependency priority of the node; a topology sequence generation subunit that uses a topology sorting algorithm to generate a sequence of page execution according to the principle of prioritizing dependent pages and postponing dependent pages; a code generation order determination subunit that converts the topology sequence into a code generation order; and a sorting result output subunit that encapsulates the legal dependency graph and the topology sorting result into unified dependency relationship data for output.

5. The multi-page interactive code generation system based on decision tree and dependency graph according to claim 1, characterized in that, The rule mapping module includes a multi-source data receiving unit, a mapping relationship establishment unit, a code generation rule definition unit, a rule verification unit, and a rule output unit connected in sequence. The multi-source data receiving unit includes: a decision tree rule receiving subunit that receives a set of structured interactive logic execution rules from the rule output unit of the decision tree construction module, parses the core parameters of each rule, and converts the rule format into a unified JSON format, where each parameter corresponds to a clear key-value pair. It also filters invalid rules and outputs a standardized decision tree rule set; a dependency relationship data receiving subunit that receives final dependency relationship data containing the topological order from the topology sorting unit of the dependency graph construction module, extracts two types of core information—dependency type, dependency direction, and associated parameters between pages, and the code generation order generated by the topology sorting—and performs structured processing, associating and binding the dependency relationship with the page order to form a three-dimensional mapping table of page identifier-dependency relationship-sorting priority; and a code template information receiving subunit that receives front-end framework code template metadata from the template classification and retrieval unit of the template library storage module, extracts the core information of the template—template identifier, adapting framework, template type, replaceable parameters, and parameter placeholders—and establishes a template metadata index table. The mapping relationship establishment unit includes: a decision tree and dependency mapping subunit that uses page identifier and interaction action as dual primary keys to bind standardized decision tree rules with dependencies in the three-dimensional mapping table, clarifying the dependency constraints that the interaction rule must follow, and generating decision tree rule-dependency mapping pairs; a mapping pair and code template matching subunit that retrieves the code template metadata index table based on the core parameters of the decision tree rule-dependency mapping pair and matches the corresponding code template; if no matching template is found, a template missing prompt is output; and a mapping relationship storage subunit that stores the matched decision tree rule-dependency-code template three-dimensional mapping relationship to a temporary database within the module, establishes a mapping relationship index, and records mapping matching logs.

6. The multi-page linked code generation system based on decision tree and dependency graph according to claim 5, characterized in that, The code generation rule definition unit includes: a basic rule definition subunit that defines general basic rules for code generation, including rules for calling code templates, rules for parameter replacement, and code formatting specifications; an interaction logic rule definition subunit that defines specific interaction logic generation rules for each decision tree rule-dependency-code template mapping pair; an execution order rule definition subunit that defines the execution order rules for code generation based on the page order generated by topological sorting; and a rule standardization subunit that organizes the defined basic rules, interaction logic rules, and execution order rules into a unified JSON format code generation rule set. The rule verification unit includes: a rule validity verification subunit that verifies whether the format of the code generation rule conforms to the standardization requirements, whether the rule content is valid, and whether the associated mapping relationship exists. If an anomaly is found, the anomaly type is marked and a correction suggestion is output; a rule logic verification subunit that verifies whether there are logical conflicts between rules and the compatibility between rules and code templates; a verification result processing subunit that marks the code generation rules that pass the verification and organizes them into a set of valid code generation rules; and for rules that fail the verification, an anomaly report is output and fed back to the mapping relationship establishment subunit and the rule definition subunit for correction and re-verification until all rules pass the verification. The rule output unit includes: a rule formatting output subunit that converts the set of valid code generation rules into a format that the code generation module can directly parse, and adds auxiliary information; and a rule backup and log subunit that backs up the output valid code generation rules and records the rule output log.

7. The multi-page interactive code generation system based on decision tree and dependency graph according to claim 1, characterized in that, The code generation module includes an input data receiving unit, a rule parsing unit, a template calling unit, a parameter replacement unit, a code integration unit, and a code output unit connected in sequence. The input data receiving unit includes: a rule generation receiving subunit that receives a standardized and parsable valid code generation rule set from the rule output unit of the rule mapping module, verifies whether the rule format is compatible with the module interface and whether the rule parameters are complete, marks incomplete rules, converts the format of rules that do not match, and outputs the adapted valid code generation rule set; and a code template receiving subunit that receives front-end framework code templates from the template classification and retrieval unit of the template library storage module, verifies the integrity of the templates, extracts the core structure of the templates, classifies and stores them according to template type, and outputs a standardized code template set that can be directly called. The rule parsing unit includes: an execution order parsing subunit that parses the execution order parameters in the code generation rules, extracts the page generation order determined by the topology sorting, and establishes a page identifier-generation priority mapping table; an interaction logic parsing subunit that parses the interaction logic parameters in each rule, extracts core information, and organizes it into an interaction logic parameter table; and a template matching parsing subunit that parses the template identifier parameters in each rule, associates them with the code template set stored in categories, determines the specific code template corresponding to each interaction logic, and generates an association table of rule identifier-template identifier-template path. The template invocation unit includes: a template retrieval and invocation subunit that, based on the rule identifier-template identifier-template path association table, sequentially retrieves and invokes the corresponding code templates according to the page generation priority order; simultaneously, for each interaction logic, it invokes the corresponding interaction template and loads the template into the module's temporary memory for subsequent parameter replacement; and a template compatibility verification subunit that, after invoking the code template, verifies the compatibility between the template and the interaction logic parameters. If the compatibility fails, it outputs a compatibility exception report and feeds it back to the rule parsing subunit for re-matching the template.

8. The multi-page linked code generation system based on decision tree and dependency graph according to claim 7, characterized in that, The parameter replacement unit includes: a placeholder recognition subunit that traverses the loaded code template, identifies all replaceable placeholders in the template, and establishes a placeholder-template position mapping table; a parameter matching and replacement subunit that, based on the placeholder-template position mapping table and the interaction logic parameter table, replaces the corresponding parameter values ​​into the placeholders in the template; and a replacement result verification subunit that, after the replacement is completed, verifies the accuracy of the replacement result, marks code segments that fail verification, and feeds back to the placeholder recognition subunit for re-replacement. The code integration unit includes: a page order integration subunit that generates a priority mapping table based on page identifiers and integrates single-page code snippets in order; a linkage logic association subunit that adds linkage logic association code between pages based on an interaction logic parameter table; and a code format standardization subunit that performs format standardization processing on the integrated multi-page code, unifying code indentation, comment format, variable naming conventions, and removing redundant code. The code output unit includes: a code packaging subunit that packages a standardized, complete multi-page linked code collection according to front-end project specifications to generate a code package that can be directly deployed. The code package includes page files, style files, and interaction files, and also generates code package documentation; an output log and backup subunit that records code output logs; and a backup of the generated code package.

9. A multi-page cascading code generation method based on decision trees and dependency graphs, characterized in that, Using the multi-page linked code generation system based on decision tree and dependency graph as described in any one of claims 1 to 8, the system includes the following steps: Step 1: Construct a structured requirements model; Step 2: Decompose the interaction logic and generate decision tree execution rules; Step 3: Analyze page relationships, clarify dependency constraints, and build a dependency graph; Step 4: Combine rules and dependencies to automatically generate code.

10. The multi-page linkage code generation method based on decision tree and dependency graph according to claim 9, characterized in that, Step 1 includes: Step 1.1, Requirement Input: The requirement receiving unit receives multi-page linkage business requirements and performs preliminary screening of the input requirements. Step 1.2, Requirements Extraction: The original input requirements are structured and parsed through the structured parsing unit. The page recognition subunit, interaction behavior extraction subunit, and data flow parsing subunit within this unit work together to extract key information one by one and organize the structured key information into a structured requirement model in a unified format. The model output unit will synchronously distribute the completed structured requirement model to the decision tree construction module and the dependency graph construction module. Key information includes: page set, interaction behavior, data flow rules, rendering constraints, and structured requirement model including page node set, interaction behavior set, trigger condition set, data dependency set, and rendering constraint set; Step 2 includes: Step 2.1, Node Definition and Initialization: The page identification subunit, condition extraction subunit, branch generation subunit, and tree structure generation subunit within the node construction unit work together to complete the initial node definition of the decision tree, with the triggering page of multi-page linkage as the root node, the interaction triggering condition as the intermediate branch node, and the linkage behavior of the target page as the leaf node. Step 2.2, Branch Rule Generation and Pruning Optimization: The node construction unit extracts all interaction trigger conditions from the structured requirement model as candidate branch features. Based on the execution logic correlation of the interaction behavior, it determines the optimal trigger conditions at each level and generates corresponding intermediate nodes. According to the binary branch logic of the trigger conditions being met / not met, it splits the branches of each intermediate node, maps the page linkage behavior matched by each branch to leaf nodes, and recursively executes this process to generate an unpruned initial interaction decision tree. The redundant branch identification subunit, conflict branch detection subunit, and tree structure simplification subunit within the pruning optimization unit work together to traverse the initial decision tree, identify and delete redundant branches, detect and correct conflict branches, merge duplicate conditions, and generate an optimized decision tree. Step 2.3, Rule Standardization and Output: The tree traversal subunit, rule formatting subunit, and rule output interface subunit within the rule output unit work together to perform a depth-first traversal of the optimized decision tree, read each complete path from the root node to the leaf node, transform each path into a set of structured interactive logic execution rules in the format of trigger page + trigger condition + execution action + target page, and output the rule set to the subsequent rule mapping module. Step 3 includes: Step 3.1, Node and Dependency Edge Extraction: The page node parsing subunit, trigger dependency identification subunit, data dependency identification subunit, and rendering dependency identification subunit within the dependency extraction unit work together to extract the trigger dependency relationship, data dependency relationship, and rendering dependency relationship between pages as dependency edges, using the set of pages in the structured requirement model as nodes in the dependency graph. Step 3.2, Dependency Graph Initialization: The dependency graph initialization sub-unit of the dependency extraction unit combines the extracted page nodes with the three types of dependency edges to construct an initial multi-page dependency graph, clarifies the association parameters of each dependency edge, and presents it in the form of a directed graph; Step 3.3, Dependency Validation and Topology Sorting: The loop detection subunit, isolated node detection subunit, dependency validity determination subunit, and anomaly correction subunit within the dependency validation unit work together to validate the initial dependency graph, detect the existence of circular dependencies, isolated nodes, and illegal dependencies, remove or correct detected abnormal dependencies, and generate a valid and conflict-free final dependency graph. The in-degree calculation subunit, topology sequence generation subunit, code generation order determination subunit, and sorting result output subunit within the topology sorting unit work together to perform topology sorting based on the final dependency graph, calculate the in-degree of each page node, generate the execution sequence of pages, and output the final dependency relationship data containing the topology order to the rule mapping module. Step 4 includes: Step 4.1, Rule Mapping and Template Matching: The multi-source data receiving unit of the rule mapping module receives decision tree rules, dependency data, and code template metadata, processes them in a standardized manner, and then passes them to the mapping relationship establishment sub-unit. The mapping relationship establishment unit establishes a three-dimensional mapping relationship between decision tree rules, dependencies, and code templates. Based on the mapping relationship, the code generation rule definition unit defines basic rules, interaction logic rules, and execution order rules. After verification by the rule verification unit, the rule output unit outputs the valid code generation rules to the code generation module. The input data receiving unit of the code generation module receives the valid code generation rules and also receives the standardized code templates from the template library storage module, stores them according to function, and matches the corresponding templates. Step 4.2, Parameter Replacement: The rule parsing unit of the code generation module parses valid code generation rules, extracts core parameters, and passes them to the template calling unit. The template calling unit loads the adapted code templates in sequence. The placeholder identification subunit, parameter matching and replacement subunit, and replacement result verification subunit within the parameter replacement unit work together to identify replaceable placeholders in the template, replace the core parameters in the decision tree rules and the dependency constraint parameters in the dependency graph with the matching code template placeholders, and add auxiliary logic to ensure that the code can be executed normally. Step 4.3, Code Integration: The page order integration unit, linkage logic association unit, and code format standardization unit within the code integration unit of the code generation module work together to integrate the replaced single-page code fragments according to the page generation order determined by the topological sorting, add linkage logic association code between pages, unify the code format, remove redundant code, and form a complete multi-page linkage code set.

Images