Computer language programming method based on business logic

Abstract

The invention relates to the technical field of computer programming languages, and particularly discloses a computer language programming method based on business logic. Aiming at the defects of deep coupling of business logic and technology implementation, high cross-domain adaptation cost, hardware operation code redundancy, high asynchronous programming complexity and the like in the prior art, the invention provides the following core schemes: a modularized development framework, a cross-platform adaptive mechanism, an event hierarchical model, a hardware intention analysis engine and a code, namely a document system. According to the method, the development complexity of a multi-field system is remarkably reduced, the business logic expression efficiency and maintainability are improved, the method is suitable for cloud micro-services, embedded equipment and mixed language scenes, and a technical basis is provided for intelligent programming.

Description

Technical Field

[0001] This invention relates to the field of computer programming language technology, and more specifically to a computer language programming method based on business logic. Background Technology

[0002] Java is an object-oriented general-purpose programming language that implements business logic through structured programming using classes and methods. Developers need to manage technical details such as threads and exception handling themselves. Advantages: It has a complete ecosystem and cross-platform capabilities, making it suitable for building complex, large-scale 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 and HTTP request processing), leading to reduced visibility of core business logic.

[0003] C language implements embedded functions by directly manipulating registers or hardware interfaces, requiring developers to manually manage memory, interrupts, and hardware timing. Advantages: High execution efficiency and the ability to achieve fine-grained hardware control. Disadvantages: The code is filled with low-level hardware operations (such as configuring GPIO pins and handling communication protocol timing), business logic is obscured by hardware operation details, resulting in low development efficiency and poor portability.

[0004] Business Process Execution Language (BPEL) is an XML-based service process orchestration language that defines the order and conditions of service calls to implement business logic. Advantages: Supports visual orchestration and is suitable for describing the collaborative relationships between services. Disadvantages: Redundant syntax (complex XML structure), lacks support for hardware operations and non-service-oriented business logic (such as embedded logic), high learning curve, and limited applicability.

[0005] DSL domain languages ​​(taking SQL database query language as an example): SQL operates on the database through declarative syntax, focusing on data querying and transaction processing. Advantages: Simplifies data operation logic and improves database interaction efficiency. Disadvantages: Limited to data layer operations, unable to describe complete business processes, requiring reliance on external languages ​​for business integration.

[0006] Service orchestration frameworks (using AWS Step Functions as an example): Service call flows are defined via JSON, supporting visual orchestration of cloud services such as Lambda functions and API gateways. This reduces the complexity of distributed system development and provides state tracking and error retry mechanisms. However, it is deeply tied to specific cloud platforms, cannot adapt to embedded or offline scenarios, and lacks the ability to manipulate hardware resources.

[0007] In existing technologies, the integration of cross-domain customized logic and standardized components relies on redundant development in multiple languages, resulting in high redundancy in hardware operation code and risks of callback nesting and state chaos in asynchronous process management. Furthermore, existing GOTO jumps suffer from logical instability due to a lack of isolation mechanisms, and cross-platform data interaction frequently crashes due to type conflicts. Taking Java development as an example, developers need to explicitly write infrastructure code such as database connection management and thread synchronization control within the business logic; in embedded C language development, business logic is overwhelmed by technical details such as hardware register operations. This leads to core business logic being obscured by technical implementation code, significantly reducing code readability and maintainability, and forcing developers to modify a large amount of technically detailed code during cross-platform adaptation. Summary of the Invention

[0008] To address the technical pain points of the existing technologies, the present invention provides a computer language programming method and apparatus based on business logic.

[0009] This invention provides 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 SDL code uses components as the basic execution unit and completes process control through predefined keywords. Process control includes process jump 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.

[0010] Furthermore, in the business logic-based computer language programming method of the present invention, 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.

[0011] Furthermore, the business logic-based computer language programming method of the present invention includes a parameter parsing step in compiling the SDL code, the parameter parsing step including: 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.

[0012] Furthermore, the computer language programming method based on business logic described in this invention, after storing the parsed parameter values ​​to the runtime environment, further 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.

[0013] Furthermore, in the business logic-based computer language programming method of the present invention, the step of verifying parameter values ​​based on preset type rules and loading the verified parameters into the execution environment includes: 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.

[0014] Furthermore, the computer language programming method based on business logic described in this invention 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.

[0015] Furthermore, the computer language programming method based on business logic described in this invention, which associates event processing results with process jumps and terminations, 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.

[0016] Furthermore, the computer language programming method based on business logic described in this invention 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.

[0017] Furthermore, the computer language programming method based on business logic described in this invention, which dynamically infers variable types in the general-purpose storage space, includes: 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.

[0018] Furthermore, the computer language programming method based on business logic described in this invention, after establishing a bidirectional data synchronization channel, further 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.

[0019] Beneficial effects of this invention: Directly describing business logic: Existing programming languages ​​describe machine function calls, such as variable data storage, machine hardware access, and network communication. Implementing a single business logic function often requires extensive coding and debugging. In contrast, the SDL programming language describes business logic directly, using parameter settings for business logic components to complete the coding of the business logic. This eliminates over 90% of the code, significantly reducing bug rates, greatly improving product development efficiency, and lowering project development risks and costs.

