A computer language programming method based on business logic

Abstract

The application relates to the technical field of computer programming languages, and particularly discloses a computer language programming method based on business logic. In view of the defects of the prior art, such as deep coupling between business logic and technical implementation, high cross-domain adaptation cost, redundant hardware operation code, and high complexity of asynchronous programming, the application proposes the following core solutions: a componentized development framework, a cross-platform self-adaptive mechanism, an event layered model, a hardware intention analysis engine, and a code-as-document system. The application significantly reduces the complexity of multi-domain system development, improves the business logic expression efficiency and maintainability, is suitable for cloud microservices, embedded devices and hybrid language scenarios, and provides a technical basis for intelligent programming.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer programming languages, and particularly relates to a computer language programming method based on business logic. BACKGROUND

[0002] Java is an object-oriented general-purpose programming language that implements business logic through structured programming of classes and methods. Developers need to manage technical details such as threads and exception handling themselves. Advantages: It has a perfect ecosystem and cross-platform capabilities, making it suitable for building complex large systems. Disadvantages: Business logic is deeply coupled with technical implementation, requiring the writing of a large amount of template code (such as database connection management, HTTP request processing), resulting in reduced visibility of business core logic.

[0003] C language implements embedded functions by directly operating registers or hardware interfaces, requiring developers to manually manage memory, interrupts, and hardware timing. Advantages: High execution efficiency, capable of implementing fine hardware control. Disadvantages: Code is filled with hardware-related low-level operations (such as configuring GPIO pins, handling communication protocol timing), business logic is obscured by hardware operation details, development efficiency is low and portability is poor.

[0004] Process orchestration language (take BPEL as an example): BPEL (Business Process Execution Language) is an XML-based service process orchestration language that implements business logic by defining the order and conditions of service calls. Advantages: Supports visual orchestration, suitable for describing collaboration between services. Disadvantages: Syntax is redundant (XML structure is complex), lacks support for hardware operations and non-service class businesses (such as embedded logic), has high learning costs and limited application fields.

[0005] DSL domain language (take SQL database query language as an example): SQL operates databases through declarative syntax, focusing on data query and transaction processing. Advantages: Simplifies data operation logic, improves database interaction efficiency. Disadvantages: Limited to data layer operations, cannot describe complete business processes, requires external language implementation for business integration.

[0006] Service orchestration framework (take AWS Step Functions as an example): Defines service call processes through JSON, supporting visual orchestration of cloud services such as Lambda functions and API gateways. Reduces the complexity of distributed system development, provides state tracking and error retry mechanisms. Deeply bound to specific cloud platforms, unable to adapt to embedded offline scenarios, and lacks the ability to operate hardware resources.

[0007] In the prior art, the fusion of cross-domain customized logic and standardized components needs to rely on multi-language redundant development, the amount of hardware operation code is redundant, and asynchronous process management has the risk of callback nesting and state confusion. The existing GOTO jump leads to out-of-control logic due to the lack of isolation mechanism, and cross-platform data interaction crashes due to frequent type conflicts. Taking Java development as an example, developers need to explicitly write database connection management, thread synchronization control and other infrastructure codes in business logic; in embedded C language development, business logic is overwhelmed by technical details such as hardware register operation. The business core logic is hidden by technical implementation code, which significantly reduces the code readability and maintainability, and forces developers to modify a large number of technical detail related codes when adapting to different platforms. SUMMARY

[0008] In view of the technical problems in the prior art, the present application provides a computer language programming method and device based on business logic.

[0009] The present application provides a computer language programming method based on business logic, comprising:

[0010] Receiving business requirement input, extracting process rules of business logic through semantic analysis;

[0011] Based on the process rules, using SDL code to declaratively describe business logic, wherein the SDL code takes components as basic execution units, and completes process control through predefined keywords, and the process control includes process jump and termination;

[0012] Compiling the SDL code to generate intermediate representation data, the intermediate representation data including platform-independent business logic description layer and platform-specific adaptation extension layer;

[0013] According to the target running environment, branch processing is performed on the intermediate representation data:

[0014] If the target running environment is a resource-limited hardware platform, the hardware extension attribute in the platform-specific adaptation extension layer is parsed to generate a corresponding hardware executable program, and the function of the hardware executable program is verified through a simulation verification module;

[0015] If the target running environment is an extensible computing platform, the cloud extension attribute in the platform-specific adaptation extension layer is parsed, the intermediate representation data is converted into source code of the target platform through a real entity engine, and a micro-service program is generated;

[0016] Executing the generated hardware executable program or micro-service program outputs the execution result of the business logic.

[0017] Further, the business logic based computer language programming method provided by the present application, the flow control completed by the predefined keywords comprises:

[0018] In the compiling stage, the predefined keywords and the target identifiers associated with the predefined keywords are parsed, and a mapping relationship between the target identifiers and the execution positions is established;

[0019] In the running stage, the flow jump and termination are completed in response to the predefined keywords, and the flow jump or flow termination operation is executed based on the mapping relationship;

[0020] When the flow termination operation is executed, the execution resource is released and the execution result is stored.

[0021] Further, the business logic based computer language programming method provided by the present application, the compiling of the SDL code comprises a parameter parsing step, and the parameter parsing step comprises:

[0022] The parameter types are distinguished by recognizing the feature identifiers in the parameter declarations;

[0023] Based on whether the parameters are named, a parsing mode is selected, the unnamed parameters are parsed in a predefined order, the default values are filled in the missing positions, the named parameters are matched and assigned according to the parameter names, and the later values are overwritten on the former values when the repeated assignment occurs;

[0024] The parsed parameter values are stored in a runtime environment for component calling.

[0025] Further, the business logic based computer language programming method provided by the present application, after the parsed parameter values are stored in the runtime environment, further comprises:

[0026] The parameter values are verified based on preset type rules, and the parameters passing the verification are loaded into an execution environment;

[0027] A special interface corresponding to the target runtime environment is called to execute a preset operation, and the execution state is recorded in real time;

[0028] When an event trigger condition is met, event logic is executed, and an operation result is output to a shared storage space.

[0029] Further, the business logic based computer language programming method provided by the present application, the verification of the parameter values based on the preset type rules and the loading of the parameters passing the verification into the execution environment comprise:

[0030] The parameter types are distinguished based on the feature identifiers;

[0031] The parameter values are associated with variables through the named identifiers, and are parsed according to the naming matching or order rules;

[0032] Verify parameter type in compiling stage, terminate compiling when parameter type is not matched.

[0033] Further, the business logic-based computer language programming method comprises the following steps:

[0034] Based on the parameter type distinguishing result, the variable class parameter that passes the verification is stored in the runtime environment, and the trigger type of the event parameter is identified as synchronous or asynchronous.

[0035] In the compiling stage, the event logic is converted into an intermediate representation node, and in the running stage, the event node logic is executed when the trigger condition is met, so as to obtain an event processing result; and based on the mapping relationship between the target identifier and the execution position, the event processing result is associated with the flow jump and termination.

[0036] Further, the business logic-based computer language programming method comprises the following steps:

[0037] According to the type of the target running environment, general storage space and environment-specific storage space are allocated for the component.

[0038] The general storage space is used for cross-component data sharing, and the specific storage space is used for storing environment-specific data.

[0039] A bidirectional data synchronization channel is established between the general storage space and the environment-specific storage space.

