An automated software code generation method and system based on inheritance relationships and flow rules

Abstract

This invention relates to the field of software engineering technology, specifically to an automated software code generation method and system based on inheritance relationships and flow rules. The method includes receiving a module hierarchy definition, where each module includes a starting module, inheriting modules, and a final-level module, enabling automatic inheritance of fields and business logic; defining the forward and reverse flow of data between modules and reverse blocking conditions; automatically identifying relationships between modules and generating join logic through an AI agent; and automatically generating forward code for data tables, API interfaces, and front-end pages, as well as reverse business logic code for handling anti-approval, withdrawal, rollback, and offsetting documents, based on the definitions and identification results. It also supports saving the generated complete module chain as a template for rapid replication of similar systems. This invention solves the problems of long development cycles, complex reverse processes, and poor reusability in traditional development and low-code platforms, enabling business personnel to quickly generate a complete, runnable business system without writing any code.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, specifically to an automated software code generation method and system based on inheritance relationships and flow rules. Background Technology

[0002] In traditional software development, after business users raise their requirements, product managers need to translate them into requirements documents, and then developers implement the code. This model has the following significant problems: 1. High communication costs and long development cycles: There is a cognitive gap between business personnel and developers, and misunderstandings of requirements lead to repeated modifications. It usually takes several weeks or even months from requirements to system launch.

[0003] 2. Complex reverse business processes and lack of universal solutions: The reverse operation logic in the business system, such as withdrawal, unaudit, and rollback, is complex. It usually requires developers to do a lot of customized coding for different scenarios, which is difficult to implement and prone to errors.

[0004] 3. Poor system reusability: Even business modules with similar functions cannot be quickly copied and need to be repeatedly developed from scratch, resulting in a waste of resources.

[0005] While low-code platforms, which have emerged in recent years, have lowered the development threshold to some extent, they still have the following shortcomings and have failed to fundamentally solve the above problems: The configuration of modules and relationships is cumbersome: the hierarchy and inheritance relationships between modules need to be configured manually, and the automatic inheritance of fields and business logic cannot be achieved.

[0006] Business process definition relies on manual intervention: the rules for the forward flow and reverse rollback of data need to be defined and coded manually, and cannot be automatically generated based on the rules.

[0007] Weak reverse process handling capability: For complex reverse operations (such as rolling back executed documents), the platform lacks a unified, configurable, and universal solution, and still requires a lot of customized development.

[0008] The user threshold still exists: users still need to have a certain programming foundation and the ability to understand data models, which has not completely freed up business personnel. Summary of the Invention

[0009] To address the shortcomings of existing technologies, this invention provides an automated software code generation method and system based on inheritance relationships and flow rules. It aims to solve the technical problems of long software development cycles, complex reverse processes, and poor reusability in existing technologies, enabling business personnel to quickly generate runnable business systems without writing any code.

[0010] This invention is achieved through the following technical solution: An automated software code generation method based on inheritance relationships and flow rules is provided, including the following steps: S1. Module Definition: Receives the module hierarchy structure input by business personnel. The module includes the starting module, the inheriting module, and the last module. The inheriting module automatically inherits all fields and business logic of its parent module. The last module contains all fields of the parent module and the fields specific to this module. S2, Flow direction definition: Defines the data flow direction between modules, forming a unidirectional pipeline from the starting module to the last module. The data flow direction includes forward flow and reverse flow. S3. Relationship Judgment: The AI ​​agent automatically identifies one-to-one, one-to-many, or many-to-many relationships between modules and generates corresponding inter-table lookup logic. S4. Forward Code Generation: Based on module definitions, data flow, and identified relationships, automatically generate data table structures, API interfaces, front-end pages, and workflow engine code; S5. Reverse Rule Definition: Reverse blocking conditions received from business personnel; S6. Reverse Code Generation: Based on the reverse blocking conditions, automatically generate reverse business logic code for handling unaudited, withdrawn, rolled back, and offset documents; S7. Template Copy: Saves the generated complete module chain and its associated code as a template. By replacing the module name and field name in the template, it can quickly copy and generate new business system code.

[0011] Furthermore, in S1, when a field defined by a submodule conflicts with a field inherited from a parent module, it is handled according to preset conflict resolution rules, which include submodule priority, parent module priority, merging and checking, or forced renaming.

[0012] Furthermore, in S5, the reverse blocking conditions include at least one of the following: the final module has been confirmed, there is an executed downstream document, the document has been finalized, and the business cycle has been closed.

[0013] Furthermore, in S6, when the reverse blocking condition is met, the final authorization release operation or the reverse hedging operation is performed.

[0014] The reverse hedging operation includes: automatically generating a hedging business document based on the type of the original business document. The key value of the hedging business document is the negative value of the corresponding value in the original document, so as to achieve business hedging.

[0015] Furthermore, hedging documents include return slips, refund slips, or time cancellation slips.

[0016] Furthermore, in S7, templates use a tag-based variable substitution syntax that supports multi-granularity variable substitution at the system, module, field, and relation levels, and also supports loop and conditional logic.