[0020] Solving the problem of high coupling between business logic and technical implementation: In response to the shortcomings of existing programming languages ​​where business code and technical details (such as database connection management and hardware register operations) are deeply intertwined, this invention uses a declarative component invocation mechanism to abstract the technical infrastructure into reusable standardized components (such as SQL and GPIO). This allows developers to directly describe the logical flow in terms of business semantics, while the technical details are encapsulated and implemented within the components, thereby achieving complete decoupling between business intent and underlying technology.

[0021] Intelligent abstraction for hardware interaction: Addressing the issue of high redundancy in hardware operation code in embedded development, this invention uses component-based calling. Developers only need to declare hardware behavior targets (such as "reading temperature sensor data", outputting data via I / O ports, and listening for data via I / O ports). The runtime language automatically selects the optimal communication protocol (I2C / SPI), completes timing configuration and signal parsing, and achieves secure 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.

[0022] Hybrid Language Development: This invention features a unified syntax framework that reduces the learning cost of development across different domains. It also supports embedding native languages ​​in component calls, allowing for customized business logic implementation based on users' native programming language habits. For example, it allows embedding customized encryption / decryption algorithms, data filtering algorithms, and other custom tasks into business processes, completely solving the problems of scalability and flexibility in component-based programming.

[0023] Reconstructing the Event-Driven Programming Paradigm: Addressing the pain points of complex callback nesting and difficult state management in existing asynchronous programming, this invention proposes a hierarchical declaration model for parameters and events based on components. Parameter layer (param): Defines the static configuration properties of the component (such as SQL statements, hardware port numbers), supporting immediate execution. Event layer (hook): Declares business logic blocks triggered by conditions (such as payment success callback, sensor exception handling), and achieves stack pollution-free process control through GOTO tag jump and containerized variable space, fundamentally avoiding the "callback hell" problem.

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

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

[0026] In summary, the SDL programming language described in this invention offers significant advantages in improving R&D efficiency, reducing errors, and enhancing product stability through its unique modular, optimized, and automated features. This makes the technology particularly suitable for development as a foundational language for future human-computer interaction, especially in scenarios integrating artificial intelligence features for further automation and automatic programming calls.

[0027] Furthermore, the uniqueness of this invention lies in its cross-domain application capabilities, system component optimization, and comprehensive optimization of the entire R&D process. It is not merely a development tool, but a fundamental technology that can significantly improve R&D efficiency and quality. This gives it potentially significant value within the existing engineering and technological context, especially in industries that pursue high-efficiency and high-quality R&D outputs. Attached Figure Description

[0028] Figure 1 A schematic diagram of a computer language programming method based on business logic provided for the technical solution of this invention. Detailed Implementation

[0029] An embodiment of the present invention will be further described below with reference to the accompanying drawings.

[0030] Please see Figure 1 The present invention provides 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 SDL code uses components as the basic execution unit and completes process control through predefined keywords. Process control includes process jump 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.

[0031] During the business requirement input phase, the system receives natural language descriptions or structured data templates provided by the user. The semantic analysis engine then uses a domain ontology library to parse entity relationships and operation sequences within the business scenario. The semantic analysis process identifies the relationships and operational constraints between business entities and outputs a standardized set of process rules. This set of rules includes logical node definitions, execution order logic, and business constraints, providing structured input for subsequent code generation.

[0032] Based on a set of process rules, the SDL programming interface transforms business logic into declarative code descriptions. The SDL language uses pre-encapsulated business components as atomic operation units and implements process control structures through predefined keywords. These structures include explicit jump instructions and termination instructions; jump instructions are associated with logical node identifiers in the process rules, and termination instructions trigger resource reclamation operations. Component calls are implemented through declarative parameter configuration, shielding the underlying technical implementation details.

[0033] The SDL compiler performs lexical analysis and syntax tree construction on declarative code, generating intermediate representation data. This intermediate representation data uses a directed acyclic graph structure to record component dependencies and control flow paths, including component parameter metadata, event hook bindings, and environment adaptation interface declarations. A platform-independent layer abstracts the core business logic, while a platform-specific extension layer stores environment-related configuration attributes; this separation ensures cross-platform compatibility.

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

[0035] The hardware executable program is input into the simulation verification module for functional verification. The simulation verification module constructs a virtual execution environment based on the 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, outputting a verification report identifying register read / write anomalies and timing violations.

[0036] When the environment adapter determines that the target is a scalable computing platform, the entity conversion engine parses the cloud extension attributes in the platform's specific extension layer. These cloud extension attributes include service governance policies, load balancing configurations, and circuit breaker threshold parameters. The entity conversion engine then generates microservice interface definitions based on the target framework specifications. The source code project is compiled and packaged using a continuous integration toolchain to generate containerized microservice assemblies.

[0037] During the execution phase, a runtime container is selected based on the environment type. In hardware execution environments, a verified executable program is loaded onto the physical device using a flashing tool; in cloud execution environments, microservice instances are scheduled through a container orchestration platform. The results of business logic execution are written to a standardized output channel. This channel encapsulates data according to a protocol format defined by the process rules, supporting both structured text and binary stream transmission formats.