[0040] Further, the business logic-based computer language programming method comprises the following steps:

[0041] Type management is performed when data is written into the general storage space.

[0042] Variable types are dynamically inferred in the general storage space, and the type mapping is updated.

[0043] When the component reads data, the type matching is checked, and if the types are not matched, the execution is terminated.

[0044] Further, the business logic-based computer language programming method comprises the following steps:

[0045] The actual type of the written data is detected, if the data is structured data with nested levels, the element type is parsed layer by layer, and a parsing result of the parsed element type is obtained.

[0046] The mapping table of the variable name and the data type is updated according to the parsing result of the parsed element type.

[0047] When the same variable name is assigned multiple times and the runtime data type is inconsistent with the data type recorded in the mapping table, the data type record of the variable name in the mapping table is overwritten.

[0048] Further, the business logic-based computer language programming method of the present application further comprises the following steps after establishing the bidirectional data synchronization channel:

[0049] When the environmental characteristic data changes or the component calling demand is detected, the bidirectional data synchronization channel is activated by the running environment strategy engine.

[0050] Based on the running environment strategy, the differentiated access permission of the environment-specific storage space is allocated to the component.

[0051] The isolation access rule defined by the environment is enforced when the component is accessed.

[0052] When multiple components access concurrently conflict, the resource occupation priority is decided according to the corresponding resource management strategy of the target running environment.

[0053] The present application has the following advantages:

[0054] Directly facing the business logic image description: the existing programming languages are all for describing the function calls of machines, such as variable data storage, machine hardware access, network communication and other basic functions, and a large amount of code writing and debugging work is often required to realize a business logic. The SDL programming language describes the business logic, and the parameter setting of the business logic component is used to complete the coding of the business, which omits more than 90% of the code amount, greatly reduces the BUG occurrence rate, greatly improves the product development efficiency, reduces the project development risk and development cost.

[0055] Solve the high coupling problem of business logic and technical implementation: in view of the defect that the business code and technical details (such as database connection management, hardware register operation) are deeply interwoven in the existing programming language, the present application abstracts the technical infrastructure into reusable standardized components (such as SQL, GPIO) through the declarative component calling mechanism, so that the developer can directly describe the logic flow with business semantics, and the technical details are realized by encapsulation in the component, so as to realize the complete decoupling of business intention and underlying technology.

[0056] Intelligent abstraction of hardware interaction: To address the problem of high redundancy in hardware operation code in embedded development, the invention uses component-based calling. Developers only need to declare hardware behavior goals (such as "read temperature sensor data", IO port output data, and IO port data listening). The language runtime automatically selects the optimal communication protocol (I2C / SPI), completes timing configuration and signal analysis, and realizes safe interaction between hardware state and business logic through containerized result storage. This greatly simplifies the logical clarity of hardware program development and reduces hardware programming errors.

[0057] Mixed language development: The invention designs a unified syntax framework, which reduces the learning cost in different fields and supports embedding native languages in component calling. Customized business logic can be implemented according to the user's native programming language habits. For example, embedding customized encryption and decryption algorithms, data filtering algorithms, and other custom types of work in business processes completely solves the problems of component-based programming extensibility and flexibility.

[0058] Reconstructing event-driven programming paradigm: To address the pain points of callback nesting complexity and state management difficulty in existing asynchronous programming, the invention proposes a parameter and event layered declaration model based on components:

[0059] Parameter layer (param): Defines static configuration attributes of components (such as SQL statements and hardware port numbers), supports immediate execution

[0060] Event layer (hook): Declare condition-triggered business logic blocks (such as payment success callback and sensor exception handling), implement stack pollution-free flow control through GOTO label jumping and containerized variable space, and fundamentally avoid the "callback hell" problem.

[0061] Deeply integrated simulation verification and optimization: Not just simple code generation, the invention verifies and improves the performance of components and their integration through simulation and optimization algorithms, thereby achieving high-quality output.

[0062] Cross-domain applicability: Covers software, hardware, chip, and mechanical design fields, and is a comprehensive solution.

[0063] In summary, the SDL programming language described in the invention provides significant advantages in improving development efficiency, reducing errors, and enhancing product stability through its unique componentization, optimization, and automation features. This makes the technology particularly suitable for developing into a future human-computer interaction foundation language, especially in scenarios that incorporate artificial intelligence features to further automate and automate programming calls.

[0064] Meanwhile, the application has the unique ability of cross-domain application, the optimization of system components, and the comprehensive optimization of the whole R&D process. It is not only a development tool, but also a basic technology that can greatly improve the efficiency and quality of R&D. This makes it have potential important value in the existing engineering and technical background, especially in the industry that pursues efficient and high-quality R&D output. BRIEF DESCRIPTION OF DRAWINGS

[0065] Figure 1 A business logic-based computer language programming method flowchart is provided for the technical solutions of the application. DETAILED DESCRIPTION

[0066] An embodiment of the application will be further described below in combination with the drawings.

[0067] Please refer to Figure 1 The application provides a business logic-based computer language programming method, which comprises the following steps:

[0068] Receiving business requirement input, extracting the flow rules of business logic through semantic analysis;

[0069] Based on the flow rules, using SDL code to declaratively describe the business logic, wherein the SDL code takes components as the basic execution unit, and completes flow control through predefined keywords, and the flow control includes flow jump and termination;

[0070] Compiling the SDL code to generate intermediate representation data, wherein the intermediate representation data contains a platform-independent business logic description layer and a platform-specific adaptation extension layer;

[0071] According to the target running environment, branch processing is performed on the intermediate representation data:

[0072] If the target running environment is a resource-constrained hardware platform, the hardware extension attribute in the platform-specific adaptation extension layer is parsed to generate a corresponding hardware executable program, and the function of the hardware executable program is verified through a simulation verification module;

[0073] If the target running environment is an extensible computing platform, the cloud extension attribute in the platform-specific adaptation extension layer is parsed, the intermediate representation data is converted into the source code of the target platform through a real entity engine, and a micro-service program is generated;

[0074] Executing the generated hardware executable program or micro-service program to output the execution result of the business logic.

[0075] The business requirement input stage receives a natural language description or a structured data template provided by a user, and a semantic analysis engine resolves entity relationships and operation sequences in a business scenario through a domain ontology library. The semantic analysis process identifies the relevance between business entities and operation constraint conditions, and outputs a standardized process rule set. The process rule set includes logical node definitions, execution order logic, and business constraint conditions, providing a structured input for subsequent code generation.

[0076] Based on the process rule set, an SDL programming interface converts business logic into a declarative code description. The SDL language uses pre-packaged business components as atomic operation units, and implements flow control structures through predefined keywords. The flow control structures include explicit jump instructions and termination instructions. The jump instructions are associated with logical node identifiers in the process rules, and the termination instructions trigger resource recycling operations. Component calls implement business function calls through declarative parameter configuration, shielding underlying technical implementation details.

[0077] An SDL compiler performs lexical analysis and syntax tree construction on the declarative code to generate intermediate representation data. The intermediate representation data uses a directed acyclic graph structure to record component dependency relationships and control flow paths, including component parameter metadata, event hook binding relationships, and environment adaptation interface declarations. The platform-independent layer abstracts the core of business logic, and the platform-specific extension layer stores environment-related configuration attributes. Separation of the two layers ensures cross-platform compatibility.