[0017] An automated software code generation system based on inheritance relationships and flow rules includes: The input module is used to receive input from business personnel regarding the module hierarchy structure, field definitions, and reverse blocking conditions. The intelligent agent module is used to call the AI ​​model to automatically identify the relationships between modules; The relationship judgment module is used to process and output the module relationship results identified by the AI ​​agent; The forward generation module is used to generate forward business logic code based on module definitions, data flow, and relationships. The reverse engineering module is used to generate reverse business logic code based on the reverse engineering blocking conditions. The template management module is used to save and manage form templates and supports template copying operations; The execution module is used to integrate and output the final, complete business system code.

[0018] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements an automated software code generation method based on inheritance relationships and flow rules.

[0019] A computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements an automated software code generation method based on inheritance relationships and flow rules.

[0020] The beneficial effects of this invention are: First, business personnel do not need to write any code. They can directly generate the system by defining business modules and process rules, which shortens the development cycle from weeks to minutes, greatly reducing the development threshold and cycle.

[0021] Second, through the "reverse blocking rules" and "reverse hedging" mechanism, a standardized and automated code generation solution is provided for complex business rollback operations, solving the problem of customized development of reverse processes, providing a unified and powerful reverse process processing capability, and systematically solving the implementation problem of complex reverse processes.

[0022] Third, by defining modular inheritance to achieve automatic inheritance of fields and logic, the "form template copying" function enables a set of business models to be reused infinitely and quickly, which greatly improves development efficiency, reduces the construction cost of similar systems, and achieves high reusability.

[0023] Fourth, the AI ​​intelligent agent automatically determines the relationship between modules and automatically merges fields and logic through the inheritance mechanism, which significantly reduces the workload of manual configuration and has a high degree of intelligence and automation. Attached Figure Description

[0024] Figure 1 This is a flowchart of the overall process of the method of the present invention.

[0025] Figure 2 This is a schematic diagram of the module inheritance relationship in this invention.

[0026] Figure 3 This is a schematic diagram of the forward and reverse flow directions in this invention.

[0027] Figure 4 This is a system architecture block diagram of the present invention.

[0028] Figure 5 This is a flowchart illustrating the business judgment and execution process for reverse hedging in this invention. Detailed Implementation

[0029] To clearly illustrate the technical features of this solution, the following detailed implementation method will be used to explain the solution.

[0030] The following embodiments use a work order management system in the testing industry as an example to illustrate the complete process of this invention from business definition to the generation of a runnable system. Those skilled in the art will understand that this example is only for illustrating the principles of the invention, and its application is not limited to this specific business scenario.

[0031] The overall execution flow of the method of this invention is as follows: Figure 1 As shown in the diagram, this illustrates the complete flow from user input to system output. The flow begins with the user input module definition (supporting Excel upload, JSON import, and manual configuration). The system then executes the inheritance relationship parsing step, constructing a module tree and merging fields. Next, the system calls AI to determine the relationships between tables, identifying one-to-one, one-to-many, and many-to-many relationships. Then, the system constructs the data flow direction, including forward flow and reverse blocking rules. Afterward, the system generates forward code, including database DDL, backend API, and frontend pages. Simultaneously, the system generates reverse code based on the reverse blocking rules, including anti-audit logic and offsetting document logic. Finally, the system outputs a runnable business system code package. The flowchart uses rectangles to represent steps and arrows to connect them to indicate the flow direction.

[0032] System architecture such as Figure 4As shown, users define business modules by uploading Excel files, configuring JSON, or manually entering information through a web interface. The system then automatically performs a series of steps, including resolving inheritance relationships, using AI to intelligently determine relationships between tables, constructing data flow (including forward and reverse rules), and generating forward and reverse code. Finally, it outputs a full-stack business system code package that can be directly deployed and run.

[0033] Step 1: Module Definition and Inheritance Handling Business personnel first define the system's module hierarchy. Each module includes a name, hierarchy, type, and set of fields. Module types are categorized as follows: Starting point module: The starting point of the business chain, with no superior module.

[0034] Inherited Module: Automatically inherits all fields and business logic from its parent module.

[0035] Last-level module: At the end of the business chain, it inherits all fields from its parent module and includes fields specific to this module.

[0036] Taking the work order management system as an example, the definitions are shown in Table 1: Table 1: Examples of Module Definitions Work Order Summary 1 starting point none Work order number, project name, planned working hours Work order 2 inherit Work Order Summary Workers dispatched, workers assigned, dispatch time Report work order 3 Final level Work order Actual working hours, work content, and confirmation status like Figure 2 As shown in the diagram, taking a work order management system as an example: the top layer is the work order master table module, marked as the first-level starting module; the middle layer is the work order dispatch module, marked as the second-level inherited module; and the bottom layer is the work order reporting module, marked as the third-level final module. The diagram also indicates the field inheritance relationship: the work order dispatch module includes all fields from the work order master table plus two newly added fields: dispatcher and dispatch time; the work order reporting module includes all fields from the work order dispatch module plus two newly added fields: actual working hours and confirmation status.

[0037] Work orders automatically inherit all fields (work order number, project name, etc.) and business logic from their parent module's work order master table; work reports automatically inherit all fields and logic from both the work order master table and the work order table, and also have their own exclusive fields.

