Method for generating code based on multi-semantic domain field-specific language and related device

Abstract

Embodiments of the present application relate to the technical field of artificial intelligence, and disclose a method for generating code based on a multi-semantics domain specific language and related equipment, which comprises: receiving a formal specification file describing a financial system, the specification file being written based on a multi-semantics domain specific language, and the semantics domain at least including an entity domain, a transaction domain, a strategy domain and an attribute domain; running a specification processing engine to parse the specification file, extract system-level attributes, and generate a structured code generation instruction through a multi-layer prompt template; calling an artificial intelligence code generation model to generate source code; abstracting behaviors of the source code into a finite state model, and performing an exhaustive verification on the finite state model based on the system-level attributes, and after the verification is passed, outputting the source code as qualified source code. In the above manner, the embodiments of the present application can improve the reliability, security and compliance of code generation in the financial field.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of artificial intelligence technology, specifically to a method and related equipment for generating code based on a domain-specific language with multiple semantic domains. Background Technology

[0002] Artificial intelligence technologies, exemplified by Large Language Models (LLMs), are transforming traditional software development models. While these technologies possess immense efficiency potential, they also suffer from inherent fundamental flaws—probabilism and unpredictability. AI-generated code may appear functionally correct on the surface, but deeper layers may conceal subtle logical errors, security vulnerabilities, or deviations from complex business rules and regulatory requirements. In some general software development, these issues can be corrected through traditional testing and manual review. However, in the financial sector, where financial systems are complex conglomerates involving data, transactions, compliance, system integration, human-computer interaction, and organizational permissions, traditional code generation, testing, and manual review methods are inefficient, inaccurate, and unreliable. This is particularly true in core business systems such as trading, clearing, and risk control, where even minor errors can trigger chain reactions, leading to significant systemic risks. Therefore, the reliability, security, and compliance deficiencies of AI code generation technology in the financial sector remain to be addressed. Summary of the Invention

[0003] In view of the above problems, embodiments of the present invention provide a method and related equipment for generating code based on a domain-specific language with multiple semantic domains, in order to solve the problems existing in the prior art.

[0004] According to one aspect of the present invention, a method for generating code based on a domain-specific language with multiple semantic domains is provided, the method comprising:

[0005] The system receives a formal specification document describing a financial system. This specification document is written in a domain-specific language with multiple semantic domains. These semantic domains include at least an entity domain, a transaction domain, a strategy domain, and an attribute domain. The entity domain includes entity declarations, which define the system's data model, state variables, and invariants that are always true on the data model. The transaction domain includes transaction declarations, which define the system's business operations and specify corresponding preconditions and postconditions for each business operation. The strategy domain includes strategy declarations, which define global compliance and risk control rules across individual transactions. The attribute domain includes attribute declarations, which are expressed using temporal logic and specify security and liveness attributes that the financial system satisfies across all execution paths.

[0006] Based on the specification file, a preset specification processing engine is run. The specification processing engine performs the following operations: parses the specification file, extracts system-level attributes based on the parsed specification file, and generates structured code generation instructions through multi-level prompt templates; calls an artificial intelligence code generation model, which generates source code corresponding to the specification content of the specification file based on the code generation instructions.

[0007] The behavior of the source code is abstracted into a finite state model, and the finite state model is exhaustively verified based on the system-level properties. After the verification is passed, the source code is output as qualified source code.

[0008] In an alternative approach, the semantic domain further includes an integration domain, an interaction domain, and an organization domain.

[0009] The integration domain defines the interface contracts, service calls, and communication protocols between the financial system and external systems.

[0010] The interaction domain defines user interface components, user-executable operations, and multi-step manual approval workflows;

[0011] The organizational domain defines user roles, user role access permissions, and separation of duties rules within the financial system.

[0012] In one alternative approach, parsing the specification file and extracting system-level attributes based on the parsed specification file includes:

[0013] Lexical and syntactic analysis are performed on the specification file to generate an abstract syntax tree, and multiple semantic analysis is performed on the abstract syntax tree to obtain an abstract syntax tree with semantic annotations.

[0014] The abstract syntax tree of the semantic annotations is converted into a syntax-independent intermediate representation, and the system-level attributes are extracted based on the intermediate representation.

[0015] In one alternative approach, the multiple-pass semantic analysis includes:

[0016] The abstract syntax tree is traversed to identify declaration statements and record the symbols and basic information of the declarations into a hierarchical symbol table; type and reference checks are performed based on the symbol table, and consistency and logical verification are performed.

[0017] In one alternative approach, the intermediate representation is a set of mutually referencing data objects, including entity model objects, transaction contract objects, compliance strategy objects, and time series attribute objects.

[0018] In one alternative approach, the multi-layered prompt template includes a system layer, a specification layer, a task layer, and a constraint layer. The step of generating structured code generation instructions through the multi-layered prompt template includes:

[0019] Based on the system layer, the roles and global instructions of the code generation instructions are set; based on the specification layer, specification information is injected into the code generation instructions; based on the task layer, the specific generation goals of the code generation instructions are defined; and based on the constraint layer, the output format of the code generation instructions is clarified, so as to obtain structured code generation instructions.