[0078] The intermediate representation data is input into an environment adapter for target runtime environment determination. When the environment adapter identifies a resource-constrained hardware platform based on a device feature library, it calls a hardware code generator to process the intermediate representation data. The hardware code generator parses hardware extension attributes in the platform-specific extension layer, which include register address mapping tables, interrupt priority configurations, and peripheral clock parameters, and generates executable machine code based on the target chip instruction set.

[0079] The hardware executable program is input into a simulation verification module for functional verification. The simulation verification module constructs a virtual execution environment based on a hardware abstraction layer, injects test case data streams, and monitors register state changes and signal response timing. The verification process performs boundary value analysis and abnormal path coverage, and outputs a verification report identifying register read / write exceptions and timing violation issues.

[0080] When the environment adapter determines that the target is an extensible computing platform, a conversion engine parses cloud extension attributes in the platform-specific extension layer. The cloud extension attributes include service governance strategies, load balancing configurations, and fuse threshold parameters, and the conversion engine generates microservice interface definitions based on the target framework specifications. The source code engineering compiles and packages through a continuous integration tool chain to generate a containerized microservice program set.

[0081] The execution phase selects a runtime container according to the environment type. The hardware execution environment loads the verified executable program to the physical device through the burning tool; and the cloud execution environment schedules the microservice instance through the container orchestration platform. The business logic execution result is written to the standardized output channel, and the output channel encapsulates data in the protocol format defined according to the process rule, and supports two transmission formats of structured text and binary stream.

[0082] The flow jump operation is executed after the target address validity check. The address checker accesses the jump address index table generated in the compiling stage to confirm that the target identifier has a valid address mapping and does not exceed the executable boundary. The invalid jump triggers the exception handling process, and the exception handler rolls back the uncommitted data change and resets the component state machine.

[0083] The resource recycler performs the ordered release operation when the process terminates. The recycler traverses the runtime resource allocation record, and unloads the resource instance in the reverse order according to the component dependency graph. The unloading process calls the resource release callback function registered by the component, writes the execution result to the non-volatile storage device, and stores the transient data in the volatile cache area.

[0084] The type management system performs dynamic inference when data is written to the general storage space. The type inference engine detects the storage structure characteristics of the written data, identifies the continuous memory block as an array type, and the pointer associated structure as an object type. The nested data structure recursively analyzes the internal element type, generates a composite type signature, and updates the versioned mapping table.

[0085] The cross-platform data synchronization is activated through the environment strategy engine. The environment monitor polls the hardware register state or the cloud configuration change event, and starts the bidirectional channel after matching the preset synchronization trigger rule. The synchronization engine translates the general storage space data change into platform-specific operation instructions, and the hardware environment is converted into a register bit operation, and the cloud environment is translated into a configuration center application program interface call.

[0086] The component access conflict is eliminated by using a distributed transaction lock mechanism. The resource conflict detector monitors the concurrent access events of multiple components, the hardware environment implements a spin lock based on an atomic instruction, and the cloud environment coordinates multiple nodes by using a lease protocol. The arbitration algorithm is selected according to the environment strategy, the hardware environment implements real-time preemption scheduling, and the cloud environment performs resource quota allocation based on weights.

[0087] Specifically, the business logic-based computer language programming method disclosed by the application includes the following steps:

[0088] In the compiling stage, the pre-defined keywords and the target identifiers associated with the pre-defined keywords are parsed, and a mapping relationship between the target identifiers and the execution positions is established.

[0089] The process jump and termination are completed in response to predefined keywords in the running phase, and the process jump or process termination operation is performed based on the mapping relationship;

[0090] When the process termination operation is performed, the execution resource is released and the execution result is stored.

[0091] In the compiling phase, the compiler performs static scanning on the SDL source code, identifies the predefined keywords and the associated target identifiers. The predefined keywords include the reserved character sequences of the process jump instruction and the termination instruction, and the target identifiers mark the process node positions by using the naming labels. The compiler builds a symbol table to store the mapping relationship between the target identifiers and the memory address offsets, generates intermediate representation data, and encodes the mapping relationship into a jump address index table when the intermediate representation data includes a platform-independent business logic description layer and a platform-specific adaptation extension layer.

[0092] The jump address index table is loaded into the runtime context in the running phase. When the interpreter executes to the process jump keyword, the memory address offset of the target node is obtained by retrieving the index table through the target identifier, and the program counter is modified to realize the execution position switching. The process termination keyword triggers the interrupt processing program, and the program reads the current execution stack state and calls the resource recycler.

[0093] The resource recycler traverses the runtime resource allocation record, releases the occupied memory buffer and hardware handle. The execution result data is processed according to the preset storage strategy: the transient result is written into the volatile storage area, and the persistent result is submitted to the non-volatile storage device. The result storage process performs data format packaging, and the packaging rule is defined according to the metadata associated with the target identifier.

[0094] The target address validity is verified before the process jump operation is performed. The address verifier accesses the jump address index table, confirms that the target identifier exists corresponding address record and does not exceed the executable range. Invalid jump triggers the exception processing flow, and the exception processor records the error code and rolls back the current transaction state, and the rollback operation includes undoing the uncommitted data changes and resetting the internal state machine of the component.

[0095] The process termination operation includes an orderly shutdown sequence. The termination sequence controller performs reverse order unloading according to the component dependency graph, and calls the resource release callback function of the component in the unloading process. The final execution result is written into the result container, and the container structure adopts the key-value storage model, and the key name is generated by the target identifier and the result type identifier.

[0096] Specifically, the business logic-based computer language programming method disclosed by the application includes a parameter parsing step in the compiling of the SDL code, and the parameter parsing step includes:

[0097] The parameter category is distinguished by identifying the feature identifier in the parameter declaration, and the parameter type is distinguished by the feature identifier;

[0098] The parsing mode is selected based on whether the parameter is named or not, the unnamed parameter is parsed in a predefined order, the default value is filled in the missing position, the named parameter is assigned by matching the parameter name, and the later value is overwritten when there is repeated assignment;

[0099] The parsed parameter value is stored in the runtime environment for component calling.

[0100] The parameter parser scans the parameter declaration statement in the SDL code, extracts the feature identifier as the basis for distinguishing the parameter category. The feature identifier is composed of a preset character prefix and a type suffix, and the compiler matches the identifier pattern by regular expression and classifies it into variable parameter, event parameter or environment parameter. The parameter category information is recorded in the symbol table, and the symbol table is associated with the type constraint rule and the default value generation strategy.

[0101] The named parameter parsing mode activates the named matching mechanism. The parser establishes a mapping dictionary of parameter names and component interface definitions, traverses the named assignment statements in the source code to perform dictionary query, and writes the matched parameter value into the target storage slot. When detecting that the same named parameter is repeatedly assigned, the later assignment operation overwrites the previously stored value, and the overwrite operation updates the parameter version mark in the runtime environment.

[0102] The unnamed parameter enables the sequential parsing process. The parser reads the unnamed value according to the position order in the source code based on the parameter order list in the component interface declaration. When the position is empty, the default value generation strategy is called, and the strategy obtains the initial value corresponding to the type according to the parameter category recorded in the symbol table. Position overflow value triggers syntax exception, exception handler interrupts compilation and outputs error positioning information.