[0038] Field conflict resolution rules: During module inheritance, if a field defined in a submodule conflicts with a field in a parent module (e.g., duplicate names but different data types), the system provides configurable resolution rules. For example, this embodiment uses the "submodule priority" rule, meaning that the field definition in the submodule will override the field definition with the same name in the parent module. Other optional rules include "parent module priority," "check after merging," and "force renaming," which users can select as needed in the system configuration.

[0039] Step 2: Defining Data Flow Direction and Reverse Rules The system automatically constructs a unidirectional data pipeline from the starting point to the end point based on the module hierarchy, such as... Figure 3 As shown, the forward flow from left to right consists of four nodes: creating a work order, approving work assignment, executing work reporting, and completing archiving. These nodes are connected by right-pointing arrows. The reverse flow from left to right consists of four nodes: withdrawing a work order, withdrawing work assignment, canceling work reporting, and canceling archiving. These nodes are also connected by right-pointing arrows. The diagram indicates blocking conditions at the work reporting node: a work order cannot be directly withdrawn after confirmation; it requires authorization from the worker to cancel confirmation, and after cancellation, the process traces back upwards level by level. Furthermore, the reverse business process rules must be defined by business personnel; this is one of the core innovations of this invention.

[0040] Forward flow: This refers to the creation and advancement process of the corresponding business, where data flows from the upper level to the lower level, i.e., "creating a work order - dispatching work - executing work report".

[0041] Reverse flow: This refers to the rollback and correction process for the corresponding business, where data is traced back from the last level to the starting point, i.e., "withdrawal of work order - withdrawal of work assignment - withdrawal of work order".

[0042] To standardize reverse operations, business personnel need to define reverse blocking conditions. In this embodiment, the business personnel input the following natural language rule: "Once a work order is confirmed, it cannot be withdrawn directly; the worker must cancel the confirmation." The system parses this into a structured blocking rule. This invention presets several basic blocking condition types for combined use, including: Last-level node blocking: When the status of the last-level module (work order) is "confirmed", direct withdrawal is prohibited.

[0043] Downstream document blocking: If there are already executed related downstream documents, direct rollback is prohibited.

[0044] Final approval blocking: Once a document has been finally approved, it cannot be modified.

[0045] Business cycle interruption: Operations are prohibited after the financial month or project quarter to which the document belongs is closed.

[0046] Execution status blocking: When a document is in the "Executing" or "Completed" status, it cannot be withdrawn.

[0047] Users can combine multiple conditions using "AND" and "OR" logic to form compound rules. The system has a built-in rule engine that evaluates these conditions in real time when a reverse operation is triggered.

[0048] For example, the reverse rule for a work order can be defined as: "If (the work order confirmation status is confirmed) or (there is a downstream quality inspection order and the quality inspection order status is passed), then trigger blocking."

[0049] Step 3: AI-powered intelligent relationship judgment and joint query logic generation Detailed description of the AI ​​agent workflow: In this step, the AI ​​agent follows a clear "input-processing-output" process to ensure the automation and accuracy of relationship recognition.

[0050] Input: The system structures the module definition into a JSON object as input.

[0051] Processing: The system calls the configured large language model API and sends a carefully crafted prompt word. The core of the prompt word template includes: Role Instruction: "You are a database design expert. Please analyze the relationships between the following business modules." Task requirements: The AI ​​is required to output the inheritance chain and determine whether any two modules have a "one-to-one", "one-to-many", or "many-to-many" relationship, and explain the reasoning.

[0052] Output format constraints: AI is strictly required to output in the specified JSON format.

[0053] Output and Parsing: The system receives the JSON results returned by the AI, which are then parsed by the "relationship judgment module." Taking the work order management system input in this embodiment as an example, the JSON results output by the AI ​​agent after analysis include the following core parts: The inheritance chain [“Work Order Master Table”, “Work Order Dispatch”, “Work Order Report”] clarifies the hierarchical relationship of the modules.

[0054] Relationship list: An array of relationships that automatically identifies the connections between modules.

[0055] The parsing process includes: validating the JSON format, extracting each item from the relationships array, and converting it into a data structure that can be directly used in the subsequent code generation stage (such as foreign key constraint objects and ORM association mapping configurations) based on fields such as foreign_key_suggestion and join_sql_template.

[0056] Step 4: Forward Code Generation Based on the complete configuration (modules, fields, inheritance relationships, data flow, and inter-table relationships) obtained from the aforementioned steps, the system calls the template engine to generate full-link forward code.

[0057] Data Table Structure (DDL): Based on the module fields and AI suggestions, generate SQL statements to create three tables and establish foreign key constraints.

[0058] API Interface: Generate complete CRUD (Create, Read, Update, Delete) RESTful API code for each module.

[0059] Front-end pages: Generate the corresponding front-end code (such as Vue / React components) for each module's list page, form page, and detail page.

[0060] Workflow engine code: Integrates forward flow logic, generating code that drives the flow from work order creation to work completion.

[0061] Step 5: Reverse Code Generation This is one of the core innovations of the present invention: the system automatically generates logic code for handling complex rollback business based on the defined reverse blocking rules.