[0038] Before executing a jump operation, the target address validity is verified. The address validator accesses the jump address index table generated during compilation to confirm that the target identifier has a valid address mapping and does not exceed the executable boundary. An invalid jump triggers an exception handling process, in which the exception handler rolls back uncommitted data changes and resets the component state machine.

[0039] The resource reclaimer performs an ordered release operation upon process termination. The reclaimer traverses the runtime resource allocation record and unloads resource instances in reverse order according to the component dependency graph. The unloading process calls the resource release callback functions registered by the components, persistently writes the execution results to non-volatile storage, and stores transient data in a volatile cache.

[0040] The type management system performs dynamic inference when data is written to general storage space. The type inference engine detects the storage structure characteristics of the written data, identifying contiguous memory blocks as array types and pointer-associated structures as object types. Nested data structures recursively parse the types of their internal elements, generate composite type signatures, and update the versioned mapping table.

[0041] Cross-platform data synchronization is activated through the environment policy engine. The environment monitor polls for hardware register status or cloud configuration change events, and initiates a bidirectional channel after matching the preset synchronization trigger rules. The synchronization engine translates general storage space data changes into platform-specific operation instructions, converts hardware environment changes into register bit operations, and cloud environment changes into configuration center application interface calls.

[0042] Component access conflicts are resolved using a distributed transaction lock mechanism. A resource conflict detector monitors concurrent access events from multiple components. The hardware environment implements spinlocks based on atomic instructions, while the cloud environment uses a lease protocol to coordinate multiple nodes. The adjudication algorithm is selected based on the environment policy; the hardware environment implements real-time preemptive scheduling, and the cloud environment performs weighted resource quota allocation.

[0043] Specifically, the computer language programming method based on business logic described in this invention, wherein the process control is completed 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.

[0044] During the compilation phase, the compiler performs a static scan of the SDL source code to identify predefined keywords and their associated target identifiers. Predefined keywords include reserved character sequences for flow jump instructions and termination instructions, while target identifiers use named tags to mark flow node positions. The compiler constructs a symbol table to store the mapping relationship between target identifiers and memory address offsets, generating intermediate representation data. When this intermediate representation data includes a platform-independent business logic description layer and a platform-specific adaptation extension layer, the mapping relationship is encoded into a jump address index table.

[0045] During runtime, the jump address index table is loaded into the runtime context. When the interpreter executes a flow jump keyword, it retrieves the memory address offset of the target node from the index table using the target identifier and modifies the program counter to switch the execution location. A flow termination keyword triggers an interrupt handler, which reads the current execution stack state and calls the resource reclaimer.

[0046] The resource reclaimer traverses the runtime resource allocation record, releasing occupied memory buffers and hardware handles. Execution result data is processed according to a preset storage strategy: transient results are written to volatile storage, and persistent results are committed to non-volatile storage devices. The result storage procedure performs data format encapsulation, with encapsulation rules based on the metadata definition associated with the target identifier.

[0047] Before executing a process jump operation, the validity of the target address is verified. The address validator accesses the jump address index table to confirm that the target identifier has a corresponding address record and is within the executable range. An invalid jump triggers an exception handling process. The exception handler records the error code and rolls back the current transaction state. The rollback operation includes undoing uncommitted data changes and resetting the component's internal state machine.

[0048] The process termination operation includes an ordered shutdown sequence. The termination sequence controller performs reverse unloading based on the component dependency graph, calling the component's resource release callback function during the unloading process. The final execution result is written to a result container, which uses a key-value pair storage model, with the key name generated by combining the target identifier and the result type identifier.

[0049] Specifically, the business logic-based computer language programming method of the present invention includes a parameter parsing step in compiling the SDL code, the parameter parsing step including: 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.

[0050] The parameter parser scans parameter declaration statements in the SDL code, extracting characteristic identifiers as the basis for distinguishing parameter categories. These characteristic identifiers consist of a predefined character prefix and a type suffix. The compiler uses regular expressions to match identifier patterns and categorizes them into variable parameters, event parameters, or environment parameters. Parameter category information is recorded in a symbol table, which is associated with type constraint rules and default value generation strategies.

[0051] Named parameter resolution mode activates the named matching mechanism. The parser establishes a mapping dictionary between parameter names and component interface definitions, traverses named assignment statements in the source code to perform dictionary lookups, and writes the matching parameter values ​​to the target storage slot. When a duplicate assignment of a parameter with the same name is detected, the later assignment operation overwrites the previous stored value, and the overwrite operation updates the parameter version flag in the runtime environment.

[0052] Unnamed parameters enable sequential parsing. The parser reads unnamed values ​​according to their position in the source code, based on the parameter order list in the component interface declaration. When a position is missing, a default value generation strategy is invoked, which obtains the initial value corresponding to the type based on the parameter category recorded in the symbol table. Position overflow triggers a syntax exception, and the exception handler interrupts compilation and outputs error location information.

[0053] The parsed parameter values ​​are loaded into the runtime environment. The runtime environment establishes a binding relationship between the parameter storage area and the component execution context. The storage area adopts a hierarchical namespace architecture: the global namespace stores environment parameters, the local namespace mounts variable parameters, and the event namespace registers event parameters. Parameter values ​​are written to the operation execution type compatibility check, and the check is based on the type constraint rules registered in the symbol table.