[0103] The parsed parameter value is loaded into the runtime environment. The runtime environment builds the binding relationship between the parameter storage area and the component execution context, and the storage area adopts a hierarchical namespace architecture: the global namespace stores the environment parameters, the local namespace mounts the variable parameters, and the event namespace registers the event parameters. The parameter value writing operation performs type compatibility check, and the check is based on the type constraint rules registered in the symbol table.

[0104] The parameter value is accessed by the runtime environment interface in the component calling stage. The execution engine retrieves the corresponding local namespace according to the current execution position, and the namespace parser locates the storage slot address according to the parameter name. The event parameter is activated when the trigger condition is met, the event processor extracts the parameter value from the event namespace and constructs the event message body, and the message body is passed to the event response interface of the target component.

[0105] Specifically, the business logic-based computer language programming method according to the present application, after storing the parsed parameter values to the runtime environment, further comprises:

[0106] verifying the parameter values based on preset type rules, and loading the parameter values that pass the verification to an execution environment;

[0107] calling a special interface corresponding to the target execution environment to perform a preset operation, and recording the execution state in real time;

[0108] executing event logic when an event trigger condition is met, and outputting an operation result to a shared storage space.

[0109] The type verifier verifies the parameter values according to a preset type rule library. The type rule library stores a mapping relationship between parameter names and data types, and the verification process performs mode matching between the value type and the declared type. The parameter values that pass the verification are loaded to a memory allocation area of the execution environment, and the memory allocation area is divided into independent access spaces according to the parameter scope. The loading process performs a deep copy operation to create a runtime instance copy of the parameter values.

[0110] The execution engine calls a special interface adapter registered by the target execution environment. The interface adapter activates the corresponding implementation according to the environment type: the hardware environment calls the peripheral driver layer, and the cloud environment accesses the service agent layer. The operation execution process uses a transaction monitor to record the state changes in real time. The state data includes an operation sequence identifier, a timestamp, and a resource consumption indicator. The state record is written to a ring buffer to realize efficient circular storage.

[0111] The event listener continuously detects the state of the trigger condition. The trigger condition is divided into static conditions and dynamic conditions: the static condition is defined by a Boolean expression preset at compile time, and the dynamic condition is calculated in real time depending on the runtime state data. When the condition is met, the event scheduler activates the event logic unit, and the event logic unit obtains the parameter instance through the execution environment interface and executes a predetermined operation sequence.

[0112] The operation result is output to a result container of the shared storage space. The result container uses a hierarchical key-value storage architecture, and the key name is generated by combining the component identifier and the operation type. The output process performs data serialization operation, and the serialization format is automatically selected according to the target environment: the hardware environment uses a binary compact format, and the cloud environment uses a structured text format.

[0113] The event logic execution process supports nested call chains. The event processor maintains a call stack depth counter, and triggers a fuse mechanism to terminate event propagation when the stack overflows. After the event execution result is written back to the shared storage space, the execution environment updates the component state machine migration marker, and the state migration marker is used for subsequent flow jump decision.

[0114] Specifically, the computer language programming method based on business logic of the present application includes:

[0115] Distinguishing parameter types based on feature identifiers;

[0116] Resolving by naming matching or order rules through naming identifiers to associate parameter values with variables;

[0117] Verifying parameter types in the compilation phase, and terminating the compilation when the parameter types do not match.

[0118] The lexical analysis phase identifies feature identifiers in parameter declaration statements. The feature identifiers are composed of type prefix symbols and variable names, and the compiler distinguishes parameter type categories through regular pattern matching. The type categories include basic data types, component object references, and event callback functions, and the classification results are recorded in the type attribute field of the symbol table. The symbol table synchronously stores type constraint rules, including type compatibility matrices and conversion function pointers.

[0119] Named identifiers establish the binding path of parameter values and target variables. Named parameters use hash tables to achieve naming matching, and the hash table key names are parameter identifiers declared in the source code, and the key values point to the storage slot addresses defined by the component interface. Unnamed parameters are positioned by a sequential index table to locate the storage slot, and the index table generates a position mapping relationship according to the declaration order of the component interface. The position resolver detects the deviation of the number of parameter values from the interface definition, fills in default value objects when the number is insufficient, and triggers a syntax exception when the number overflows.

[0120] The compilation phase performs static verification of parameter types. The type checker traverses the parameter declarations recorded in the symbol table, extracts the expected types corresponding to the storage slot addresses. The verifier compares the actual types of the parameter values with the expected types, and the actual types are obtained through the type metadata carried by the syntax tree nodes. When the types do not match, the error handler is called, which generates type conflict diagnosis information and terminates the compilation process.

[0121] The verified parameter values are loaded into the memory structure of the execution environment. The loader selects a memory allocation strategy according to the parameter type category: basic data types allocate contiguous memory blocks, object references construct pointer associations, and event callback functions are registered with the event dispatcher. The memory allocation process performs a copy-on-write operation to generate a runtime-independent copy of the parameter values.

[0122] The termination process when type verification fails includes transaction rollback. The rollback controller cleans up the allocated memory resources and releases the temporary storage space occupied by the symbol table. The error reporter outputs specific positioning information of the type conflict, including the source code line number, parameter identifier, and expected type and actual type comparison results.

[0123] Specifically, the business logic-based computer language programming method provided by the present application further comprises:

[0124] Based on the parameter type distinguishing result, the variable class parameter that passes the verification is stored in a runtime environment, and the trigger type of the event parameter is identified as synchronous or asynchronous;

[0125] In the compiling stage, the event logic is converted into an intermediate representation node, in the running stage, the event node logic is executed when the trigger condition is met, and an event processing result is obtained, and based on the mapping relationship between the target identifier and the execution position, the event processing result is associated with the flow jump and termination.

[0126] The parameter classifier separates the variable class parameter and the event class parameter according to the type distinguishing result. The variable class parameter is loaded into a data storage area of the runtime environment, and the data storage area is divided into a namespace according to a scope level. The event class parameter trigger type identification module analyzes the feature modifier in the event declaration, the feature modifier includes a synchronous execution identifier or an asynchronous listening identifier, and the identification result is written into an event registry.

[0127] The event logic converter in the compiling stage generates an intermediate representation node. The converter analyzes the event logic code block, extracts a conditional judgment expression and an execution statement sequence, and constructs a directed state node with a target identifier. The state node is stored in an event subgraph of intermediate representation data, and the event subgraph is associated with the interface address of the component and the trigger condition metadata. The event intermediate representation node generated in the compiling stage belongs to a platform-independent business logic description layer, and the jump logic is realized through a mapping table, which is decoupled from a platform-specific extension layer.

[0128] The event monitor in the running stage detects a trigger condition satisfaction state. The synchronous event is polled by the state detector according to the key variable value, and the asynchronous event receives an external interrupt signal through a message bus. The trigger signal is input into an event scheduler, and the event scheduler queries the event registry to obtain the intermediate representation node address corresponding to the target identifier.

[0129] The event execution engine activates the intermediate representation node logic. The execution process creates an independent sandbox environment, and the sandbox environment inherits the parameter namespace of the parent component and isolates the variable pollution. The logic execution outputs an event processing result, and the processing result is encapsulated as a structured message body, which includes a result status code and an output data load.