[0062] Detailed explanation of the reverse hedging code generation logic: When a reverse rule is triggered and a "reverse offsetting" operation is required, the system automatically generates the creation logic for the offsetting document based on the type of the original business document. This logic is embedded in the generated ReverseService or similar service layer code, and its core generation algorithm and pseudocode are as follows: 1. Determine the offsetting order type: The system has a built-in mapping table of "document type - offsetting order type". For example, an outbound order is mapped to a return order, a payment order is mapped to a refund order, and a work order is mapped to a work hour cancellation order.

[0063] 2. Generate hedging order data: The system-generated code logic will execute the following steps: Retrieve Original Document: Retrieve the complete original business document data (original_doc) based on the document ID of the operation.

[0064] Create an offset document instance: Instantiate a new offset document object (offset_doc).

[0065] Field value offsetting: The key business fields (such as quantity, amount, and working hours) of the original document are negativeized and then assigned to the corresponding fields in the offset document. For example: offset_doc.quantity = -original_doc.quantity.

[0066] Copy the associated and descriptive fields of the original document (such as business type, project ID, and material number).

[0067] Automatically generate associated identifiers: Set the original_doc_id field in the hedging order to record the original order ID and establish a two-way traceability relationship.

[0068] 3. Generate executable code framework: The system generates method code in the service layer in the style of Java / Spring framework.

[0069] 4. Business process integration: The generated GenerateOffsetDocument method will be automatically integrated into the entry function of the "recall" or "rollback" operation. It will be called after the reverse blocking condition is judged, thus forming a complete and traceable business hedging closed loop.

[0070] When a user triggers a reverse operation, the system executes as follows: Figure 5 The logic shown: When a reverse operation is triggered, the system first calls the reverse blocking judgment function (ReverseCheck function) to check whether the current document status meets the preset blocking conditions.

[0071] If the conditions are met, the corresponding general reverse processing logic is executed: In this embodiment, a simple scenario is described: the last-level authorization is revoked (corresponding to "last-level node blocking"). For the condition "work order confirmed", the system generates a "last-level authorization release" code: check whether the operator is the person who submitted the work order or his / her authorized person. After verification, the status of the work order is set to "released" and then traced back up level by level (work order, work order master table) to update its status to "can be withdrawn".

[0072] For more complex scenarios, such as "downstream documents have been executed," the system will generate "reverse hedging" code. For example, in an inventory outbound scenario, when an executed outbound order is withdrawn, the system does not directly delete the record but automatically generates an hedging business document (such as a return order). The key quantity / amount of this hedging order is the negative value of the original document (e.g., amount = -original_amount). After execution, the business data is reset to zero, while ensuring a complete operation audit trail. This invention predefines several hedging types, including inventory hedging (generating return orders), financial hedging (generating refund orders), and work order hedging (offsetting work hours).

[0073] Figure 5 The flowchart illustrates the business judgment and execution process of reverse hedging. The process begins with a user initiating a cancellation request. The system first checks for blocking conditions, determining whether the current document meets the conditions for a final-level node, whether there are downstream documents, and whether it has been finalized. If no blocking conditions exist, the system allows direct cancellation, updates the document status, and traces back level by level, finally recording the operation log to complete the cancellation. If blocking conditions exist, the system triggers reverse hedging, generating the corresponding hedging document (return order, refund order, or canceled work order) based on the document type, executing the hedging operation (inventory hedging, financial hedging, or work hour hedging), marking the original document as hedging-ready, and finally completing the cancellation. The flowchart uses diamonds to represent judgment nodes, rectangles to represent operation nodes, and arrows to indicate the flow direction.

[0074] Step 6: Copy the form template The system will package and save the complete module chain of the successfully generated work order management system, all configuration rules, and generated code into a template.

[0075] Template syntax: Template files use double curly braces {{variable}} to mark variables, and support {% for ... %} loops and {% if ... %} conditional statements.

[0076] Variable granularity: Four levels of variables are defined: system level (e.g., {{system_name}}), module level (e.g., {{module_name}}), field level (e.g., {{field_type}}), and relation level (e.g., {{foreign_key}}), enabling fine-grained replacement.

[0077] Rapid replication: When a similar maintenance work order system needs to be developed quickly, business personnel only need to replace the module names with "Maintenance Request Form," "Maintenance Dispatch Form," and "Maintenance Completion Form" on the template, and adjust some field names. The system, through template engine rendering, can generate a completely new set of business system code with a complete forward and reverse process within minutes, achieving efficient reuse of the solution.

[0078] System module interaction and data flow The system architecture of this invention is as follows: Figure 4 As shown, a layered design is adopted, and modules collaborate through clear data flow: User input: Receive the module definition Excel / JSON (data flow one) through the web interface.

[0079] Parsing and Construction: Parsing modules, handling inheritance, and building relational trees (Data Flow II and III).

[0080] AI intelligent analysis: The structured module data is sent to the AI ​​agent for relationship judgment (data flow four).

[0081] Code generation: The template engine receives the AI ​​results and all configurations, and renders and generates forward and reverse code (data flow five).

[0082] Output and Deployment: Output the final code package to the file system and make it available to users for download and deployment (Data Flow 6).