[0054] During the component invocation phase, parameter values ​​are accessed through the runtime environment interface. The execution engine retrieves the corresponding local namespace based on the current execution location, and the namespace resolver locates the storage slot address based on the parameter name. Event parameters are activated when the triggering condition is met. The event handler extracts the parameter value from the event namespace and constructs the event message body, which is then passed to the event response interface of the target component.

[0055] Specifically, the computer language programming method based on business logic described in this invention, after storing the parsed parameter values ​​in the runtime environment, further 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.

[0056] The type validator validates parameter values ​​based on a predefined type rule base. The type rule base stores the mapping between parameter names and data types; the validation process matches the value type against the declared type. Validated parameters are loaded into the execution environment's memory allocation area, which is divided into independent access spaces according to the parameter's scope. The loading process performs a deep copy operation, creating a runtime instance copy of the parameter value.

[0057] The execution engine calls the dedicated interface adapter registered by the target runtime environment. The interface adapter activates the corresponding implementation based on the environment type: for hardware environments, it calls the peripheral driver layer; for cloud environments, it accesses the service proxy layer. During operation execution, a transaction monitor records state changes in real time. State data includes operation sequence identifiers, timestamps, and resource consumption metrics. State records are written to a circular buffer for efficient circular storage.

[0058] Event listeners continuously monitor the status of trigger conditions. Trigger conditions are divided into static and dynamic conditions: static conditions are defined by pre-defined Boolean expressions at compile time, while dynamic conditions are calculated in real time based on runtime state data. When a condition is met, the event scheduler activates the event logic unit, which obtains parameter instances through the execution environment interface and executes a predetermined sequence of operations.

[0059] The operation results are output to a result container in shared storage. The result container uses a hierarchical key-value storage architecture, where the key name is generated by combining the component identifier and the operation type. The output process performs data serialization, and the serialization format is automatically selected based on the target environment: a binary compact format is used for hardware environments, and a structured text format is used for cloud environments.

[0060] The event logic execution process supports nested call chains. The event handler maintains a call stack depth counter, and a circuit breaker is triggered to terminate event propagation when the stack overflows. After the event execution result is written back to the shared storage space, the execution environment update component's state machine transition flags are used for subsequent process jump decisions.

[0061] Specifically, the computer language programming method based on business logic described in this invention, wherein verifying parameter values ​​based on preset type rules and loading the verified parameters into the execution environment includes: 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.

[0062] The lexical analysis phase identifies characteristic identifiers in parameter declaration statements. These identifiers are composed of type prefixes and variable names, and the compiler distinguishes parameter type categories using regular expression pattern matching. Type categories are divided into three types: basic data types, component object references, and event callback functions. The classification results are recorded in the type attribute field of the symbol table. The symbol table synchronously stores type constraint rules, including a type compatibility matrix and conversion function pointers.

[0063] Named identifiers establish the binding path between parameter values ​​and target variables. Named parameters use a hash table for name matching, where the hash table key is the parameter identifier declared in the source code, and the key value points to the storage slot address defined in the component interface. Unnamed parameters locate the storage slot using a sequential index table, which generates a position mapping relationship according to the order of component interface declarations. The position resolver detects the deviation between the number of parameter values ​​and the interface definition; if the number is insufficient, it fills in a default value object; if the number overflows, it triggers a syntax exception.

[0064] During the compilation phase, static type verification of parameters is performed. The type checker traverses the parameter declarations recorded in the symbol table and extracts the expected type corresponding to the storage slot address. The verifier compares the actual type of the parameter value with the expected type; the actual type is obtained through the type metadata carried by the syntax tree node. If a type mismatch occurs, the error handler is invoked, which generates type conflict diagnostic information and terminates the compilation process.

[0065] The validated parameter values ​​are loaded into the execution environment's memory structure. The loader selects a memory allocation strategy based on the parameter type: primitive data types are allocated contiguous memory blocks, object references are associated with pointers, and event callback functions are registered with the event dispatcher. The memory allocation process performs a copy-on-write operation, generating a runtime-independent copy of the parameter values.

[0066] The termination process upon type validation failure includes transaction rollback. The rollback controller cleans up allocated memory resources and releases temporary storage space occupied by the symbol table. The error reporter outputs detailed location information for the type conflict, including the source code line number, parameter identifier, and the comparison result between the expected and actual types.

[0067] Specifically, the computer language programming method based on business logic described in this invention further 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.

[0068] The parameter classifier separates variable-type parameters from event-type parameters based on their type. Variable-type parameters are loaded into the runtime environment's data storage area, which is divided into namespaces according to scope hierarchy. Event-type parameters trigger the type recognition module, which parses the feature modifiers in the event declaration. These feature modifiers include synchronous execution identifiers or asynchronous listening identifiers, and the recognition results are written to the event registry.

[0069] During the compilation phase, the event logic converter generates intermediate representation nodes. The converter parses event logic code blocks, extracts conditional expressions and execution statement sequences, and constructs directed state nodes with target identifiers. These state nodes are stored in the event subgraph of the intermediate representation data. The event subgraph is associated with the interface addresses and trigger condition metadata of the associated meta-components. The intermediate event representation nodes generated during the compilation phase belong to the platform-independent business logic description layer, and their jump logic is implemented through a mapping table, decoupling them from the platform-specific extension layer.