[0130] The flow controller retrieves the execution position mapping table according to the target identifier. The mapping table records the corresponding relationship between the target identifier and the program counter offset. The controller selects a flow jump path according to the status code of the event processing result: a successful state executes a jump operation to update the program counter, and a failure state triggers a termination flow to recycle resources. The jump operation verifies the validity of the target address, and an invalid address activates an exception processing channel.

[0131] Specifically, the business logic-based computer language programming method associates the event processing result with the flow jump and termination, and further comprises:

[0132] According to the type of the target running environment, the component is allocated with general storage space and environment-specific storage space;

[0133] The general storage space is used for cross-component data sharing, and the specific storage space is used for storing environment characteristic data;

[0134] A bidirectional data synchronization channel of the general storage space and the environment-specific storage space is established.

[0135] The environment type identifier allocates the storage space according to the characteristic mark of the target running environment. The resource-restricted hardware environment activates the hardware adaptation layer allocator, and the extensible computing platform calls the cloud platform adaptation layer allocator. The allocator creates a double-layer structure of the general storage space and the environment-specific storage space, the general storage space is deployed in the shared memory area, and the environment-specific storage space is mapped to the device characteristic management area.

[0136] The general storage space implements a cross-component data sharing mechanism. The sharing mechanism adopts a pre-constructed publish-subscribe model, and the components register data access interfaces through a unified message bus. The data storage format adopts a platform-independent byte stream encoding, and the encoding rules include a metadata header and a payload body. The metadata header records a component identifier and a data version number. The read operation performs byte stream decoding, and the write operation triggers a data change notification event.

[0137] The environment-specific storage space stores the running environment characteristic data. The hardware environment is mapped to the register abstraction layer, and the GPIO state word and the communication protocol cache are stored; the cloud environment is bound to the distributed configuration center, and the service instance metadata and the load balancing strategy are stored. The characteristic data is accessed through an environment proxy interface, and the proxy interface encapsulates the difference implementation of the underlying driver.

[0138] The bidirectional data synchronization channel is established depending on a transaction log tracker. The synchronization engine listens to the data change event of the general storage space, and generates an incremental operation log record. The log record is input to an environment converter, and the converter translates the operation instruction according to the environment type: the hardware environment is converted into a register bit operation instruction, and the cloud environment is translated into a configuration center API call. The reverse synchronization process is triggered by an environment monitor, and the environment characteristic change event generates an update transaction of the general storage space through the converter.

[0139] The synchronization channel performs conflict detection and resolution. The conflict detector compares data version numbers and timestamps. The hardware environment uses a semaphore locking mechanism, and the cloud environment implements an optimistic lock check. The conflict resolution strategy is selected by the environment strategy engine: the hardware environment prioritizes the preservation of real-time control data, and the cloud environment forcibly overwrites based on transaction sequence numbers. The resolved data changes are written to the target storage space and the version marker is updated.

[0140] Specifically, the business logic-based computer language programming method provided by the present application further comprises:

[0141] Type management is performed when data is written to the general storage space;

[0142] Variable types are dynamically inferred in the general storage space, and the type mapping is updated;

[0143] Type matching is checked when a component reads data, and execution is terminated if the types do not match.

[0144] The type manager is activated when data is written to the general storage space. The type manager analyzes the byte stream structure of the written data and extracts the initial type marker in the header metadata. When the metadata is missing, value feature analysis is performed. The feature analyzer detects data format patterns: numerical sequences are identified as array types, key-value pair sequences are classified as dictionary types, and undefined format markers are generic objects. The analysis results generate temporary type descriptors and are attached to the data header.

[0145] The type inference engine updates the type mapping table based on the features of the written data. The mapping table uses a hash dictionary structure to store the correspondence between variable names and type descriptors. The inference process identifies data nesting levels: single-layer structures directly record basic types, and nested structures recursively analyze internal element types and generate composite type signatures. Each data update operation triggers an increment of the mapping table version number, which is used to track type change history.

[0146] The type mapping table update rule follows the dynamic overwrite principle. When the same variable name is assigned new data, the type comparator checks the difference between the new data type descriptor and the mapping table record. If the descriptor structure changes, the type mapping table performs a version replacement operation: delete the old version type record, write the new version type signature and version timestamp. Historical version records are dumped to the type audit log for diagnostic analysis.

[0147] The component reading operation calls the type matching verifier. The verifier extracts the expected type declared by the component interface and performs structure compatibility comparison with the current version type descriptor in the general storage space. The basic type performs equality matching, and the composite type uses a depth-first traversal algorithm to verify field consistency. Compatibility judgment is based on the conversion relationship matrix defined by the type rule library, which includes an implicit conversion permission list.

[0148] A type mismatch triggers an execution termination protocol. The termination protocol includes an ordered rollback sequence: the rollback controller freezes the current execution thread, reverts uncommitted storage space mutations, and releases allocated runtime resources. The error handler generates a type conflict report, which includes variable name, expected type descriptor, actual type descriptor, and type mapping table version provenance information.

[0149] In particular, the programming method of the computer language based on business logic dynamically infers variable types in the general storage space, which includes:

[0150] Detecting the actual type of the written data, and if the data is structured data with a nested level, parsing the element type layer by layer to obtain a parsing result of the parsed element type;

[0151] Updating the mapping table of variable names and data types according to the parsing result of the parsed element type;

[0152] When the same variable name is assigned multiple times and the runtime data type is inconsistent with the data type recorded in the mapping table, the data type record of the variable name in the mapping table is overwritten.

[0153] The data type detector scans the data instance written into the general storage space. The detection process is based on the memory structure characteristics of the data instance: a continuous memory block is marked as an array type, a pointer associated structure is identified as an object type, and a function pointer is classified as a callback type. When a nested level is detected, a recursive parser is started, which decomposes the internal elements layer by layer and extracts the meta-type descriptor, and finally generates a tree signature structure of the composite type.

[0154] The type descriptor generator constructs the type mapping table entry based on the parsing result. The tree signature structure is converted into a type descriptor code, and the coding rules include level depth marking and leaf node type marking. The mapping table adopts a versioned storage model, and each update operation generates a new version entry and preserves a historical version snapshot. The entry update process performs an atomic write operation, and the atomic write operation guarantees the consistency of the multi-threaded environment through memory barrier instructions.

[0155] The runtime data type is compared with the mapping table record using a descriptor compatibility algorithm. The algorithm inputs the actual descriptor of the current data instance and the latest descriptor recorded in the mapping table, and outputs a difference marker set. When a basic type change or a nested structure dimension difference is detected, it is marked as a type incompatible event. The type incompatible event triggers the mapping table overwrite process, which appends the new descriptor to the version chain and activates the historical version archiving.

[0156] Type override operation synchronizes update type audit log. Log recorder captures descriptor snapshot before and after override, records change timestamp with operation thread identification. Audit log adopts circular buffer storage, buffer full triggers compression dump operation, dump file is associated to runtime diagnostic interface.

[0157] Dynamic type inference process is decoupled from component execution environment. Type management system runs independently in shared memory management area, receives data write event through inter-process communication interface. Decoupled architecture allows hardware environment and cloud environment to reuse the same type inference core, environment difference is adapted through descriptor encoding conversion layer, conversion layer selects compact binary encoding or readable text encoding according to target platform characteristics.

[0158] Specifically, the computer language programming method based on business logic according to the present application, after establishing a bidirectional data synchronization channel, further comprises:

[0159] When detecting changes in environmental characteristic data or component call requirements, the bidirectional data synchronization channel is activated by the running environment strategy engine;

[0160] Based on the running environment strategy, the component is allocated differential access rights to the environment-specific storage space;

[0161] The isolation access rules defined by the environment are enforced when the component accesses;

[0162] When multiple components access concurrently conflict, the resource management strategy corresponding to the target running environment is used to determine the resource occupation priority.

[0163] The environment monitor polls the hardware register state or cloud configuration change event to generate an environmental characteristic data change signal. The change signal is input to the running environment strategy engine, and the strategy engine matches the preset synchronization trigger rule: the hardware environment uses the interrupt priority threshold rule, and the cloud environment matches the service level agreement strategy. When the rule is hit, the bidirectional data synchronization channel is activated, and the activation instruction includes a synchronization direction identifier and a data range filtering condition.

[0164] The running environment strategy engine loads the permission allocation matrix. The permission matrix generates differential access rights according to the component security level and the environment type: the hardware environment allocates a register address whitelist, and the cloud environment grants a configuration center namespace access token. The permission allocation process implements the principle of least privilege, and the component only obtains the necessary data access range. The access token is bound to the component identity certificate, and the certificate is injected into the component metadata in the compilation phase.

[0165] The isolation access controller intercepts requests from components to access the environment's dedicated storage space. The controller verifies the matching of the access token with the target storage area and enforces the isolation rules defined by the environment: the hardware environment enables a memory protection unit hardware lock, and the cloud environment implements a role-based access control policy. Unauthorized access triggers a security exception, and the exception handler terminates the current operation and generates an audit log.

[0166] A resource conflict detector monitors concurrent access events from multiple components. Conflict detection employs a distributed transaction lock mechanism: the hardware environment uses spinlocks implemented with atomic instructions, while the cloud environment uses a lease protocol to coordinate multiple nodes. The resource management strategy engine selects an adjudication algorithm based on the target environment: the hardware environment uses real-time-priority preemptive scheduling, while the cloud environment performs weighted resource quota allocation. The adjudication result is broadcast to competing components via a message bus.

[0167] The priority executor allocates resource occupancy sequences based on the decision. Preemptive scheduling immediately suspends access threads for low-priority components, allowing high-priority threads to take over resource control. Weighted quota allocation generates resource access time slices, and the time slice manager switches component execution windows via timer interrupts. After resource release, the synchronization channel updates the data version number; the version number increment is used for consistency checks in subsequent synchronization cycles.

[0168] The technical solution of this invention is explained in detail below:

[0169] The SDL language of this invention uses components as the basic unit of execution, and completes the writing of product business logic by setting component parameters, component events, etc.

[0170] For the SDL language mentioned above, the syntax structure of the SDL language is as follows:

[0171] Component(param0 = value, param1 = value);

[0172] Component(

[0173] param0 = value,

[0174] hook1: GOTO point1, # When writing GOTO directly after hook, the curly braces can be omitted.

[0175] hook2: {

[0176] The DSL language compiler is not sensitive to punctuation marks, but for better writing, it is recommended to use complete punctuation.

[0177] Component(param0 = value, param1 = value);

[0178] Component(param0 = value, param1 = value);

[0179] Component(param0 = value, param1 = value);

[0180] GOTO point2;

[0181] } );

[0183] point2: Component(value0, value1);

[0184] Component(value0, param3 = value3); # Parameters are parsed in order. If a named parameter is encountered, the skipped parameters are assigned default values.

[0185] Syntax Structure Explanation: Components are the basic execution units, and keywords such as GOTO and END are used to implement flow transitions and termination. A component begins with its name, followed by code within parentheses that represents its parameters. Parameters are parsed primarily according to the component's parameter order, but parameter names can also be specified directly for assignment.

[0186] For the SDL language described above, the component structure is: COMPONENT_NAME(

[0187] param1 = value, / / Parameter declaration

[0188] param2 = value,

[0189] hook1: { ...}, / / Event hook

[0190] hook2: GOTO label )

[0192] Component parameters are divided into parameters (param) and events (hook). The event (hook) invocation logic is determined internally by the component. Hooks are also divided into synchronous and asynchronous events. The nature of the event is determined by the component's internal implementation. To ensure code elegance and simplicity, most component events are synchronous events. For example, the callback in an IF statement checks whether the corresponding condition is true; if it is, it executes (synchronous event). For example, in a payment component, the user payment success callback is an asynchronous callback that executes only after the user's payment operation is completed (which may require some time or waiting).

[0193] For the above SDL language, its variable storage scheme is:

[0194] The SDL language adopts a shared data variable namespace and a special data variable namespace specific to different project types. For example:

[0195] In microservice development, the namespace of the SDL has: global variables request, result, and session, which can be directly accessed in the namespace through container.variable_name. Among them, request is a service request parameter storage namespace, and its fixed variables include: request.url: request link, request.path: request service mapping, and request.$ip: request IP address; result is a component execution result storage container, and all components can read and write data in result; session is a session variable storage container, which is used to identify requests from different clients (identification principle: when a new client requests the server, the server will allocate a jtoken to it and the session namespace, and the client will carry the jtoken next time to operate the session namespace bound to the jtoken), which can be used to store user login status, user information, etc.

[0196] In the PIC and other chip-oriented programming environments, the namespace of the SDL has: global variables only result. Other single-chip resources P1, P2, P3, FIFO, I2C, UART, SPI, etc. are operated by components, and users only need to focus on business logic.

[0197] For the above SDL language, its accompanying system is: the compiler and the converter are written in JavaScript, the executor, the interpreter, and the conversion entity engine are written in Java, which is an optimal solution for the accompanying system of the SDL programming language. The compiler or executor can also be implemented in other languages or ways. The present application mainly protects the SDL programming language, so only a brief description of its accompanying system is given to prove that the SDL programming language has higher programming efficiency and stability compared with existing languages and emerging languages.

[0198] For the SDL programming language: compiler: written in JavaScript, executed in the user's browser. When the user writes the SDL language in the browser environment, the compiler of the SDL programming language can perform real-time compilation and checking on the SDL code written by the user. The user can immediately correct syntax errors according to the results of the compilation output. When the user finishes writing, the compiler outputs metadata that can be directly executed by the executor (including component execution parameters, binary data of the execution flow, referred to as metadata hereinafter). JavaScript is used to implement the compiler to respond more quickly to the user's code writing, give code writing suggestions and error prompts in a timely manner, and greatly reduce the server compilation pressure.

[0199] Converter: after successful compilation, the user can also use the converter to graphically display the compiled metadata. This can more intuitively and beautifully display the logic process of the current business.

[0200] Reverse parser: after successful compilation, the user can also use the reverse parser to output the SDL source code by reverse formatting the compiled metadata. This can more conveniently modify the code and assign parameters, etc. The function is mainly used for business logic generated by Tola and the like, and synchronously generates SDL source code. (Bidirectional conversion of source code and business logic generated by Tola).

[0201] Executor: after successful compilation, the user can directly submit the compiled metadata to the server. When the project type is microservice, the executor can directly execute the metadata of the microservice in component units to realize the business logic of the microservice. When the project is an embedded / PIC chip-oriented program, the submitted metadata uses the executor to simulate the chip program to verify the correctness of the written program.