[0083] Figure 4The system's three-tier architecture is illustrated in a layered diagram. The top layer is the user layer, comprising four roles: business users, developers, administrators, and AI agents. The middle layer is the interaction layer, including three interaction entry points: Web interface, REST API, and file upload. The core layer includes six core functional modules: parsing module, relationship judgment module, agent module, inheritance processing module, flow construction module, and reverse generation module. The bottom layer is the data layer, including three data storage and output modules: template library, SQL generator, and code output. Layers are separated by horizontal lines, and arrows indicate call relationships between modules.

[0084] The entire process is automated, requiring no manual coding intervention, and ultimately delivers a complete business system that can be run directly, including the interface, logic, and database.

[0085] To quantify and verify the beneficial effects of the present invention, comparative tests were conducted on the above-described work order management system embodiments. The tests selected business scenarios with the same requirements and implemented them using the method of the present invention, existing low-code platforms (such as Siemens Mendix (version 11.8)), and traditional manual coding methods, respectively. Key comparisons are shown in Table 2 below: Table 2: Comparison Test Data of Technical Effects Time spent by business personnel completing configuration / input Approximately 8 minutes Approximately 90 minutes not applicable System end-to-end code automatic generation time Approximately 2 minutes Approximately 30 minutes (partially generated) not applicable Total time from demand to a working system <10 minutes Approximately 2 hours Approximately 24 hours Number of lines of business logic code that need to be written manually 0 lines Approximately 200 lines Approximately 2000 lines Automatic generation rate of reverse process code 100% <30% 0% Number of test defects that generate reverse code 0 Incomplete generation An average of 4 per scene Time consumption of generating similar systems based on templates 5 minutes Still requires a large amount of configuration Approximately the time taken by the first system Test data shows that this invention, through module inheritance and flow rule-driven automated code generation, can improve the construction efficiency of business systems by orders of magnitude, completely eliminate the need for manual coding of business logic (especially complex reverse processes), and achieve near-zero-cost solution reuse through template copying, thereby comprehensively solving core problems such as long development cycles, complex reverse processes, and poor reusability.

[0086] In this invention, the reverse blocking conditions are defined using rule expressions described in natural language. Each blocking condition consists of three parts: the triggering object, the judgment condition, and the blocking result.

[0087] Triggering Target: Specifies which business node or data state this rule applies to. For example, it applies to the "Work Order" node, or to the "Contract Status is Finalized" state.

[0088] Judgment conditions: Describe the circumstances under which the blocking is triggered using the "if...then..." structure. For example: "If the current document is at the last level node and its status is confirmed, then the blocking is triggered."

[0089] Blocking Result: Describes the operation the system should perform after the blocking is triggered. For example: "Direct revocation is prohibited; prompts that the lowest level authorization needs to be lifted."

[0090] This invention pre-sets five basic blocking condition types, which users can select and combine in the configuration interface: The first method is blocking at the last-level node. When a business process reaches the last node (e.g., submitting a work order) and that node has been confirmed as completed, the system prohibits users from directly withdrawing or deleting the document. Users must obtain authorization from the last-level node to remove the confirmation status, and then withdraw the document by tracing back up the hierarchy.

[0091] The second method involves blocking downstream documents. When a current document has related downstream documents (such as an outbound order corresponding to inventory details) and the downstream document is already in progress or completed, the system prohibits directly deleting the current document. Users need to generate offsetting documents through reverse offsetting to handle this.

[0092] The third type: Final review blocking. When a document has completed three or more levels of approval and its status is marked as "finally approved," the system prohibits users from modifying the document content. Users need to initiate a "reverse review" process to go through the approval chain again.

[0093] The fourth type: Business cycle blocking. When the business cycle to which a document belongs (such as a financial month or project quarter) has been marked as "closed" by the system, the system prohibits any modification or withdrawal operations on documents within that cycle.

[0094] Fifth type: Execution status blocking. When the execution status of a document is "in execution" or "completed", the system prohibits the cancellation operation of the document.

[0095] Users can combine multiple blocking conditions to form compound rules. Combination methods support both AND and OR logic:

[0096] The combined expression is: if (the current node is a work order and the work order status is confirmed) or (there is a downstream work order and the work order status is dispatched), then the blocking is triggered and withdrawal is prohibited.

[0097] The combined expression is: if (the contract status is finalized and the review level reaches level three) or (there is an associated work order and the work order status is not cancelled), then the blocking is triggered, and modification of the contract is prohibited.

[0098] The combined expression is: if (the purchase order status is paid) or (the receipt status is received and there is an associated inventory detail record), then the blocking is triggered, and the system automatically generates a return order to offset the order.

[0099] The system has a built-in rule evaluation engine, and its execution flow is as follows: The first step is for the system to read the node location and status information of the current document.

[0100] The second step is for the system to obtain the blocking rule expression corresponding to the document type.

[0101] Third, the system evaluates each condition from left to right. For AND logic, all conditions must be met simultaneously to trigger blocking; for OR logic, blocking is triggered if any one condition is met.

[0102] Fourth, if the evaluation result is "block", the system returns the blocking type and the reason for blocking; if the evaluation result is "allow", the system continues to perform subsequent operations.