[0070] During the runtime phase, the event monitor detects whether the triggering conditions are met. Synchronous events are detected by the status detector polling the values ​​of key variables, while asynchronous events receive external interrupt signals via the message bus. The trigger signal is input to the event scheduler, which queries the event registry to obtain the address of the intermediate representation node corresponding to the target identifier.

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

[0072] The process controller retrieves the execution location mapping table based on the target identifier. The mapping table records the correspondence between the target identifier and the program counter offset. The controller selects the process jump path based on the event handling result status code: a successful jump operation updates the program counter, while a failure triggers process termination and resource reclamation. The jump operation verifies the validity of the target address; an invalid address activates the exception handling channel.

[0073] Specifically, the computer language programming method based on business logic described in this invention, which associates event processing results with process jumps and terminations, further 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.

[0074] The environment type identifier allocates storage space based on the characteristics of the target operating environment. Resource-constrained hardware environments activate the hardware adaptation layer allocator, while scalable computing platforms invoke the cloud platform adaptation layer allocator. The allocator creates a two-tiered structure of general-purpose storage space and environment-specific storage space. The general-purpose storage space is deployed in the shared memory area, while the environment-specific storage space is mapped to the device characteristic management area.

[0075] A general-purpose storage space enables a cross-component data sharing mechanism. This mechanism employs a pre-built publish-subscribe model, with components registering data access interfaces through a unified message bus. The data storage format uses platform-independent byte stream encoding, with encoding rules including a metadata header and payload. The metadata header records the component identifier and data version number. Read operations perform byte stream decoding, while write operations trigger data change notification events.

[0076] A dedicated environment storage space stores runtime environment characteristic data. The hardware environment is mapped to the register abstraction layer, storing GPIO status words and communication protocol caches; the cloud environment is bound to a distributed configuration center, storing store instance metadata and load balancing strategies. Characteristic data is accessed through an environment proxy interface, which encapsulates the differences in the underlying driver implementation.

[0077] A two-way data synchronization channel is established using a transaction log tracker. The synchronization engine monitors data change events in the general storage space and generates incremental operation log records. These log records are input to an environment converter, which translates operation instructions according to the environment type: hardware environments are translated into register bit operation instructions, and cloud environments are translated into configuration center API calls. The reverse synchronization process is triggered by the environment monitor; environment characteristic change events are used by the converter to generate update transactions for the general storage space.

[0078] The synchronization channel performs conflict detection and resolution. The conflict detector compares the data version number with the timestamp. In the hardware environment, a semaphore locking mechanism is used, while in the cloud environment, optimistic locking is implemented. The conflict resolution strategy is selected based on the environment policy engine: in the hardware environment, real-time control data is prioritized; in the cloud environment, data is forcibly overwritten based on the transaction sequence number. The resolved data changes are written to the target storage space, and the version tag is updated.

[0079] Specifically, the computer language programming method based on business logic described in this invention further 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.

[0080] The type manager is activated when data is written to general storage. The type manager parses the byte stream structure of the written data and extracts the initial type marker from the header metadata. When metadata is missing, value feature analysis is performed. The feature analyzer detects the data format pattern: numeric sequences are identified as arrays, key-value pair sequences are classified as dictionaries, and undefined formats are marked as generic objects. The analysis results generate a temporary type descriptor and are appended to the data header.

[0081] The type inference engine updates the type mapping table based on the characteristics 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 the data nesting level: a single-level structure directly records the basic type, while a nested structure recursively parses the types of its internal elements and generates a composite type signature. Each data update operation triggers the increment of the mapping table version number, which is used to track the type change history.

[0082] The type mapping table update rules follow the dynamic overwrite principle. When the same variable name is assigned new data, the type comparator verifies the differences 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: deleting the old version type record and writing the new version type signature and version timestamp. Historical version records are dumped to the type audit log for diagnostic analysis.

[0083] The component read operation invokes the type matching validator. The validator extracts the expected type declared in the component interface and performs a structural compatibility comparison with the current version type descriptor in the general storage space. Basic types undergo equality matching, while composite types use a depth-first search algorithm to verify field consistency. Compatibility judgments are based on the conversion relationship matrix defined in the type rule library, which includes a list of implicit conversion permissions.

[0084] A type mismatch triggers an execution termination protocol. The termination protocol includes an ordered rollback sequence: the rollback controller freezes the currently executing thread, uncommitted memory space change operations are revoked, and allocated runtime resources are released. The error handler generates a type conflict report, which includes the variable name, expected type descriptor, actual type descriptor, and type mapping table version information.

[0085] Specifically, the computer language programming method based on business logic described in this invention includes dynamically inferring variable types in the general-purpose storage space, including: 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.

[0086] The data type detector scans for data instances written to the general storage space. The detection process is based on the memory structure characteristics of the data instances: contiguous memory blocks are marked as array types, pointer-associated structures are identified as object types, and function pointers are classified as callback types. When a nested level is detected, a recursive parser is started. The recursive parser decomposes the internal elements layer by layer and extracts the meta-type descriptors, ultimately generating a tree-shaped signature structure of the composite type.