[0202] Interpreter: when the SDL code contains native code, the server will call the interpreter to compile the native code after the user submits the metadata. For example, when the native code is Java, the interpreter will automatically generate a temporary Java class (inherited from the Component class) and compile it into machine code that can be directly executed by the Java virtual machine (JVM).

[0203] When the native code is JavaScript, the interpreter will automatically inject global variables and public tool libraries of the current project type, and store the injected code into the cache. When the executor executes, it will directly execute the JavaScript code with the injected global variables in the cache.

[0204] When the native code is Python, the interpreter automatically injects the global variables of the current project type and the public tool library, and stores the injected code into the cache, and when the executor executes, the Python code after injecting the global variables in the cache is directly executed;

[0205] When the native code is C / C++, the interpreter will automatically generate a temporary C / C++ source file (automatically inject global variables, library files) combined with the native code, and compile it into machine code (compiled into dll) that can be directly executed on the target chip;

[0206] The entity conversion engine: when the user selects to export the native code, the entity conversion engine will convert the code according to the user's selection of the project type and the chip type (PIC / embedded chip needs to be selected), and through the input of the compiled metadata, the entity conversion engine will call the corresponding framework of the component assembly method in turn, and can assemble the code of all components and generate a native project engineering.

[0207] The implementation process of the application is as follows: the SDL language described in the application needs to realize its "accessory system", please refer to the introduction of each accessory system in the above patent content.