[0103] The AI ​​agent in this invention uses the following structured prompt template when determining relationships between tables. This template consists of five parts: Part 1: Role Definition. The system tells the AI: "You are a database relational analysis expert."

[0104] Part Two: Input Data Description. The system provides the AI ​​with JSON format data defining the modules, including the system name, names of each module, field list, and inheritance relationship annotations.

[0105] Part Three: Task Description. The system requires the AI ​​to complete the following four sub-tasks: identify the parent module of each module and output the inheritance chain; determine the one-to-one, one-to-many, and many-to-many relationships between modules; output table creation suggestions for each foreign key relationship; and output templates for join SQL statements for each relationship.

[0106] Part Four: Output Format Constraints. The system requires AI to output results in a fixed JSON format, ensuring that the output can be automatically parsed by the program.

[0107] Part 5: Example Guidance. The system provides a simplified example to help the AI ​​understand the task requirements.

[0108] The module definitions entered by the user into the system adopt the following data format: First, there is a system name field, which identifies the name of the current business system; then there is a list of modules, each module in the list containing a module name, inheritance source (if the module inherits from other modules), and a list of fields for that module. Each field in the field list contains attributes such as field name, data type, and whether it is required.

[0109] Taking the work order management system as an example, the modules for user input are defined as follows: the work order module is the first-level module, which includes four fields: work order number, project name, planned working hours, and status; the work dispatch module inherits from the work order module and adds two fields: assignor and dispatch time; the work report module inherits from the work dispatch module and adds three fields: actual working hours, work content, and confirmation status.

[0110] The results output by the AI ​​agent after analysis include two parts: inheritance chain and relationship list.

[0111] The inheritance chain section records the name of the parent module and the hierarchy depth of each module. For example: the work order module has no parent module and is at the first level; the work dispatch module's parent module is the work order module and is at the second level; the work report module's parent module is the work dispatch module and is at the third level.

[0112] The relationship list section records the table relationships between modules. Each relationship record includes the source table name, target table name, relationship type (one-to-one, one-to-many, or many-to-many), foreign key field name, and a template for the join SQL statement.

[0113] Reverse hedging is a reverse process handling method proposed in this invention. When a forward business process needs to be withdrawn, the system does not directly delete the already generated data records, but automatically generates a reverse business document. The business data is offset and zeroed out through these two documents ("forward + reverse"). This method ensures the integrity and traceability of data auditing.

[0114] This invention defines three basic hedging types: The first method is inventory hedging. When a user needs to cancel an outbound order that has already been shipped, the system will automatically generate a return order. The quantity in the return order is a negative value, which, when added to the quantity in the original outbound order, equals zero. After the return order is executed, the inventory quantity is restored to its state before the outbound shipment.

[0115] The second method is financial hedging. When a user needs to withdraw a payment received, the system automatically generates a refund order. The refund amount is equal to the original payment amount. After the refund order is executed, the accounts receivable balance is restored to its pre-payment state.

[0116] The third method: Work order offsetting. When a user needs to withdraw a confirmed work order, the system will reset the work order's confirmation status to unconfirmed and return the already recorded work hours. This operation can only be performed by the creator or authorized person of the work order.

[0117] When the system performs a reverse hedging, it follows these steps: The first step is for the system to receive the cancellation request initiated by the user and obtain the type and identifier of the original document.

[0118] The second step is for the system to query the preset hedging rule mapping table based on the type of the original document to determine the type of hedging document to be generated.

[0119] The third step involves the system creating an offsetting document, setting the source identifier field of the offsetting document to the identifier of the original document, and setting the quantity or amount field of the offsetting document to the negative value of the corresponding field in the original document.

[0120] The fourth step is for the system to save the hedging documents to the database and mark the status as "effective".

[0121] The fifth step is to update the status of the original document to "offset" and record the identifier of the offset document in the original document to establish a two-way association.

[0122] Taking material requisition and outbound operations as an example, the complete process of reverse hedging is explained: Forward Flow: The warehouse manager creates an outbound order, which includes material A and the quantity to be issued: 100. The system executes the outbound operation, deducting the inventory quantity of material A by 100 from the inventory details table. The production line retrieves the material based on the outbound order.

[0123] User-initiated order cancellation: An operator discovers an error in the outbound order and initiates a cancellation request.

[0124] System detection: The system detected that a deduction record corresponding to the outbound order already exists in the inventory details table, triggering the offsetting rule.

[0125] Hedging Execution: The system automatically generates a return order. The material in the return order is material A, and the quantity is 100 (a positive number, indicating receipt). After the return order is executed, the inventory quantity of material A in the inventory details table increases by 100, restoring it to the state before the outbound shipment.

[0126] Result: The original outbound order is marked as "offset", the newly generated return order is associated with the original outbound order, and all operation records are traceable.

[0127] In the process of module inheritance, when a field defined by a submodule conflicts with a field inherited from a parent module, this invention defines four conflict types: Category 1: Field name duplication conflict. A field name explicitly defined in a submodule is exactly the same as a field name that already exists in the parent module.

[0128] The second type: data type conflict. The data type of a field in the submodule is inconsistent with the data type of a field with the same name in the parent module.