[0020] In one alternative approach, the abstraction of the behavior of the source code into a finite state model and the exhaustive verification of the finite state model based on the system-level properties include:

[0021] Analyze the variables related to entities in the entity domain in the source code, enumerate the combinations of the variable values ​​into a set of states, extract the function call paths and conditional branch logic that change the variables into state transition relationships, and map the atomic propositions in the attribute domain into label functions on the states, so as to abstract the behavior of the source code into the finite state model.

[0022] The model checking algorithm exhaustively explores all reachable states of the finite state model to verify whether all execution paths of the finite state model satisfy the system-level property.

[0023] According to another aspect of the present invention, an apparatus for generating code based on a multi-semantic domain domain-specific language is provided, the apparatus comprising:

[0024] The receiving module is used to receive a formal specification document describing a financial system. The specification document is written in a domain-specific language with multiple semantic domains. These semantic domains include at least an entity domain, a transaction domain, a strategy domain, and an attribute domain. The entity domain includes entity declarations, which define the system's data model, state variables, and invariants that are always true on the data model. The transaction domain includes transaction declarations, which define the system's business operations and specify corresponding preconditions and postconditions for each business operation. The strategy domain includes strategy declarations, which define global compliance and risk control rules across individual transactions. The attribute domain includes attribute declarations, which are expressed using temporal logic and specify security and liveness attributes that the financial system satisfies on all execution paths.

[0025] The specification processing module is used to run a preset specification processing engine based on the specification file. The specification processing engine performs the following operations: parsing the specification file, extracting system-level attributes based on the parsed specification file, and generating structured code generation instructions through multi-level prompt templates; calling an artificial intelligence code generation model, which generates source code corresponding to the specification content of the specification file based on the code generation instructions.

[0026] The verification module is used to abstract the behavior of the source code into a finite state model, and perform exhaustive verification on the finite state model based on the system-level properties. After the verification is passed, the source code is output as qualified source code.

[0027] According to another aspect of the present invention, a computer device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, wherein the executable instruction causes the processor to perform the method described above.

[0028] According to another aspect of the present invention, a computer-readable storage medium is provided, the storage medium storing at least one executable instruction, which, when executed on a computer device, causes the computer device to perform the method described above.

[0029] The specification document of this invention is written in a domain-specific language with multiple semantic domains. These semantic domains include at least entity, transaction, strategy, and attribute domains. A pre-defined specification processing engine runs based on the specification document. This engine parses the specification document, extracts system-level attributes, generates structured code generation instructions, and calls an AI code generation model to generate source code that conforms to business logic. The behavior of the source code is abstracted into a finite state model, and the finite state model is exhaustively verified based on system-level attributes. This invention's specification document provides a comprehensive and unambiguous formal description of the financial system. Based on this specification document, the specification processing engine automatically parses and transforms the document, extracts system-level attributes, and generates structured code generation instructions. These instructions provide the AI ​​model with a more accurate and complete context, reducing its guesswork and enabling the direct generation of code that better conforms to the specification. Furthermore, the structured data format supports automated processes, allowing the entire pipeline of specification, instruction, and code generation to be seamlessly integrated with automated scripts or systems without manual intervention in writing prompts. By using finite state models to verify source code, the source code can be formally verified automatically and exhaustively, thereby improving the reliability, security, and compliance of code generation in the financial field.

[0030] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0031] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0032] Figure 1 A flowchart illustrating the method for generating code based on a domain-specific language with multiple semantic domains provided in an embodiment of the present invention is shown.

[0033] Figure 2 It shows Figure 1 A detailed flowchart for extracting system-level attributes in the embodiment;

[0034] Figure 3 It shows Figure 1 A schematic diagram of the structure of the multi-layered prompt template in the embodiment;

[0035] Figure 4 A schematic diagram of the structure of the device for generating code based on a domain-specific language with multiple semantic domains provided in an embodiment of the present invention is shown;

[0036] Figure 5 A schematic diagram of the structure of a computer device provided in an embodiment of the present invention is shown. Detailed Implementation

[0037] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0038] Figure 1 A flowchart of a method for generating code based on a domain-specific language with multiple semantic domains, as provided in an embodiment of the present invention, is shown. Figure 1 As shown, the method includes the following steps:

[0039] Step 10: Receive a formal specification document describing the financial system. The specification document is written in a domain-specific language with multiple semantic domains. The semantic domains include at least an entity domain, a transaction domain, a strategy domain, and an attribute domain. The entity domain includes entity declarations, which define the system's data model, state variables, and invariants that are always true on the data model. The transaction domain includes transaction declarations, which define the system's business operations and specify the corresponding preconditions and postconditions for each business operation. The strategy domain includes strategy declarations, which define global compliance and risk control rules across individual transactions. The attribute domain includes attribute declarations, which are expressed using temporal logic and specify the security and liveness attributes that the financial system satisfies on all execution paths.