[0087] The type descriptor generator constructs type mapping table entries based on the parsing results. The tree-like signature structure is converted into type descriptor encoding, with encoding rules including hierarchical depth marking and leaf node type marking. The mapping table adopts a versioned storage model; each update operation generates a new version entry and retains a snapshot of historical versions. The entry update process performs atomic write operations, which ensure consistency in a multi-threaded environment through memory barrier instructions.

[0088] Runtime data type and mapping table record comparison employs a descriptor compatibility algorithm. The algorithm takes the actual descriptor of the current data instance and the latest descriptor of the mapping table record as input, and outputs a set of difference markers. When a change in the underlying type or a difference in the nested structure dimension is detected, it is marked as a type incompatibility event. A type incompatibility event triggers a mapping table overwrite process, which appends the new descriptor to the version chain and activates the historical version archive.

[0089] Type overwrite operations synchronously update the type audit log. The logger captures snapshots of the descriptors before and after the overwrite, recording the change timestamp and the operation thread identifier. The audit log is stored in a circular buffer; when the buffer is full, a compression and dump operation is triggered, and the dump file is associated with the runtime diagnostic interface.

[0090] The dynamic type inference process is decoupled from the component execution environment. The type management system runs independently in a shared memory management area and receives data write events through an inter-process communication interface. This decoupled architecture allows the hardware and cloud environments to reuse the same type inference core. Environmental differences are adapted through a descriptor encoding conversion layer, which selects either compact binary encoding or readable text encoding based on the characteristics of the target platform.

[0091] Specifically, the computer language programming method based on business logic described in this invention, after establishing a bidirectional data synchronization channel, further 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.

[0092] The environment monitor polls for hardware register status or cloud configuration change events, generating environmental characteristic data change signals. These signals are input to the runtime environment policy engine, which matches preset synchronization trigger rules: interrupt priority threshold rules for the hardware environment and service level agreement (SLA) policies for the cloud environment. When a rule is matched, a bidirectional data synchronization channel is activated; the activation command includes a synchronization direction identifier and data range filtering conditions.

[0093] The runtime environment policy engine loads the permission allocation matrix. This matrix generates differentiated access permissions based on component security level and environment type: a register address whitelist is allocated for hardware environments, and access tokens are granted to the configuration center namespace for cloud environments. The permission allocation process follows the principle of least privilege, ensuring that components only obtain the data access necessary for execution. Access tokens are bound to component identity credentials, which are injected into the component's metadata during the compilation phase.

[0094] 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.

[0095] 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.

[0096] 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.

[0097] The technical solution of this invention is explained in detail below: 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.

[0098] For the SDL language mentioned above, the syntax structure of the SDL language is as follows: Component(param0 = value, param1 = value); Component( param0 = value, hook1: GOTO point1, # When writing GOTO directly after hook, the curly braces can be omitted. hook2: { The DSL language compiler is not sensitive to punctuation marks, but for better writing, it is recommended to use complete punctuation. Component(param0 = value, param1 = value); Component(param0 = value, param1 = value); Component(param0 = value, param1 = value); GOTO point2; } ); point2: Component(value0, value1); Component(value0, param3 = value3); # Parameters are parsed in order. If a named parameter is encountered, the skipped parameters are assigned default values.

[0099] 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.

[0100] For the SDL language described above, the component structure is: COMPONENT_NAME( param1 = value, / / Parameter declaration param2 = value, hook1: { ...}, / / Event hook hook2: GOTO label ) 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). For the SDL language mentioned above, its variable storage scheme is as follows: The SDL language uses a shared namespace for data variables as well as special namespaces for data variables specific to different project types. For example: In microservice development, SDL namespaces include: global variables `request`, `result`, and `session`, which can be accessed directly using methods like `container.variable_name`. `request` is the namespace for storing service request parameters, with fixed variables including: `request.url` (the request URL), `request.path` (the service mapping), and `request.$ip` (the IP address of the request). `result` is the container for storing component execution results; all components can read and write data in `result`. `session` is the container for storing session variables, used to identify requests from different clients (identification principle: whenever a new client requests the server, the server assigns it a `jtoken` and a `session` namespace; subsequent client requests can use the `jtoken` to operate the `session` namespace bound to the `jtoken`). It can be used to store user login status, user information, etc.

[0101] In chip-oriented programming environments such as PIC, the SDL namespace includes only the global variable `result`. Other microcontroller resources such as P1, P2, P3, FIFO, I2C, UART, and SPI are handled by components, allowing users to focus solely on business logic.

[0102] For the aforementioned SDL language, its auxiliary system components are: the compiler and converter are written in JavaScript, and its executor, interpreter, and entity conversion engine are written in Java. As a preferred embodiment of the SDL programming language, the compiler or executor can also be implemented in other languages ​​or methods. The main purpose of this invention is to protect the SDL programming language, so only its auxiliary system components are briefly described here to demonstrate that the SDL programming language has higher programming efficiency and stability than existing and emerging languages.