[0129] Category 3: Required attribute conflict. The required field settings for a field in a submodule are inconsistent with the required field settings for the same name in the parent module.

[0130] Category 4: Default value conflict. The default value setting of a field in a submodule is inconsistent with the default value setting of a field with the same name in the parent module.

[0131] This invention provides four conflict resolution rules, which users can select from in the system configuration interface: Rule 1: Submodules take precedence. When field conflicts occur, the system prioritizes the field attributes defined in the submodule, with the submodule's fields overriding the parent module's fields. This rule applies to scenarios where submodules have special business requirements.

[0132] Rule 2: Parent module takes precedence. When field conflicts occur, the system prioritizes the field attributes defined in the parent module, ignoring conflicting field definitions in the child module. This rule is suitable for scenarios that maintain system-wide field consistency.

[0133] Rule 3: Post-merge check. The system attempts to merge the field attributes of the parent and child modules. For data types, the one with the stricter classification should be used (e.g., the parent module is defined as text type, the child module is defined as numeric type, and the merged module uses numeric type). If unresolved conflicts still exist after merging, the system will report an error and require the user to handle it manually.

[0134] Rule 4: Mandatory Renaming. The system requires users to rename conflicting fields to other names within submodules, and does not allow overwriting fields from the parent module.

[0135] The system provides a conflict resolution rule configuration interface, allowing users to select rules individually for each inheritance relationship or set a default rule for the entire system. Once a rule is selected, the system will automatically apply that rule to handle all field conflicts when generating code.

[0136] This invention uses a tag-based variable substitution syntax. Variables are represented in the template file by identifiers enclosed in double curly braces, in the format: {{variable name}}.

[0137] For example, the system name variable is written as "{{ system_name}}", which will be replaced with the actual system name in the configuration during rendering.

[0138] For content that needs to be generated repeatedly (such as iterating through all modules to generate table creation statements), the system supports loop syntax. The format of loop syntax is: {% for item in list%} ... {% endfor %}.

[0139] For example, when iterating through all modules to generate a CREATE TABLE statement, the template should contain "for module in module list", the table creation statement template for that module should be written in the middle, and "endfor" should be written at the end.

[0140] The system supports conditional statement syntax, with the format: {% if condition%} ... {% endif %}.

[0141] For example: Determine if a field is required; if so, add a "NOT NULL" constraint after the field definition.

[0142] This invention defines four levels of variable granularity: Level 1: System-level variables. Their scope covers the entire system, including global configuration items such as system name, database type, and project name. These variables are replaced once when the template is loaded.

[0143] Level 2: Module-level variables. These variables apply to the currently processed business module, including the module name, its Chinese display name, and its hierarchy depth. These variables are replaced sequentially as the module list is traversed.

[0144] Level 3: Field-level variables. Their scope is a single field within the current module, including the field name, data type, whether the field is required, and its default value. These variables are replaced sequentially as the field list is iterated.

[0145] Level 4: Relationship-level variables. Their scope extends to inter-table relationships, including source table name, target table name, foreign key field name, and relationship type. These variables are used when generating foreign key constraints and join statements.

[0146] This invention provides several pre-built standard template files, such as the app.py template file. The structure of this template file is as follows: first, it imports the Flask framework and database driver module; then, it defines the database connection function; next, it uses loop syntax to iterate through the module list to generate table creation statements for each module; then, it uses loop syntax to generate CRUD interface functions for each module; finally, it generates the startup code. System-level variables are used to replace the system name, database file name, and port number in the template.

[0147] This invention adopts a layered architecture design, with interactions between system modules following a top-down calling relationship. The overall architecture consists of five layers: user interaction layer, intelligent agent core layer, parsing and processing layer, code generation layer, and data storage layer.

[0148] The user interaction layer is responsible for receiving user input in Excel files, JSON configurations, or manually entered module definitions, and displaying the processing results to the user.

[0149] The core layer of the intelligent agent is the central hub of the system, responsible for core functions such as task scheduling, AI interface calls, and context management.

[0150] The parsing processing layer is responsible for parsing the module definitions input by the user, building an inheritance tree, determining the relationships between tables, and handling field conflicts.

[0151] The code generation layer is responsible for generating database table creation statements, backend API code, and frontend page code based on the parsed configuration and pre-set template files.

[0152] The data storage layer is responsible for storing the parsed configuration information, the generated code files, and the vectorized system structure data.

[0153] This invention defines six main data streams: Data Flow 1: User Input to the Parsing Module. Users upload Excel files or fill in JSON configurations via the web interface. The frontend sends the files or data to the backend parsing module. The transmission method is HTTP protocol, and the data format is binary files or JSON text.

[0154] Data Flow 2: From Parsing Module to Inheritance Processing Module. The parsing module parses the Excel data into a module tree structure in memory and passes it to the inheritance processing module. The transmission method is memory object transfer.

[0155] Data Flow 3: Inheritance Processing Module to Relationship Judgment Module. After the inheritance processing module completes field merging and conflict resolution, it passes the complete module data to the relationship judgment module. The transmission method is memory object transfer.