[0040] The domain-specific language (DSAR) in this embodiment is a programming language or markup language designed for the financial application domain. It is not a general programming language (such as Java or Python), but rather a language specifically designed for financial system specifications, possessing strict syntax and formal semantics. The DSAR employs a formal grammar defined by Backus-Naur Normal Form (BNF), which deconstructs the complex financial system into at least four orthogonal semantic domains: entity domain, transaction domain, strategy domain, and attribute domain. This allows for complete and unambiguous formal specification of the financial system. Specification documents, written using the DSAR, replace traditional vague requirement documents, constituting the authoritative and sole credible source for AI code generation. By transforming vague business requirements into precise, unambiguous, and machine-verifiable formal specifications, the DSAR eliminates information loss and misunderstandings during requirement transmission, ensuring the accuracy of requirements from the outset and improving reliability. Furthermore, the specification document is no longer a document for archiving after development, but rather an executable core driving code generation, verification, and repair. This provides unprecedented transparency, traceability, and auditability throughout the software development process, fully complying with the stringent regulatory requirements of the financial industry.

[0041] In an entity declaration, a data model refers to the abstract definition of an entity or core entity within a financial system, similar to a class in object-oriented programming. It defines the entity's name, attributes (fields), and types. For example, in a financial trading system, the data model is an order. The definition of the data model (entity) includes: the unique order identifier `orderId`, the buy / sell direction (BUY or SELL), the order price `price`, and the order quantity. State variables represent the current state of the financial system or entity during program execution. They typically correspond to attribute values ​​of data model instances. For example, the value of the `price` field in a specific buy order instance `order_001` is 100.5; this value is a state variable. Data invariants are global constraints about the data model or state that must be true at any given moment during the operation of the financial system. They are interpreted semantically using first-order logic. Given a system state `σ`, an invariant `φ` holds true in state `σ` if and only if the logical formula is true after replacing the variables in `φ` with their corresponding values ​​in `σ`. For example, the data invariants in a financial system are account.balance>=0, meaning the account balance is non-negative. These data invariants always hold true, and no transaction operation can break them.

[0042] In a transaction statement, the semantics of preconditions and postconditions are expressed based on the Hall triple {P}T{Q}, where P is the conjunction of all preconditions, T is the implementation code of the transaction operation, and Q is the conjunction of all postconditions. A precondition refers to the condition that the system must meet before a business operation (function / method) is allowed to execute. For example, for a transfer operation, the preconditions include sufficient balance in the sending account. A postcondition refers to the condition that the system must guarantee after a business operation is successfully executed. For example, in a transfer transaction, transferring a specified amount of funds from account A to account B, the new value of account A equals its old value minus the amount, and the new value of account B equals its old value plus the amount, while the total amount of funds remains unchanged: Old value of account A + Old value of account B = New value of account A + New value of account B.

[0043] In the policy statement, it is based on the event-condition-action ECA model and can be formalized as a triple (E,C,A). When the event matches the pattern E and the condition C is true, the action set A is executed. The domain-specific language extension ECA model supports compound event patterns, such as sequence(transfer[5]) which means matching 5 consecutive transfer events.

[0044] The property declaration contains high-level rules that the system must adhere to throughout its entire operational history, expressed using temporal logic. Temporal logic properties focus on the relationships and patterns of events and states over time. They allow complex, time-sequence-related regulatory rules to be directly written into the specification using temporal logic; for example, a withdrawal request must be completed within 5 minutes of approval. Property declarations can include temporal logic formulas, which support global operators G, final operators F, next-state operators X, until-the-end operators U, and recursive combinations of implied operators.

[0045] Furthermore, the semantic domain also includes the integration domain, interaction domain, and organizational domain. The integration domain defines the interface contracts, service calls, and communication protocols between the financial system and external systems (such as payment gateways, market data sources, etc.). The interaction domain defines user interface components, user-executable operations, and multi-step manual approval workflows to ensure the correctness of human-computer interaction processes. The organizational domain defines user roles within the financial system, user role operating permissions, and separation of duties rules. The entity domain, transaction domain, attribute domain, integration domain, interaction domain, and organizational domain work together to completely and accurately capture the full essence of complex financial systems, enabling a comprehensive and unambiguous formal description of the financial system.

[0046] Step 20: Run a preset specification processing engine based on the specification file. The specification processing engine performs the following operations: parse the specification file, extract system-level attributes based on the parsed specification file, and generate structured code generation instructions through multi-level prompt templates; call an artificial intelligence code generation model, which generates source code corresponding to the specification content of the specification file based on the code generation instructions.

[0047] The specification processing engine is configured to automatically parse the entire specification file, distinguish semantic domains, and understand the definition of each semantic domain. Based on the parsed specification file, it automatically identifies and extracts system-level attributes described in formal languages ​​such as Linear Temporal Logic (LTL) (e.g., any transaction must be authorized before execution). It then generates structured code generation instructions, converting the specific requirements in the specification file (such as entity definitions and transaction logic) into structured code generation instructions. System-level attributes are expressed using temporal logic such as LTL or Computational Tree Logic (CTL). The structured code generation instructions differ from traditional AI code generation hints. Traditional AI code generation hints are usually free-form hints written by developers in natural language, which may have problems such as ambiguity, incompleteness, and context dependencies. In this embodiment, the structured code generation instructions contain organized information, such as task definitions (code elements to be generated), specifications (expected output type), core logical constraints (preconditions, postconditions, etc.), data models (data structure information to be used in the code), and invariants. The structured code generation instructions in this embodiment provide the AI ​​code generation model with a more accurate and complete context, reducing its guesswork and enabling the direct generation of code that better conforms to the specification. Furthermore, the structured data format supports automated processes, allowing the entire pipeline of specification, instructions, and code generation to be seamlessly integrated with automated scripts or systems without the need for manual intervention in writing prompts. Therefore, in this embodiment, the structured code generation instructions are an intermediate representation with a fixed pattern or schema that acts as a bridge between the high-level formal specification and the AI ​​code generation model. By decomposing, classifying, and standardizing the specification content, it optimally transmits the precise intent of human experts to the AI ​​code generation model, thereby improving the quality and reliability of the generated code at the source. This is a crucial preliminary step in achieving a closed loop of specification-driven development and automated verification.