[0103] For the SDL programming language: The compiler is written in JavaScript and executes in the user's browser. When the user finishes writing SDL code in the browser environment, the SDL compiler performs real-time compilation checks and provides immediate guidance to the user to correct syntax errors based on the compilation output. Once the user has finished writing, the compiler outputs metadata (including component execution parameters and binary data of the execution flow, referred to here as metadata) that can be directly executed by the executor. Using JavaScript to implement the compiler allows for faster response to user code writing, providing timely code suggestions and error messages, while significantly reducing the server's compilation load.

[0104] Converter: After successful compilation, users can use the converter to graphically display the compiled metadata, providing a more intuitive and visually appealing dynamic representation of the current business logic.

[0105] Reverse parser: After successful compilation, users can use the reverse parser to reverse format the compiled metadata and output it as SDL source code. This facilitates code modification and parameter assignment. The main function is to synchronously generate SDL source code from business logic generated using drag-and-drop methods (bidirectional conversion between source code and drag-and-drop generated business logic).

[0106] Executor: After successful compilation, users can directly submit the compiled metadata to the server. When the project type is microservice, the microservice address on the server is accessed directly. The executor can directly execute the metadata of the microservice on a component-by-component basis to implement the business logic of the microservice. When the project is an embedded / PIC chip-oriented program, the submitted metadata is used by the executor to perform chip program simulation to verify the correctness of the written program.

[0107] Interpreter: When native code is embedded in SDL code, after the client submits metadata to the server, the server will call the interpreter to compile the native code. For example, when the native code is Java, the interpreter will combine the native code to 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). When the native code is JavaScript, the interpreter will automatically inject global variables and common utility libraries of the current project type and store the injected code in the cache. When the executor executes, it will directly execute the JavaScript code injected with global variables from the cache. When the native code is Python, the interpreter will automatically inject global variables and common utility libraries of the current project type and store the injected code in the cache. When the executor executes, it will directly execute the Python code injected with global variables from the cache. When the native code is C / C++, the interpreter will automatically generate a temporary C / C++ source code file (automatically injecting global variables and library files) and compile it into machine code that can be directly executed by the target chip (compiling into a DLL). Entity Converter: When a user selects to export native code, the entity converter will, based on the user's selected project type and chip type (only required for PIC / embedded chips), and by inputting the compiled metadata, sequentially call the native code assembly methods under the corresponding framework of the components. This can assemble the code of all components and generate a native project.

[0108] The implementation process of this invention is as follows: To reproduce the SDL language described in this invention, it is necessary to implement its "auxiliary system components". Please refer to the description of each auxiliary system component in the above patent content.

[0109] Step 1: Analyze the R&D process in the domain to be implemented, and break down the work in the R&D process at the atomic level (atomic level: in the domain implementation process, there is no need to break it down at the business level. For example, in software development, the atomic level is the function in the business process, such as executing SQL, sending SMS, sending email, executing algorithms, making payments, etc. In the field of chip programming, it is the basic chip function or external device function, such as: GPIO output, specified protocol communication (I2C, FIFO, SPI, UART), external ADC reading, reading external sensors, etc.).

[0110] Step 2: Determine the business logic of the product being developed, and describe the product's business logic using the SDL programming language.

[0111] Step 3: Use the SDL language compiler to compile the SDL code. When a syntax error occurs, provide compilation prompts to guide the user in fixing the code; when compilation is successful, output metadata.

[0112] Step 4: Use the metadata executor to execute the compiled metadata to obtain the program execution result and achieve the program execution purpose.

[0113] Step 5: Use the metadata to entity engine to convert the metadata output from the compilation to obtain the project source files for production or secondary development.

[0114] 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 involves parsing the component parameters and call relationships in the business logic metadata to extract the functional descriptions and context information of each component, including component type (e.g., SQL execution component, I2C communication component), parameter configuration (e.g., SQL statement, communication pin), and execution order. Based on the target project type (e.g., Spring Boot, Keil), the engine retrieves the corresponding project's basic structure description, fixed file information, and directory structure from the project type structure library. It then initializes the project's basic files through a virtual file system, such as the Maven configuration file and Controller / Service layer directory structure for a Spring Boot project, or the chip base library files and main program file main.c for a Keil project.

[0115] 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 a Spring Boot project, the engine analyzes the incoming SQL type (query / modify) 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 a Keil project, the engine generates I2C utility functions (such as start signal, stop signal, byte send function) and delay functions based on the communication pin, data content, and clock frequency parameters, and injects the function call logic into a specified location in the main.c file.

[0116] During component code generation, the engine utilizes the variable management space, function management space, and code block management space of the virtual file system to achieve variable scope isolation, automatic function dependency injection, and structured code block storage. For example, when generating Service layer code, the engine uses the function name generator in the virtual file system to call the large model to generate function names for Services and Controllers based on interface mapping information; and uses the annotation generator, combined with the component functions described in the DSL language, to generate comprehensive functional description comments for variables and functions.

[0117] After code generation is complete, the engine calls the project type optimizer to optimize the structure of the generated source code. For Spring Boot projects, the optimizer checks for repeated use of variables at the same level, merges redundant variable definitions, identifies duplicate code blocks and encapsulates them into generic functions to reduce logical complexity. For Keil projects, the optimizer analyzes memory usage, merges duplicate 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 dependencies, achieving a complete conversion of no-code / low-code business logic metadata into the target project type source code.