[0156] Data Flow 4: From Relationship Judgment Module to AI Agent. The relationship judgment module structures the module data into prompt word templates and calls the AI ​​agent's API interface to perform relationship analysis. The transmission method is HTTP protocol, and the request body is a prompt word in JSON format.

[0157] Data Flow 5: From AI Agent to Template Engine. The relational analysis results returned by the AI ​​agent are passed to the template engine, which then selects the corresponding template file for rendering based on the results. The transmission method is memory object transfer.

[0158] Data Flow Six: From Template Engine to Output Module. After the template engine finishes rendering, the generated code file is output to the specified directory, and a download link is provided to the user. The transmission methods are file system write and HTTP file download.

[0159] The execution sequence of the entire system is as follows: First, the user uploads an Excel file through the web interface, and the front end sends the file to the back end. After receiving the file, the back end initiates the parsing process, sequentially calling the parsing module, the inheritance processing module, and the relationship judgment module.

[0160] Then, the relationship determination module encapsulates the processing results into prompt words and calls the AI ​​agent interface. After the AI ​​agent completes the processing, it returns the relationship analysis results.

[0161] Next, the template engine selects a template based on the analysis results and performs rendering, generating app.py, index.html, and page files for each business module.

[0162] Finally, the system saves the generated file to the specified directory and notifies the frontend of the completion via a JSON response. Upon receiving the response, the frontend displays the generated result on the interface and provides a download button.

[0163] Of course, the above description is not limited to the examples above. Technical features not described in this invention can be implemented by or using existing technology, and will not be repeated here. The above embodiments and drawings are only used to illustrate the technical solutions of this invention and are not intended to limit this invention. This invention has been described in detail with reference to preferred embodiments. Those skilled in the art should understand that any changes, modifications, additions or substitutions made by those skilled in the art within the scope of this invention do not depart from the spirit of this invention and should also fall within the scope of protection of the claims of this invention.

Claims

1. An automated software code generation method based on inheritance relationships and flow rules, characterized in that: Includes the following steps: S1. Module Definition: Receives the module hierarchy structure input by business personnel. The module includes the starting module, the inheriting module, and the last module. The inheriting module automatically inherits all fields and business logic of its parent module. The last module contains all fields of the parent module and the fields specific to this module. S2, Flow direction definition: Defines the data flow direction between modules, forming a unidirectional pipeline from the starting module to the last module. The data flow direction includes forward flow and reverse flow. S3. Relationship Judgment: The AI ​​agent automatically identifies one-to-one, one-to-many, or many-to-many relationships between modules and generates corresponding inter-table lookup logic. S4. Forward Code Generation: Based on module definitions, data flow, and identified relationships, automatically generate data table structures, API interfaces, front-end pages, and workflow engine code; S5. Reverse Rule Definition: Reverse blocking conditions received from business personnel; S6. Reverse Code Generation: Based on the reverse blocking conditions, automatically generate reverse business logic code for handling unaudited, withdrawn, rolled back, and offset documents; S7. Template Copy: Saves the generated complete module chain and its associated code as a template. By replacing the module name and field name in the template, it can quickly copy and generate new business system code.

2. The automated software code generation method based on inheritance relationship and flow rules according to claim 1, characterized in that: In S1, when a field defined in a submodule conflicts with a field inherited from a parent module, it is handled according to preset conflict resolution rules, which include submodule priority, parent module priority, merging and checking, or forced renaming.

3. The automated software code generation method based on inheritance relationship and flow rules according to claim 1, characterized in that: In S5, reverse blocking conditions include at least one of the following: the last-level module has been confirmed, there is an executed downstream document, the document has been finalized, or the business cycle has been closed.

4. The automated software code generation method based on inheritance relationship and flow rules according to claim 3, characterized in that: In S6, when the reverse blocking condition is met, the final authorization release operation or the reverse hedging operation is executed.

5. The automated software code generation method based on inheritance relationship and flow rules according to claim 4, characterized in that: The reverse hedging operation includes: automatically generating a hedging business document based on the type of the original business document. The key value of the hedging business document is the negative value of the corresponding value in the original document, so as to achieve business hedging.

6. The automated software code generation method based on inheritance relationship and flow rules according to claim 5, characterized in that: Hedging documents include return orders, refund orders, or work hour cancellation orders.

7. The automated software code generation method based on inheritance relationship and flow rules according to claim 1, characterized in that: In S7, templates use a tag-based variable substitution syntax that supports multi-granularity variable substitution at the system, module, field, and relation levels, and also supports loop and conditional logic.

8. An automated software code generation system based on inheritance relationships and flow rules, characterized in that, include: The input module is used to receive input from business personnel regarding the module hierarchy structure, field definitions, and reverse blocking conditions. The intelligent agent module is used to call the AI ​​model to automatically identify the relationships between modules; The relationship judgment module is used to process and output the module relationship results identified by the AI ​​agent; The forward generation module is used to generate forward business logic code based on module definitions, data flow, and relationships. The reverse engineering module is used to generate reverse business logic code based on the reverse engineering blocking conditions. The template management module is used to save and manage form templates and supports template copying operations; The execution module is used to integrate and output the final, complete business system code.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, it implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by the processor, it implements the method as described in any one of claims 1 to 7.

Images