[0048] Furthermore, the parsing of the specification file, based on the parsed specification file, extracts system-level attributes, including:

[0049] Lexical and syntactic analysis are performed on the specification file to generate an abstract syntax tree, and multiple semantic analysis is performed on the abstract syntax tree to obtain an abstract syntax tree with semantic annotations.

[0050] The abstract syntax tree of the semantic annotations is converted into a syntax-independent intermediate representation, and the system-level attributes are extracted based on the intermediate representation.

[0051] like Figure 2As shown, the first stage consists of lexical analysis and syntax analysis. Based on the ANTLR v4 parser generator framework, the adaptive LL(*) parsing algorithm is used to segment the character stream of the FinSpec-DSL specification file into tokens. For example, keywords such as entity declarations, transaction declarations, identifiers such as Order, operators, and parentheses are identified. According to the formal grammar rules predefined in the FinSpec-DSL specification file using Backus-Naur normal form, the token sequence is checked and organized to determine whether it conforms to the language's structural rules. If it does, an abstract syntax tree is constructed. The abstract syntax tree describes the structure of the program, where each node represents a grammatical structure (such as entity declarations and transaction declarations).

[0052] Phase Two: Multi-pass Semantic Analysis. The abstract syntax tree (AST) is processed three times: The first pass involves symbol table construction and scope analysis. The AST is traversed, identifying all entity, transaction, and other declarations, and recording the declared symbols and their basic information in a hierarchical symbol table. This essentially creates a global dictionary, recording the names and basic outlines of all defined elements. The second pass involves type checking and inference. Based on the symbol table, it checks the type compatibility of various expressions, assignments, function calls, etc., performs type inference for expressions with undefined types, and checks the validity of variable and function references (i.e., whether they have been declared in the symbol table). The third pass involves consistency and logical verification, including checking the logical consistency of transaction preconditions and postconditions, the validity of atomic propositions in sequential logic, and the satisfiability of entity invariants.

[0053] The third stage: Transforming the intermediate representation. The abstract syntax tree with semantic annotations is converted into a syntax-independent intermediate representation. This intermediate representation is a unified internal data structure, more suitable for subsequent automated processing. The intermediate representation is a set of mutually referencing data objects, including: entity models, transaction contracts, compliance policies, and temporal attributes. The entity model contains a list of fields and an invariant expression tree; the transaction contract contains a list of parameters and a logical expression tree of preconditions and postconditions; the compliance policy contains structured event patterns, conditions, and actions; and the temporal attributes contain a logical tree structure of temporal logic formulas. The intermediate representation stores the structured, syntax-independent specification information of the specification document after parsing and processing, serving as a unified semantic data source. After obtaining the intermediate representation, temporal attributes are used as system-level attributes. Specifically, the intermediate representation, as a unified semantic data source, also serves the subsequent generation and verification of structured code generation instructions (Prompts), ensuring that code generation constraints and verification standards remain consistent.

[0054] Furthermore, construct a generator for multi-level prompt templates, such as Figure 3As shown, the multi-layered prompt template includes a system layer, a specification layer, a task layer, and a constraint layer, and generates structured code generation instructions through a generator.

[0055] The first layer, the system layer, defines the AI ​​role and global instructions. Example: "You are an expert in Java and the development of highly reliable financial systems. Your primary instruction is to strictly adhere to the provided formal specifications. You must not make any assumptions about anything not explicitly stated in the specifications."

[0056] The second specification layer injects specification information related to the current task. Instead of reading the original specification file, the generator programmatically accesses and traverses the intermediate data objects to extract the structured specification information related to the current code generation task, and then injects it into the Prompt after formatting it (such as JSON format).

[0057] Layer 3, Task Layer: Defines specific code generation goals. Instructions must be explicit, unambiguous, and executable, connecting the macro-level specifications with a specific code implementation goal. Example: "Please implement the Java method for the match_orders transaction according to the above specification document. This method should be a public method of the TransactionService class, and the parameter and return value types must strictly correspond to the transaction declaration."

[0058] The fourth constraint layer specifies additional constraints beyond the code and the expected output format, including the target programming language and version (e.g., Java 17), error handling mechanisms (e.g., throwing a TransactionException exception when preconditions are violated), concurrency requirements (e.g., methods must be thread-safe), coding standards (e.g., naming conventions and comment standards), and output format (e.g., providing only the method body code, without class definitions and import statements).