[0118] This invention solves the following technical problems: Solving the problem of high coupling between business logic and technical implementation: In response to the shortcomings of existing programming languages ​​where business code and technical details (such as database connection management and hardware register operations) are deeply intertwined, this invention uses a declarative component invocation mechanism to abstract the technical infrastructure into reusable standardized components (such as SQL and GPIO). This allows developers to directly describe the logical flow in terms of business semantics, while the technical details are encapsulated and implemented within the components, thereby achieving complete decoupling between business intent and underlying technology.

[0119] Eliminating the domain gap in cross-platform development: In response to the current situation where cloud services and embedded systems require different technology stacks, this invention designs a unified syntax framework and, through an environment-adaptive component implementation mechanism, enables the same business logic code to run seamlessly on microservice clusters and embedded devices (directly manipulating I2C / GPIO hardware resources), achieving the core goal of "write once, deploy on multiple devices" and reducing redundant development costs for multi-platform adaptation.

[0120] Reconstructing the Event-Driven Programming Paradigm: Addressing the pain points of complex callback nesting and difficult state management in existing asynchronous programming, this invention proposes a hierarchical declaration model for parameters and events: Parameter layer (param): Defines the static configuration properties of the component (such as SQL statements, hardware port numbers), and supports immediate execution; Event layer (hook): Declares business logic blocks triggered by conditions (such as payment success callback, sensor exception handling), and achieves stack pollution-free process control through GOTO tag jump and containerized variable space, fundamentally avoiding the "callback hell" problem.

[0121] Intelligent abstraction of hardware interaction: To address the problem of high redundancy in hardware operation code in embedded development, this invention has a built-in hardware intent parsing engine. Developers only need to declare the hardware behavior target (such as "read temperature sensor data"), and the language runtime will automatically select the optimal communication protocol (I2C / SPI), complete timing configuration and signal parsing, and realize secure interaction between hardware status and business logic through containerized result storage.

[0122] Constructing a self-describing business documentation system: To address the problems of poor code readability and the disconnect between documentation and implementation in existing code, this invention uses structured syntax design (explicit parameter naming, tagged process jumps) to make the source code itself a visual business process diagram. Combined with the interactive semantic graph generated by the compiler, it realizes the "code as documentation" expression of business logic, improving system maintenance and collaboration efficiency.

[0123] This invention aims to provide a highly expressive, low-tech-intrusive domain-specific language. While ensuring execution efficiency, it reshapes the description paradigm and implementation method of business logic through a deep integration of technical abstraction and domain modeling. This significantly improves the development efficiency and stability of software and hardware products, and lowers the barrier to entry for the next step of AI-driven automated programming (direct human-computer interaction).

[0124] The core innovation of this invention lies in: By embedding native code (Java / JS / Python / C++) into the component event layer, and dynamically generating temporary code (such as Java classes and C++ DLLs) by the interpreter, a dynamic bridge between the business layer and the technical layer is achieved. This invention uses text syntax for better integration with large AI models, making it easier to write business code for these models (large models cannot directly generate graphical logic, but can generate text-based SDL business logic descriptions). Furthermore, SDL uses components as the basic unit of execution, enabling clearer expression of business logic. (Existing graphical representations suffer from readability difficulties in complex business logic scenarios; textual descriptions are more concise). Through the component-based design of the SDL programming language, SDL code can be compiled to the corresponding platform's underlying code (C / C++ / assembly / chip instructions), rather than running on a fixed operating system or virtual machine.

[0125] Based on the compile-time address mapping table and sandbox isolation mechanism, GOTO jumps only apply to the business logic layer, avoiding callback nesting and state chaos. As a cross-domain (embedded, microservice) language that focuses on business logic description, using GOTO has the following advantages. It facilitates the conversion of SDL code into a visual interface for flowchart-style business logic display. Generally, business logic is expressed using flowcharts. For example, loops and conditional statements are represented by arrows to guide the flow, which corresponds to GOTO to the corresponding node in the text.

[0126] SDL also features an event-driven model, such as hooking events in components. GOTO, as a common logic processing method, has significant advantages, such as handling exceptions and successes during navigation. The reason GOTO navigation can easily lead to logical confusion is its overuse. Furthermore, in current code development, business logic is often buried within a large amount of low-level computational code, making GOTO even harder to understand. However, in SDL code that only describes business logic (where SDL components already have synchronous and asynchronous event hooking capabilities), the appropriate use of GOTO is more conducive to understanding the logic.

[0127] It is more conducive to hardware adaptation. When adapting SDL code to hardware platforms, using GOTO is more in line with assembly language habits. It can directly convert the code into assembly code, resulting in higher execution efficiency. Similarly, using GOTO in a microservice environment also has the advantage of execution efficiency.

[0128] Hardware intent end-to-end automation: The engine automatically generates the complete chain from protocol selection to business processing, reducing the amount of code; Dynamic type management system: The general storage space infers the type at runtime and reduces cross-platform data conflicts by combining environment strategies (hardware memory lock / cloud RBAC).

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 SDL code uses components as the basic execution unit and completes process control through predefined keywords. Process control includes process jump 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