[0208] Step 1, analyze the research and development process of the field to be implemented, and perform atomic-level splitting of the work of the research and development process (atomic level: in the field implementation process, it is not necessary to be further divided in the business level. For example, in the software research and development process, the atomic level is the function in the business process, such as executing SQL, sending short message, sending email, executing algorithm, and paying. In the field of chip program design, the atomic level is the function of the basic chip or external device, such as GPIO output, specified protocol communication (I2C, FIFO, SPI, UART), external ADC reading, and reading external sensor.

[0209] Step 2, determine the business logic of the research and development product, and describe the product business logic using the SDL programming language.

[0210] Step 3, use the SDL language compiler to compile the SDL code, and give a compilation prompt when a syntax error occurs, guiding the user to complete the code repair; when the compilation is successful, the metadata is output.

[0211] Step 4, use the metadata executor to execute the metadata output by the compiler to obtain the program execution result and achieve the program execution purpose.

[0212] Step 5, use the metadata entity conversion engine to convert the metadata output by the compiler to obtain the project source file for production or secondary development.

[0213] The metadata-to-entity engine is responsible for converting the business logic metadata generated by the no-code / low-code platform into specific source code for the target project type. Its processing flow first extracts the functional description and context information of each component by parsing the component parameters and call relationships in the business logic metadata, including component type (such as SQL execution component, I2C communication component), parameter configuration (such as SQL statement, communication pin), and execution order. The engine obtains the basic structure description, fixed file information, and directory structure of the corresponding project from the project type structure library according to the target project type (such as SpringBoot, Keil), initializes the project base files through the virtual file system, such as the Maven configuration file of the SpringBoot project, the Controller layer / Service layer directory structure, or the chip base library file and main program file main.c of the Keil project.

[0214] After initializing the project structure, the engine calls the component generation logic code in the project type component code generation library to generate source code for each business logic component. For example, for the SQL execution component in the SpringBoot project, the engine analyzes the incoming SQL type (query / modification) and storage container parameters, controls the virtual file system to write the SQL statement into the corresponding SQL configuration yaml file, generates the Dao layer interface, and injects the execution information into the Service layer code block; for the I2C communication component in the Keil project, the engine generates I2C tool functions (such as start signal, stop signal, byte sending function) and delay functions based on the communication pin, data content, and clock frequency parameters, and injects the function call logic into the specified position of the main.c file.

[0215] During the component code generation process, the engine realizes variable scope isolation, function dependency automatic injection, and code block structured storage through the variable management space, function management space, and code block management space of the virtual file system. For example, when generating the Service layer code, the engine generates the function names of Services and Controller based on the interface Mapping information through the function name generator of the virtual file system; through the annotation generator, it generates perfect function description annotations for variables and functions based on the component function described in the DSL language.

[0216] After the code generation is completed, the engine calls the project type optimizer to perform structural optimization on the generated source code. For SpringBoot projects, the optimizer checks the reuse of variables at the same level, merges redundant variable definitions, identifies repeated code blocks and encapsulates them as general functions to reduce logical complexity. For Keil projects, the optimizer analyzes memory usage, merges repeated variable definitions, and optimizes function call logic to improve memory utilization. Finally, the engine outputs a structured source code project through a virtual file system, including complete file directories, class / function definitions, and dependency relationships, realizing the complete conversion of no-code / low-code business logic metadata to target project type source code.

[0217] The present application solves the following technical problems:

[0218] Solve the problem of high coupling between business logic and technical implementation: In view of the defect that the business code and technical details (such as database connection management, hardware register operation) are deeply interwoven in the existing programming language, the present application abstracts the technical infrastructure into reusable standardized components (such as SQL, GPIO) through a declarative component calling mechanism, so that developers can directly describe the logic flow in business semantics, and the technical details are realized by encapsulation inside the component, thereby realizing the complete decoupling of business intent and underlying technology.

[0219] Eliminate the field gap of cross-platform development: In view of the current situation that cloud services and embedded systems need to use different technology stacks, the present application designs a unified syntax framework, and through an environment-adaptive component implementation mechanism, the same business logic code can run seamlessly on microservice clusters and embedded devices (directly operating I2C / GPIO hardware resources), achieving the core goal of "write once, deploy multiple times", and reducing the redundant development cost of multi-platform adaptation.

[0220] Reconstruct the event-driven programming paradigm: In view of the pain points of callback nesting complexity and state management difficulty in existing asynchronous programming, the present application proposes a parameter and event layered declaration model:

[0221] Parameter layer (param): define the static configuration attributes of the component (such as SQL statement, hardware port number), support immediate execution;

[0222] Event layer (hook): declare the condition-triggered business logic block (such as payment success callback, sensor exception handling), realize the flow control without stack pollution through GOTO label jump and containerized variable space, and fundamentally avoid the "callback hell" problem.

[0223] Intelligent abstraction of hardware interaction: In view of the high redundancy of hardware operation code in embedded development, the hardware intention analysis engine is built in the application, and the developer only needs to declare the hardware behavior target (such as "reading temperature sensor data"), and the language runtime automatically selects the optimal communication protocol (I2C / SPI), completes the timing configuration and signal analysis, and realizes the safe interaction of hardware state and business logic through containerization result storage.

[0224] Building a self-describing business document system: In view of the poor readability of existing code, the document and the implementation are easy to be out of touch, the application forms a visual business flowchart through structured syntax design (explicit parameter naming, labeled process jump), and combines the interactive semantic atlas generated by the compiler to realize the "code as document" expression of business logic, and improve the system maintenance and cooperation efficiency.

[0225] The application is dedicated to providing a high-expression and low-technology-intrusive field-specific language, which remolds the description paradigm and implementation method of business logic by deep combination of technical abstraction and field modeling under the premise of ensuring execution efficiency. The development efficiency of software and hardware products is greatly improved, the product stability is improved, and the threshold for the next AI automatic programming (human-computer direct interaction) is reduced.

[0226] The core innovation of the application lies in:

[0227] By embedding native code (Java / JS / Python / C++) in the component event layer, the interpreter dynamically generates temporary code (such as Java class, C++ DLL), and realizes the dynamic bridging of the business layer and the technical layer. The application adopts text syntax to better connect the AI large model, so that the large model is easier to write business code (the large model cannot directly generate graphical logic, but can generate text SDL business logic description), and at the same time, SDL uses components as the basic unit of execution, which can more clearly express business logic. (The existing technology graphical expression has problems such as reading difficulty in complex business logic, and the text expression is more concise). Through the component-based design of SDL programming language, the SDL code can be compiled into the underlying code (C / C++ / assembly / chip instructions) of the corresponding platform, and is not running on a fixed operating system or a virtual machine.

[0228] Based on the compilation period address mapping table and the sandbox isolation mechanism, the GOTO jump only acts on the business logic layer, avoids callback nesting and state confusion, and is a cross-field (embedded, microservice) and business logic description language. The use of GOTO has the following advantages.

[0229] SDL code is more conducive to visual interface conversion for flowchart-style business logic display. General business logic is usually expressed using flowcharts, such as using arrow direction to jump between loops and judgments. In text, this corresponds to GOTO to the corresponding node.

[0230] SDL language also has an event-driven model, such as hook events in components. GOTO has obvious advantages as a common logic processing part, such as jumping to exception handling and success handling. The reason why GOTO jump can lead to logic confusion is the misuse of GOTO. In existing code development, business logic is submerged in a large amount of underlying operation code, and using GOTO makes it more difficult to understand business logic. However, in SDL code that only expresses business logic (SDL components already have synchronous and asynchronous event hook processing), reasonable use of GOTO is more conducive to understanding the logic.

[0231] SDL code is more conducive to hardware adaptation. When adapting SDL code to a hardware platform, using GOTO is more consistent with the habits of assembly language, which can directly convert the code to assembly code for higher execution efficiency. Similarly, in a micro-service environment, using GOTO also has the advantage of execution efficiency.

[0232] Hardware intent end-to-end automation: the engine automatically generates a complete chain from protocol selection to business processing, reducing code volume;

[0233] Dynamic type management system: general storage space runtime infers types, combined with environment policies (hardware memory lock / cloud RBAC) to reduce cross-platform data conflicts.

Claims

1. A computer language programming method based on business logic, comprising: Receive business requirements input and extract process rules for business logic through semantic analysis; Based on the aforementioned process rules, SDL code is used to declaratively describe the business logic. The declarative description adopts a parameter and event layered declaration model: the parameter layer defines the static configuration properties of the component and supports immediate execution. The event layer declares the business logic blocks triggered by conditions, and achieves flow control without stack pollution through GOTO tag jumps and containerized variable space. The SDL code uses components as the basic execution unit and completes flow control through predefined keywords. Flow control includes flow jumps and termination. The SDL code is compiled to generate intermediate representation data, which includes a platform-independent business logic description layer and a platform-specific adaptation and extension layer. The intermediate representation data is branched according to the target operating environment: If the target operating environment is a resource-constrained hardware platform, then the hardware extension attributes in the platform-specific adaptation extension layer are parsed to generate the corresponding hardware executable program, and the hardware executable program is functionally verified through the simulation verification module. If the target runtime environment is a scalable computing platform, then the cloud extension attributes in the platform-specific adaptation extension layer are parsed, and the intermediate representation data is converted into the source code of the target platform through the entity conversion engine, and a microservice program is generated. The generated hardware executable program or microservice program is executed, and the execution result of the business logic is output.

2. The computer language programming method based on business logic as described in claim 1, characterized in that, The process control achieved through predefined keywords includes: During the compilation phase, predefined keywords and their associated target identifiers are parsed, and a mapping relationship between target identifiers and execution locations is established. During the runtime phase, the system responds to predefined keywords to complete process jumps and terminations, and performs process jumps or termination operations based on mapping relationships. When the execution process terminates, release the execution resources and store the execution results.

3. The computer language programming method based on business logic as described in claim 2, characterized in that, Compiling the SDL code includes a parameter parsing step, which includes: The parameter category is distinguished by identifying the characteristic identifiers in the parameter declaration, and the parameter type is distinguished by the characteristic identifiers. The parsing mode is selected based on whether the parameter is named or not. Unnamed parameters are parsed in a predefined order and missing positions are filled with default values. Named parameters are assigned values ​​according to the parameter name. When assigning values ​​repeatedly, the later value overwrites the previous value. The parsed parameter values ​​are stored in the runtime environment for components to use.

4. The computer language programming method based on business logic as described in claim 3, characterized in that, Also includes: The parameter values ​​are validated based on preset type rules, and the validated parameters are loaded into the execution environment. Call the dedicated interface corresponding to the target runtime environment to execute preset operations and record the execution status in real time; When the event triggering conditions are met, the event logic is executed, and the operation result is output to the shared storage space.

5. The computer language programming method based on business logic as described in claim 4, characterized in that, The parameter values ​​are verified based on preset type rules, and the parameters that pass the verification are loaded into the execution environment. include: Parameter types are distinguished based on feature identifiers; Parameter values ​​and variables are associated through named identifiers, and parsed according to naming matching or order rules; The compiler validates the parameter types during the compilation phase, and terminates compilation if the parameter types do not match.

6. The computer language programming method based on business logic as described in claim 5, characterized in that, Also includes: Based on the parameter type differentiation results, the verified variable parameters are stored in the runtime environment, and the triggering type of the event parameters is identified as synchronous or asynchronous. During the compilation phase, the event logic is converted into intermediate representation nodes. During the runtime phase, when the triggering conditions are met, the event node logic is executed to obtain the event processing result. Based on the mapping relationship between the target identifier and the execution position, the event processing result is associated with the process jump and termination.

7. The computer language programming method based on business logic as described in claim 6, characterized in that, Also includes: Based on the type of the target operating environment, allocate general storage space and environment-specific storage space to the components; The general-purpose storage space is used for cross-component data sharing, while the dedicated storage space is used to store environmental characteristic data. Establish a two-way data synchronization channel between general-purpose storage space and environment-specific storage space.

8. The computer language programming method based on business logic as described in claim 7, characterized in that, Also includes: Type management is performed when data is written to general storage space; Dynamically infer variable types and update type mappings in a general storage space; When a component reads data, it checks the type matching; if the types do not match, execution is terminated.

9. The computer language programming method based on business logic as described in claim 8, characterized in that, The types of dynamically inferred variables in the general storage space include: The actual type of the written data is detected. If it is structured data with nested levels, the element types are parsed layer by layer to obtain the parsing results of the element types. Update the mapping table between variable names and data types based on the parsing results of the element types; When the same variable name is assigned multiple times and the data type at runtime is inconsistent with the data type recorded in the mapping table, the data type record of the variable name in the mapping table is overwritten.

10. The computer language programming method based on business logic as described in claim 7, characterized in that, Also includes: When changes in environmental characteristic data or component call requirements are detected, the runtime environment policy engine activates the bidirectional data synchronization channel. Based on the aforementioned runtime environment policy, differentiated access permissions are allocated to components for environment-specific storage space; Enforce environment-defined isolation access rules when components are accessed; When multiple components conflict to access resources concurrently, the priority of resource usage is determined according to the resource management policy corresponding to the target runtime environment.

Images