[0059] Thus, a multi-layered prompt template generator produces structured code generation instructions.

[0060] Furthermore, it also includes a fifth example layer: retrieving one or two validated high-quality code examples similar to the current task from a pre-built code example library, guiding the AI ​​code generation model to master the desired code structure and design patterns, such as specific error handling patterns and entity loading patterns, through few-shot learning, and comparing and learning with the corresponding prompts of the retrieved code examples, so that the code generation instructions can be described more accurately.

[0061] Call an AI code generation model, which could be a Claude Code model, Code Buddy, or any other model. Send structured code generation instructions to the AI ​​code generation model, and the AI ​​code generation model will generate source code, which will be saved as a file.

[0062] Step 30: Abstract the behavior of the source code into a finite state model, and perform exhaustive verification on the finite state model based on the system-level properties. After the verification is passed, output the source code as qualified source code.

[0063] Among them, the finite state model is an intermediate product or model abstracted from the source code, representing all possible behaviors of the source code and assisting in the completion of automated and formal verification.

[0064] Furthermore, the step of abstracting the behavior of the source code into a finite state model and performing exhaustive verification of the finite state model based on the system-level properties includes:

[0065] Analyze the variables related to entities in the entity domain in the source code, enumerate the combinations of the variable values ​​into a set of states, extract the function call paths and conditional branch logic that change the variables into state transition relationships, and map the atomic propositions in the attribute domain into label functions on the states, so as to abstract the behavior of the source code into the finite state model.

[0066] The model checking algorithm exhaustively explores all reachable states of the finite state model to verify whether all execution paths of the finite state model satisfy the system-level property.

[0067] The finite state model is derived from the control flow and data flow of the source code and represents all possible behavioral information of the source code. This behavioral information includes a set of states, state transition relationships (describing how a change occurs from one state to another), and label functions associated with a set of atomic propositions for each state. The finite state model is a standardized, formalized behavioral model that translates complex software systems (specifications and code) into a form that verification tools can understand and perform mathematical analysis on. It is the core product for achieving the automated transformation from specification to machine-executable mathematical verification. In this embodiment, the purpose of generating the finite state model is to provide input for the automated formal verification of the source code. AI-generated source code is a concrete program, while formal verification tools need to process abstract mathematical models. Therefore, the finite state model is a crucial bridge connecting source code and formal verification theory.

[0068] Model checking algorithms (such as SPIN and NuSMV) are used to exhaustively explore all reachable states of the finite state model, checking whether system-level properties hold true across all execution paths. Specifically, the extraction of the finite state model is achieved as follows: First, analyze the entity-related variables in the source code (such as Order.status, Account.balance, etc.) to identify all assignment statements and conditional branches that affect these variables; second, enumerate the combinations of these variable values ​​into a set of states, where each state corresponds to a specific set of variable values; third, extract the function call paths and conditional branch logic that change these variables into state transition relationships, with each transition corresponding to a triggering event (such as the execution of a transaction operation) and the resulting state change; finally, map atomic propositions in the attribute domain (such as order.status==FILLED) to label functions on the states, thereby constructing a complete finite state model. For example, the status field of the Order entity has a value space of {NEW, PARTIALLY_FILLED, FILLED, CANCELLED}, and each value constitutes a dimension of the state set; the modification of filled_quantity in the match_orders trading pair constitutes a state transition; the logical conditions in the status_consistency invariant are mapped to atomic propositions on each state.

[0069] This embodiment exhaustively explores a finite-state model to prove whether the behavior of the generated source code strictly satisfies system-level properties across all possible execution paths. If satisfied, the source code is of acceptable quality; otherwise, it is unacceptable.

[0070] The specification document of this invention is written in a domain-specific language with multiple semantic domains. These semantic domains include at least entity, transaction, strategy, and attribute domains. A pre-defined specification processing engine runs based on the specification document. This engine parses the specification document, extracts system-level attributes, generates structured code generation instructions, and calls an AI code generation model to generate source code that conforms to business logic. The behavior of the source code is abstracted into a finite state model, and the finite state model is exhaustively verified based on system-level attributes. This invention's specification document provides a comprehensive and unambiguous formal description of the financial system. Based on this specification document, the specification processing engine automatically parses and transforms the document, extracts system-level attributes, and generates structured code generation instructions. These instructions provide the AI ​​model with a more accurate and complete context, reducing its guesswork and enabling the direct generation of code that better conforms to the specification. Furthermore, the structured data format supports automated processes, allowing the entire pipeline of specification, instruction, and code generation to be seamlessly integrated with automated scripts or systems without manual intervention in writing prompts. By using finite state models to verify source code, the source code can be formally verified automatically and exhaustively, thereby improving the reliability, security, and compliance of code generation in the financial field.

[0071] For example, consider the scenario of developing a simplified "dark pool trading system" that must meet a key compliance requirement: price improvement, meaning that buy orders must be executed at or below the median price, and sell orders must be executed at or above the median price to protect traders' interests. This requirement must be met in any concurrent trading scenario.

[0072] 1. Use a domain-specific language with multiple semantic domains for specification: Write the dark_pool.finspec specification file using a domain-specific language with multiple semantic domains. The file contains:

[0073] Entity Field: Defines the Order entity, containing fields such as "orderId", "side" (BUY / SELL), "price", and "quantity". Defines the "MidPoint" entity.

[0074] Transaction Domain: Defines the "matchOrder(buyOrder, sellOrder)" operation. Its postcondition "ensures" specifies the changes in the account balances and positions of both the buyer and seller after the transaction is completed.

[0075] Policy domain: When the order matching event occurs, the system must automatically check whether the "price improvement" rule has been met.

[0076] Attribute domain: Using sequential logic, the "price improvement" rule is formalized into a system-level attribute:

[0077] The system-level attribute “G(forall_b:BuyOrder,s:SellOrder|is_matched(b,s)->(b.execution_price<=MidPoint.price&&s.execution_price>=MidPoint.price))” means: “For all cases of global G, if a buy order b and a sell order s are matched, then the transaction price of b will necessarily be less than or equal to the midpoint price, and the transaction price of s will be greater than or equal to the midpoint price.”

[0078] 2. Specification parsing and processing: The dark_pool.finspec specification file is input into the system, and the specification processing engine starts:

[0079] By analyzing the entire specification document, I understood the definitions of the Order entity and the matchOrder operation;

[0080] System-level attributes were successfully extracted from the attribute domain and marked as core compliance targets to be verified.

[0081] Based on the definitions of the entity domain, transaction domain, and strategy domain, a structured Prompt is generated, such as: "Please implement a matchOrder function in Python that takes a buy order and a sell order object as parameters...".

[0082] 3. AI Code Generation Model Generation and Code Abstraction: The system calls an LLM, sending the above Prompt to it. The LLM generates a file named matching_engine.py (source code), which contains a preliminary implementation of a matchOrder function.

[0083] 4. Source Code Verification: After the source code is generated, the system analyzes the control flow and data flow of matching_engine.py and abstracts its behavior into a finite state model. This finite state model contains all possible combinations of values ​​for relevant variables (such as order price and median price). An exhaustive verification is performed on the finite state model based on system-level properties to verify whether all execution paths of the finite state model satisfy the system-level properties. If they do, the output source code is considered valid; otherwise, it is considered invalid.

[0084] As can be seen from the above embodiments, the present invention, through domain-specific language with multiple semantic domains and automated verification methods, transforms a vague, high-level financial compliance requirement into an engineering practice that can be understood by AI and rigorously verified by machines, demonstrating its significant advantages in developing highly reliable financial systems.

[0085] Figure 4 A schematic diagram of the structure of an apparatus for generating code based on a domain-specific language with multiple semantic domains, according to an embodiment of the present invention, is shown. Figure 4 As shown, the device includes:

[0086] The receiving module 401 is used to receive a formal specification document describing a financial system. The specification document is written in a domain-specific language with multiple semantic domains. The semantic domains include at least an entity domain, a transaction domain, a strategy domain, and an attribute domain. The entity domain includes entity declarations, which define the system's data model, state variables, and invariants that are always true on the data model. The transaction domain includes transaction declarations, which define the system's business operations and specify the corresponding preconditions and postconditions for each business operation. The strategy domain includes strategy declarations, which define global compliance and risk control rules across individual transactions. The attribute domain includes attribute declarations, which are expressed using temporal logic and specify the security and liveness attributes that the financial system satisfies on all execution paths.

[0087] The specification processing module 402 is used to run a preset specification processing engine based on the specification file. The specification processing engine performs the following operations: parses the specification file, extracts system-level attributes based on the parsed specification file, and generates structured code generation instructions through multi-level prompt templates; calls an artificial intelligence code generation model, which generates source code corresponding to the specification content of the specification file based on the code generation instructions.

[0088] The verification module 403 is used to abstract the behavior of the source code into a finite state model, and perform exhaustive verification on the finite state model based on the system-level attributes. After the verification is passed, the source code is output as qualified source code.

[0089] The embodiments of the apparatus for generating code based on a domain-specific language with multiple semantic domains are basically the same as the embodiments of the method for generating code based on a domain-specific language with multiple semantic domains described above, and can be referred to the above embodiments.

[0090] Figure 5 The diagram shows a structural schematic of an embodiment of the computer device of the present invention. The specific embodiments of the present invention do not limit the specific implementation of the computer device.

[0091] like Figure 5 As shown, the computer device may include: a processor 402, a communications interface 404, a memory 406, and a communications bus 408.

[0092] The processor 402, communication interface 404, and memory 406 communicate with each other via communication bus 408. Communication interface 404 is used to communicate with other computer devices, such as clients or other server network elements. The processor 402 executes program 410, specifically performing the relevant steps described above in the computer device embodiment.

[0093] Specifically, program 410 may include program code, which includes computer-executable instructions.

[0094] Processor 402 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The computer device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0095] Memory 406 is used to store program 410. Memory 406 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0096] Specifically, program 410 can be called by processor 402 to cause the computer device to perform the following operations:

[0097] The system receives a formal specification document describing a financial system. This specification document is written in a domain-specific language with multiple semantic domains. These semantic domains include at least an entity domain, a transaction domain, a strategy domain, and an attribute domain. The entity domain includes entity declarations, which define the system's data model, state variables, and invariants that are always true on the data model. The transaction domain includes transaction declarations, which define the system's business operations and specify corresponding preconditions and postconditions for each business operation. The strategy domain includes strategy declarations, which define global compliance and risk control rules across individual transactions. The attribute domain includes attribute declarations, which are expressed using temporal logic and specify security and liveness attributes that the financial system satisfies across all execution paths.

[0098] Based on the specification file, a preset specification processing engine is run. The specification processing engine performs the following operations: parses the specification file, extracts system-level attributes based on the parsed specification file, and generates structured code generation instructions through multi-level prompt templates; calls an artificial intelligence code generation model, which generates source code corresponding to the specification content of the specification file based on the code generation instructions.

[0099] The behavior of the source code is abstracted into a finite state model, and the finite state model is exhaustively verified based on the system-level properties. After the verification is passed, the source code is output as qualified source code.

[0100] In an alternative approach, the semantic domain further includes an integration domain, an interaction domain, and an organization domain.

[0101] The integration domain defines the interface contracts, service calls, and communication protocols between the financial system and external systems.

[0102] The interaction domain defines user interface components, user-executable operations, and multi-step manual approval workflows;

[0103] The organizational domain defines user roles, user role access permissions, and separation of duties rules within the financial system.

[0104] In one alternative approach, parsing the specification file and extracting system-level attributes based on the parsed specification file includes:

[0105] Lexical and syntactic analysis are performed on the specification file to generate an abstract syntax tree, and multiple semantic analysis is performed on the abstract syntax tree to obtain an abstract syntax tree with semantic annotations.

[0106] The abstract syntax tree of the semantic annotations is converted into a syntax-independent intermediate representation, and the system-level attributes are extracted based on the intermediate representation.

[0107] In one alternative approach, the multiple-pass semantic analysis includes:

[0108] The abstract syntax tree is traversed to identify declaration statements and record the symbols and basic information of the declarations into a hierarchical symbol table; type and reference checks are performed based on the symbol table, and consistency and logical verification are performed.

[0109] In one alternative approach, the intermediate representation is a set of mutually referencing data objects, including entity model objects, transaction contract objects, compliance strategy objects, and time series attribute objects.

[0110] In one alternative approach, the multi-layered prompt template includes a system layer, a specification layer, a task layer, and a constraint layer. The step of generating structured code generation instructions through the multi-layered prompt template includes:

[0111] Based on the system layer, the roles and global instructions of the code generation instructions are set; based on the specification layer, specification information is injected into the code generation instructions; based on the task layer, the specific generation goals of the code generation instructions are defined; and based on the constraint layer, the output format of the code generation instructions is clarified, so as to obtain structured code generation instructions.

[0112] In one alternative approach, the abstraction of the behavior of the source code into a finite state model and the exhaustive verification of the finite state model based on the system-level properties include:

[0113] Analyze the variables related to entities in the entity domain in the source code, enumerate the combinations of the variable values ​​into a set of states, extract the function call paths and conditional branch logic that change the variables into state transition relationships, and map the atomic propositions in the attribute domain into label functions on the states, so as to abstract the behavior of the source code into the finite state model.

[0114] The model checking algorithm exhaustively explores all reachable states of the finite state model to verify whether all execution paths of the finite state model satisfy the system-level property.

[0115] This invention provides a computer-readable storage medium storing at least one executable instruction that, when executed on a computer device, causes the computer device to perform any of the above-described method embodiments.

[0116] This invention provides a computer program that can be invoked by a processor to cause a computer device to execute any of the above-described method embodiments.

[0117] This invention provides a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions that, when executed on a computer, cause the computer to perform any of the above-described method embodiments.

[0118] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of the present invention are not directed to any particular programming language. It should be understood that the content of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0119] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0120] Similarly, it should be understood that, in order to streamline the invention and aid in understanding one or more of the various aspects of the invention, features of the embodiments of the invention are sometimes grouped together in a single embodiment, figure, or description thereof in the above description of exemplary embodiments of the invention. However, this disclosure should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim.

[0121] Those skilled in the art will understand that modules in the computer device of the embodiments can be adaptively modified and placed in one or more computer devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or computer device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0122] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A method for generating code based on a domain-specific language with multiple semantic domains, characterized in that, The method includes: The system receives a formal specification document describing a financial system. This specification document is written in a domain-specific language with multiple semantic domains. The semantic domains include at least an entity domain, a transaction domain, a strategy domain, and an attribute domain. The entity domain includes entity declarations, which define the system's data model, state variables, and invariants that are always true on the data model. The transaction domain includes transaction declarations, which define the system's business operations and specify corresponding preconditions and postconditions for each business operation. The strategy domain includes strategy declarations, which define global compliance and risk control rules across individual transactions. The attribute domain includes attribute declarations, which are expressed using temporal logic and specify security and liveness attributes that the financial system satisfies across all execution paths. The semantic domains also include an integration domain, an interaction domain, and an organizational domain. Based on the specification file, a preset specification processing engine is run. The specification processing engine performs the following operations: parses the specification file, extracts system-level attributes based on the parsed specification file, and generates structured code generation instructions through multi-level prompt templates; calls an artificial intelligence code generation model, which generates source code corresponding to the specification content of the specification file based on the code generation instructions; the system-level attributes are expressed using linear temporal logic (LTL) or computation tree logic (CTL) temporal logic. The behavior of the source code is abstracted into a finite state model, and the finite state model is exhaustively verified based on the system-level properties. After the verification is passed, the source code is output as qualified source code. The process involves parsing the specification file and extracting system-level attributes based on the parsed specification file, including: Lexical and syntactic analysis are performed on the specification file to generate an abstract syntax tree, and multiple semantic analysis is performed on the abstract syntax tree to obtain an abstract syntax tree with semantic annotations. The abstract syntax tree of the semantic annotations is converted into a syntax-independent intermediate representation, and the system-level attributes are extracted based on the intermediate representation; The intermediate representation is a set of mutually referencing data objects, including entity model objects, transaction contract objects, compliance strategy objects, and time series attribute objects. The multi-layered prompt template includes a system layer, a specification layer, a task layer, and a constraint layer. The generation of structured code generation instructions through the multi-layered prompt template includes: Based on the system layer, the roles and global instructions of the code generation instructions are set; based on the specification layer, specification information is injected into the code generation instructions; based on the task layer, the specific generation goals of the code generation instructions are defined; and based on the constraint layer, the output format of the code generation instructions is clarified, so as to obtain structured code generation instructions.

2. The method according to claim 1, characterized in that, The integration domain defines the interface contracts, service calls, and communication protocols between the financial system and external systems. The interaction domain defines user interface components, user-executable operations, and multi-step manual approval workflows; The organizational domain defines user roles, user role access permissions, and separation of duties rules within the financial system.

3. The method according to claim 1, characterized in that, The multi-pass semantic analysis includes: The abstract syntax tree is traversed to identify declaration statements and record the symbols and basic information of the declarations into a hierarchical symbol table; type and reference checks are performed based on the symbol table, and consistency and logical verification are performed.

4. The method according to claim 1, characterized in that, The step of abstracting the behavior of the source code into a finite state model and performing exhaustive verification of the finite state model based on the system-level properties includes: Analyze the variables related to entities in the entity domain in the source code, enumerate the combinations of the variable values ​​into a set of states, extract the function call paths and conditional branch logic that change the variables into state transition relationships, and map the atomic propositions in the attribute domain into label functions on the states, so as to abstract the behavior of the source code into the finite state model. The model checking algorithm exhaustively explores all reachable states of the finite state model to verify whether all execution paths of the finite state model satisfy the system-level property.

5. An apparatus for generating code based on a domain-specific language with multiple semantic domains, characterized in that, The device includes: A receiving module is used to receive a formal specification document describing a financial system. The specification document is written in a domain-specific language with multiple semantic domains. These semantic domains include at least an entity domain, a transaction domain, a strategy domain, and an attribute domain. The entity domain includes entity declarations, which define the system's data model, state variables, and invariants that are always true on the data model. The transaction domain includes transaction declarations, which define the system's business operations and specify corresponding preconditions and postconditions for each business operation. The strategy domain includes strategy declarations, which define global compliance and risk control rules across individual transactions. The attribute domain includes attribute declarations, which are expressed using temporal logic and specify security and liveness attributes that the financial system satisfies on all execution paths. The semantic domains also include an integration domain, an interaction domain, and an organizational domain. The specification processing module is used to run a preset specification processing engine based on the specification file. The specification processing engine performs the following operations: parsing the specification file, extracting system-level attributes based on the parsed specification file, and generating structured code generation instructions through multi-level prompt templates; calling an artificial intelligence code generation model, which generates source code corresponding to the specification content of the specification file based on the code generation instructions; the system-level attributes are expressed using linear sequential logic (LTL) or computation tree logic (CTL) sequential logic. The multi-layered prompt template includes a system layer, a specification layer, a task layer, and a constraint layer. The specification processing module is specifically used to perform lexical and syntactic analysis on the specification document to generate an abstract syntax tree (AST), perform multiple semantic analyses on the AST to obtain a semantically annotated AST, convert the semantically annotated AST into a syntax-independent intermediate representation, and extract the system-level attributes based on the intermediate representation. The intermediate representation is a set of mutually referencing data objects, including entity model objects, transaction contract objects, compliance strategy objects, and time-series attribute objects. Based on the system layer, the roles and global instructions of the code generation instructions are set; based on the specification layer, specification information is injected into the code generation instructions; based on the task layer, the specific generation goals of the code generation instructions are defined; and based on the constraint layer, the output format of the code generation instructions is clarified, so as to obtain structured code generation instructions. The verification module is used to abstract the behavior of the source code into a finite state model, and perform exhaustive verification on the finite state model based on the system-level properties. After the verification is passed, the source code is output as qualified source code.

6. A computer device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the method as described in any one of claims 1-4.

7. A computer-readable storage medium, characterized in that, The storage medium stores at least one executable instruction, which, when executed on a computer device, causes the computer device to perform the method as described in any one of claims 1-4.

Images