Executable-specification-based ontology logic and action code generation method and system

Abstract

This invention discloses a method and system for generating ontology logic and action code based on executable specifications. It receives ontology logic description files and ontology action description files, traverses and parses all entries within the files, classifies them according to the execution method attributes corresponding to each entry, and extracts core identifier information. Based on the classification results, it converts the ontology logic description or ontology action description into corresponding executable specifications, perfecting the input, output, and processing logic definitions of the specifications. The executable specifications are then input into a preset template engine for rendering to generate source code files, and simultaneously generate corresponding unit test files based on the specification definitions. All files are organized according to a preset directory structure and undergo syntax compliance verification. Upon successful verification, a complete executable code package is output. This addresses the problems of disconnect between ontology knowledge and implementation code, insufficient automated generation capabilities, limited adaptability to specific scenarios, and unreliable code quality in existing ontology engineering, achieving fully automated generation from ontology to executable code.

Description

Technical Field

[0001] This invention relates to the fields of computer software and ontology engineering technology, and in particular to a method and system for generating ontology logic and action code based on executable specifications. Background Technology

[0002] This invention belongs to the field of ontology engineering and automatic computer code generation technology. As a core supporting technology for knowledge modeling and semantic web systems, ontology technology has been widely used in knowledge graphs, intelligent control systems, industrial digitalization and other fields. Its core is to realize the formal and standardized expression of domain knowledge through standardized logic and action descriptions.

[0003] Currently, the engineering implementation of ontology technology largely relies on manual conversion of the logical rules and action instructions of ontology descriptions into executable program code line by line. Existing automated code generation solutions mostly support only single-type ontology description conversion, severely limiting their adaptability to various scenarios. On the one hand, existing solutions cannot differentiate ontology entries with different execution method attributes, easily leading to a disconnect between ontology semantics and implementation code. The converted code has poor executability, requiring significant manual secondary correction. On the other hand, existing solutions lack a standardized executable specification transfer link, failing to simultaneously generate corresponding unit test files. This makes it difficult to guarantee code quality and syntax compliance, resulting in low development efficiency and high maintenance costs for ontology engineering implementation, making it difficult to adapt to the large-scale application needs of ontology across multiple scenarios and execution modes. Summary of the Invention

[0004] The main objective of this invention is to provide a method and system for generating ontology logic and action code based on executable specifications. By parsing and classifying ontology logic and action description files, converting them into standardized executable specifications, and automatically generating code and test files, verifying and outputting complete code packages, the invention achieves fully automated generation of ontology knowledge into executable programs, improving development efficiency and code quality, and adapting to multiple types of execution scenarios.

[0005] To achieve the above objectives, this invention provides a method for generating ontology logic and action code based on an executable specification, comprising the following steps: The entry information in the obtained ontology logic description file and ontology action description file is parsed, and the classification results are obtained after classifying the execution method attributes of each entry information. The type identifier and structural description information of each entry are then extracted. Based on the classification results, the ontology logic description or ontology action description of the corresponding entry is converted into an executable specification containing specification structure element definitions, and the definition content of the executable specification is corrected using the type identifier and the structure description information. The executable specification is input into a preset template engine for rendering, generating a source code file containing executable code and explanatory text; Generate unit test files corresponding to the source code files based on the definition of the executable specification; The source code files and unit test files are organized according to a preset directory structure, and an executable code package is output after passing the syntax compliance check.

[0006] Furthermore, the steps of receiving the ontology logic description file and the ontology action description file, traversing all entries in both types of files, reading the execution method attributes corresponding to each entry, classifying all entries according to the execution method attributes, and simultaneously extracting the type identifier and structural description information of each entry include: Read the received ontology logic description file and ontology action description file, and parse all the entry information contained in the two types of files; All the entry information is initially screened to remove invalid entries that do not conform to the format specifications, and only the attributes, identifiers and core content of the entries are retained; All items after the initial screening are grouped and categorized, and the type identifiers and structural descriptions corresponding to all items are extracted simultaneously for item classification. A unique identifier is established for each entry category, and the mapping relationship between the entry and the corresponding execution method attributes, type identifier, and structural description information is recorded.

[0007] Furthermore, the step of converting the ontology logic description or ontology action description corresponding to each entry into an executable specification corresponding to the execution method attribute according to the classification results, and simultaneously combining the type identifier and structural description information of the corresponding entry to improve the definition of the executable specification, includes: Read each categorized entry, extract the corresponding entry's ontology logic description or ontology action description, and match it with the specification conversion template corresponding to the execution method attribute; According to the specification conversion template, the ontology logic description or ontology action description is converted into an initial executable specification, and the input definition, output definition and processing logic definition of the initial executable specification are confirmed. By combining the type identifier and structural description information of the corresponding entries, the definition of the initial executable specification is corrected for any content that does not meet the format requirements, resulting in a standard executable specification; After verifying the completeness of the standard executable specification, the executable specification is converted.

[0008] Furthermore, the step of inputting the executable specification into a preset template engine and generating a source code file corresponding to the executable specification through rendering by the template engine includes: Read the converted executable specification and match it with the preset code generation template corresponding to the executable specification; The input definitions, output definitions, and processing logic definitions within the executable specification are filled into the preset code generation template, and the initial source code file is generated by performing a rendering operation through the template engine. The initial source code file is supplemented with explanatory text corresponding to the processing logic, and format deviations that occur during the rendering process are corrected to obtain a standard source code file; The executableness of the standard source code file is verified before generating the source code file.

[0009] Furthermore, the step of generating a unit test file corresponding to the source code file based on the input definition, output definition, and processing logic definition includes: Read the input definitions, output definitions, processing logic definitions, and execution entry points of the corresponding source code file from the executable specification corresponding to the unit test file to be generated; Generate initial unit test files according to the preset test generation template, covering normal execution path, boundary input scenarios, and abnormal input scenarios; Supplement the initial unit test file with test description text and correct any deviations between the test logic and the executable specification definition; After verifying the test coverage of the initial unit test file, a unit test file is generated.

[0010] Furthermore, the step of organizing the source code files and unit test files according to a preset directory structure, performing syntax compliance checks on all files, and outputting a complete executable code package after passing the checks includes: Read the generated source code files, unit test files, and the preset directory structure; According to the preset directory structure, all source code files are categorized and placed into the corresponding code subdirectories, and all unit test files are categorized and placed into the corresponding test subdirectories, thus performing the initial organization of the files; Check whether the contents of all source code files and all unit test files conform to the preset syntax rules; If the syntax compliance check passes, all the initially organized source code files and all unit test files, along with the preset directory structure description, will be packaged into a complete executable code package and output.

[0011] Furthermore, the step of converting the ontology logic description or ontology action description into an initial executable specification according to the specification conversion template, and confirming the input definition, output definition, and processing logic definition of the initial executable specification, includes: Read the execution method attribute of the categorized items and match the corresponding specification conversion template; The three types of attributes—code execution, prompt word execution, and API call execution—are matched with corresponding templates, and the core content of the entries is parsed and converted into the corresponding initial executable specifications.

[0012] This invention also provides an ontology logic and action code generation system based on an executable specification, which executes the ontology logic and action code generation method based on an executable specification described above. The ontology logic and action code generation system based on an executable specification includes: The data receiving and parsing module is used to receive the ontology logical description file and the ontology action description file, traverse all entries in the two types of files, read the execution method attributes corresponding to each entry, classify all entries according to the execution method attributes, and simultaneously extract the type identifier and structural description information of each entry. The specification conversion module is used to convert the ontology logic description or ontology action description corresponding to each entry into an executable specification corresponding to the execution method attribute according to the classification results, and simultaneously combine the type identifier and structural description information of the corresponding entry to improve the definition of the executable specification. The code generation module is used to input the executable specification into the preset template engine, and the template engine renders and generates the source code file corresponding to the executable specification. The test generation module is used to generate unit test files corresponding to the source code files based on the input definitions, output definitions, and processing logic definitions of the executable specification. The file verification and output module is used to organize source code files and unit test files according to a preset directory structure, perform syntax compliance verification on all files, and output a complete executable code package after the verification is passed.

[0013] The present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the ontology logic and action code generation method based on executable specifications described above.

[0014] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the ontology logic and action code generation method based on executable specifications described above.

[0015] The ontology logic and action code generation method and system based on executable specifications provided in the above embodiments have the following beneficial effects: By performing full parsing of ontology logic and action description files and preprocessing based on differentiated classification of execution method attributes, the core information of ontology entries is extracted and organized in a standardized manner, breaking the limitation of existing solutions that cannot perform targeted processing of multiple types of ontology entries.

[0016] By using standardized executable specifications as a bridge between ontology semantics and program code, lossless conversion of ontology logic and action descriptions into execution rules is achieved. This addresses the core pain point of semantic disconnect and logical deviation between ontology knowledge and implementation code in the existing ontology engineering process, ensuring that the execution logic of the generated code is completely consistent with the original ontology description.

[0017] By automatically generating business source code, it simultaneously generates full-scenario unit test files that perfectly match the code logic. Combined with full-process executableness verification, syntax compliance verification, and integrity verification, it significantly improves the efficiency of ontology implementation development while comprehensively ensuring the quality, compliance, and direct executableness of the generated code, greatly reducing the investment in manual secondary correction and test development. Attached Figure Description

[0018] Figure 1 This is a flowchart of an embodiment of the ontology logic and action code generation method based on executable specifications in this invention; Figure 2 This is a structural block diagram of an ontology logic and action code generation system based on executable specifications in one embodiment of the present invention; The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0020] Reference Figure 1 This is a flowchart illustrating a method for generating ontology logic and action code based on executable specifications proposed in this invention, comprising the following steps: S1, parse the entry information in the obtained ontology logic description file and ontology action description file, classify them according to the execution method attributes of each entry information to obtain the classification result, and extract the type identifier and structural description information of each entry. S2, based on the classification results, the ontology logic description or ontology action description of the corresponding entry is converted into an executable specification containing specification structure element definitions, and the definition content of the executable specification is corrected using the type identifier and the structure description information; S3, input the executable specification into the preset template engine for rendering, and generate a source code file containing executable code and explanatory text; S4, Generate the unit test file corresponding to the source code file based on the definition of the executable specification; S5. Organize the source code files and unit test files according to the preset directory structure, and output the executable code package after passing the syntax compliance check.

[0021] As described in step S1 above, the system receives the ontology logic description file and the ontology action description file. After receiving the files, it initiates full content parsing to achieve structured reading of the file content and extract all independent entries contained within the file. The system performs a full traversal of all extracted entries, reading the built-in execution method attributes of each entry and simultaneously capturing the type identifiers and structural description information carried in the entries to complete the full extraction of the core information of a single entry. The system uses the read execution method attributes as the classification basis to group and categorize all entries, grouping entries with the same execution method attributes into the same group to achieve a clear division of entries with different execution attributes. The system simultaneously performs regularization processing on the type identifiers and structural description information extracted during the traversal process, establishing a stable association between entries and corresponding core information. The system simultaneously performs compliance verification on all entries, removing invalid entries that do not conform to the format specifications to ensure that all entries participating in the classification process have complete core information and to avoid invalid content interfering with subsequent processing flows.

[0022] As described in step S2 above, the system reads all entries that have completed classification processing, extracts the core content of the corresponding ontology logic description or ontology action description for each entry, and simultaneously retrieves the specification conversion template that matches the execution method attributes of the entry, establishing a precise correspondence between the description content and the conversion rules. The system performs a structured conversion of the ontology logic description or ontology action description according to the matched specification conversion template, generating an initial executable specification. Simultaneously, it clarifies the input definitions, output definitions, and processing logic definitions corresponding to the initial executable specification, completing the initial conversion from ontology semantics to standardized execution rules. The system retrieves the type identifier and structural description information associated with the corresponding entry, supplements and improves the definition content of the initial executable specification, corrects content that does not conform to the standard specifications, and generates a standard executable specification. The system performs a completeness check on the standard executable specification, confirming that the core definitions are complete and without deviation, ensuring that the converted executable specification is completely consistent with the original ontology description semantics.

[0023] As described in step S3 above, the system reads the complete standard executable specification after integrity verification, parses the core definitions within each executable specification, and simultaneously retrieves code generation templates from the preset template engine that are compatible with the executable specification, completing a precise matching and binding between the template and the specification. The system then completely fills the input definitions, output definitions, and processing logic definitions from the executable specification into the corresponding positions of the matched code generation template, starts the template engine to perform rendering operations, generates the initial source code file, and simultaneously maps the business logic corresponding to the ontology description to the code execution logic, ensuring that the code logic completely matches the definitions of the executable specification. The system supplements the generated initial source code file with explanatory text corresponding to the processing logic, standardizes the code format, corrects format deviations generated during rendering, and generates a standard source code file. The system performs executable verification on the standard source code file, confirming that the code has no syntax breakpoints or logical gaps, ensuring that the generated code can be directly compiled and executed.

[0024] As described in step S4 above, the system reads the executable specifications that correspond one-to-one with the standard source code files, fully extracts the fixed input definitions, output definitions, and processing logic definitions within the specifications, and simultaneously captures the execution entry points and parameter mapping rules of the corresponding source code files, completing the full collection of core information required for test generation. Following preset standardized test generation rules, the system builds a test framework that perfectly matches the source code execution logic, generating initial unit test files covering normal execution paths, boundary input scenarios, and abnormal input scenarios. This ensures that the test logic completely covers all execution branches of the source code, with no logical omissions or missing scenarios. The system supplements the initial unit test files with explanatory text corresponding to the test scenarios, standardizes the format of the test code, corrects deviations between the test logic and the original definitions of the executable specifications, and simultaneously performs test coverage verification to confirm that the test coverage meets the preset standards and that the test logic is completely consistent with the source code execution logic, ultimately generating compliant and usable standard unit test files.

[0025] As described in step S5 above, the system reads the generated full standard source code files and corresponding unit test files, and synchronously retrieves the preset standardized directory structure rules to clarify the storage paths and classification rules for different types of files. Following the preset directory structure rules, the system completely organizes the source code files into their corresponding dedicated code subdirectories and the unit test files into their corresponding dedicated test subdirectories, completing the hierarchical organization and standardization of all files. This ensures clear file classification and standardized paths, meeting the standard management requirements of engineering projects. The system performs file-by-file syntax compliance checks on all files after directory organization, scanning the file content line by line to verify compliance with preset syntax specifications and format standards, and identifying syntax errors, format deviations, and logical breakpoints. After successful verification, the system packages the standardized full files, along with the directory structure description, into a complete executable code package. Simultaneously, it performs integrity checks on the generated code package, confirming that the files within the package are complete and undamaged, and are completely consistent with the organized full file content. Finally, it completes the standardized output of the executable code package, achieving a closed-loop implementation from ontology description to executable engineering artifacts.

[0026] In one embodiment, step S1, which involves classifying the entry information in the parsed ontology logic description file and ontology action description file according to the execution method attributes of each entry information to obtain a classification result, and extracting the type identifier and structural description information of each entry, includes: S11, Ontology description file reception and full structured parsing; S12, the entry execution method reads all attributes in a full traversal; S13, Entries are grouped and categorized according to execution method attributes; S14, Extraction of entry type identifier and structural description information.

[0027] In the specific implementation process, the system is deployed on the code generation service node of the industrial internet platform. The underlying service is built on a Java 11 runtime environment and provides a standardized HTTP file receiving interface. The interface supports a maximum file transfer of 500MB per transaction and supports the reception and parsing of mainstream ontology description file formats. The system receives ontology logic description files and ontology action description files uploaded from the industrial digital twin platform through a preset HTTP interface. Both types of files are written in OWL format, and the size of a single file is controlled within the range of 100 to 5000 entries. After the system completes file reception, it first performs an integrity check on the file by comparing the MD5 hash values ​​before and after file transmission to confirm that the file has not been corrupted during transmission. After the verification passes, the system initiates full structured parsing of the file. The system incorporates an OWL ontology parsing engine, scanning the ontology descriptions within a file line by line. This transforms unstructured text descriptions into structured data objects recognizable by the system, breaking down the file into all independent entries. Each entry corresponds to an independent ontology logic rule or ontology action instruction. The data length of a single entry is controlled within the 1KB to 100KB range. During parsing, the original line number and file ownership information of each entry are recorded simultaneously, ensuring that the parsed data can be traced back to its corresponding location in the original file. For example, a parsed ontology logic entry corresponds to the equipment temperature threshold judgment logic in an industrial digital twin scenario. The entry's built-in execution method attribute is code execution, its type identifier is an ontology attribute, and its structural description information includes the input parameter being the equipment's real-time temperature threshold upper limit and the output parameter being the alarm status logic execution result. The system performs a full traversal operation on all parsed entries using a single-threaded sequential traversal mode, with a traversal speed of no less than 1000 entries per second. For the largest scenario with 5000 entries in a single file, the full traversal time is controlled within 5 seconds. During the traversal, the system reads the execution method attribute field built into each entry. This field is a standardized enumeration field predefined in the ontology description file. The enumeration values ​​include three categories: code execution prompt words, execution interface calls, and execution. After reading the attribute field, the system binds the attribute value with the entry's unique identifier and stores it using a memory-level key-value database. The read / write latency is controlled within 1 millisecond, ensuring the efficiency of the traversal process and the stability of the data. The system groups and categorizes all entries based on the read execution method attribute values. The system pre-allocates three independent group storage areas in memory, corresponding to the three categories of execution method attributes: code execution prompt words, execution interface calls, and execution. Entries whose attributes are read during the traversal are automatically written into the corresponding group storage area based on the attribute values, achieving the aggregation of entries with the same execution method attribute.

[0028] For a scenario with 5000 entries in a single file, where code execution entries account for approximately 60%, prompt word execution entries for approximately 25%, and API call execution entries for approximately 15%, the system can complete the grouping and classification of all entries within 1 second, with a grouping accuracy of no less than 100% and no entries being misplaced or omitted. After completing the grouping of all entries, the system counts the number of entries within each group, generates a grouping statistics report, and records the number of entries, file source, attribute, and type information for each group. During the synchronous process of entry traversal and grouping, the system simultaneously performs the extraction of entry type identifiers and structural description information. The type identifier field is the ontology element type corresponding to the entry, including four categories: ontology class, ontology attributes, ontology relationships, and ontology instances. The structural description information includes the input parameter structure, output parameter structure, and logical hierarchy structure information defined within the entry.

[0029] The system extracts type identifiers and structural descriptions for each item. During extraction, the information is standardized and formatted, converting structural descriptions of different formats into a pre-defined JSON structured format. Extraction of a single piece of information is relatively quick. After extraction, the system associates the extracted type identifiers and structural descriptions with the corresponding unique identifier execution method attribute, establishing a stable mapping relationship. This mapping relationship is stored in an in-memory database, resulting in low query response latency. Simultaneously, the system performs compliance checks on all items, removing invalid items that do not contain valid execution method attribute type identifiers and structural descriptions. The invalid item removal rate is no less than 100%, ensuring that all items participating in the processing flow have complete core information and preventing invalid content from interfering with the specification conversion code generation process.

[0030] In one embodiment, step S2, which converts the ontology logical description or ontology action description of the corresponding entry into an executable specification containing specification structure element definitions based on the classification result, and corrects the definition content of the executable specification using the type identifier and the structure description information, includes: S21, Extraction of core content from the ontology description of category items; S22, perform attribute-corresponding specification conversion template matching; S23, Ontology description to initial executable specification conversion; S24, Executable specification definition completeness and integrity verification.

[0031] In the specific implementation process, the system, deployed on the code generation service node of the industrial internet platform, reads all entries after grouping and categorizing in step S1. It then reads the complete content of each entry, group by group, from the corresponding group storage area in memory, extracting the core content of the ontology logic description or ontology action description for each entry. For example, for the equipment temperature threshold judgment entry in the industrial digital twin scenario, the extracted core ontology logic description is the full-process logic rule for real-time temperature acquisition, temperature threshold comparison, alarm status output, etc. For the prompt word execution entry for equipment fault diagnosis, the extracted core ontology action description is the task requirement for generating fault cause analysis and handling suggestions based on equipment operating parameters. For the interface call execution entry for equipment data acquisition, the extracted core ontology action description is the execution requirement for interface call cycle request parameter response data processing. During the extraction process, the system synchronously retrieves the mapping relationship corresponding to the entry, associating the execution method attribute type identifier structure description information of the entry to ensure that the extracted core content is bound one-to-one with the entry attribute information, without mismatches or omissions.

[0032] The system matches the corresponding specification conversion template based on the execution method attribute bound to each entry. The system has a built-in standardized specification conversion template library, deployed on the local storage of the service nodes. The library contains three types of standardized templates, corresponding to the three execution method attributes: code execution prompts, interface calls, and execution methods. Each template has a pre-defined fixed specification structure framework, including three core fields: input definition, output definition, and processing logic definition, as well as reserved extended definition fields. The system performs precise template matching based on the entry's execution method attribute. For example, an entry with the execution method attribute of code execution (equipment temperature threshold judgment) is matched with a function specification conversion template; an entry with the execution method attribute of prompts (equipment fault diagnosis) is matched with a prompts specification conversion template; and an entry with the execution method attribute of interface calls (equipment data acquisition) is matched with an interface specification conversion template. After completing the template matching, the system loads the template into memory.

[0033] The system, following the matched specification conversion template, converts the extracted core content of ontology logic description or ontology action description into an initial executable specification, clearly defining the input, output, and processing logic of the initial executable specification. The system employs a semantic mapping conversion algorithm to map the natural language logic within the ontology description segment by segment to standardized content corresponding to the fields in the template. For code execution-type equipment temperature threshold judgment entries, the converted initial executable specification explicitly defines two numerical parameters as the equipment's real-time temperature and upper temperature threshold, and two Boolean parameters as the alarm status and logical execution result. The processing logic is defined as follows: when the equipment's real-time temperature is greater than the upper temperature threshold, the alarm status is assigned a value of 1, and the logical execution result is assigned a value of true; otherwise, the alarm status is assigned a value of 0, and the logical execution result is assigned a value of false. For prompt word execution-type equipment fault diagnosis entries, the converted initial executable specification explicitly defines three text parameters as the equipment operating parameters, equipment model, and fault phenomenon, and two structured text parameters as the fault cause analysis and handling suggestions. The processing logic is defined as generating fault analysis content conforming to industrial equipment operation and maintenance specifications based on the input parameters. The interface call execution class defines the device data acquisition entry, the converted initial executable specification, and the inputs are clearly defined as the device's unique identifier, a list of acquisition parameters, and the acquisition period. The outputs are clearly defined as the real-time values ​​of the acquisition parameters, the acquisition timestamp, and the interface call status. The processing logic is clearly defined as sending data acquisition requests to the corresponding device at fixed intervals, parsing the response data, and outputting standardized results. After the system completes the conversion of a single entry, it binds and stores the generated initial executable specification with the entry's unique identifier to ensure that the specification is traceable to the original ontology description.

[0034] The system retrieves the type identifier and structural description information corresponding to each entry, supplements and improves the definition of the initial executable specification, corrects content that does not meet the standard format requirements, generates a standard executable specification, and simultaneously performs integrity verification on the standard executable specification. Based on the type identifier, the system supplements the initial executable specification with corresponding extended definition content. For entries with the type identifier being an ontology class, it supplements the definition of class instantiation rules and inheritance relationships; for entries with the type identifier being an ontology attribute, it supplements the definition of parameter value ranges and verification rules; for entries with the type identifier being an ontology relationship, it supplements the definition of dependencies and execution order between entries; and for entries with the type identifier being an ontology instance, it supplements the definition of default values ​​for instantiation parameters and execution constraints. Based on the structural description information, the system corrects the parameter structure of the input and output definitions within the initial executable specification, unifies the naming conventions for parameter hierarchy data types, and ensures that the specification structure conforms to the preset standardization requirements. For the equipment temperature threshold judgment entry, based on the parameter range definition in the structural description information, the system supplements the input definition of the initial executable specification with verification rules for the effective range of temperature parameters; based on the characteristics of the type identifier being an ontology attribute, it supplements the parameter non-empty verification rules and improves the abnormal input handling content within the processing logic. After the system completes the specification refinement, it initiates an integrity check. The check includes verifying the completeness of the three core fields: input definition, output definition, and processing logic definition; whether the specification content is semantically consistent with the original ontology description; and whether the parameter structure conforms to the specifications. For specifications that fail the check, the system automatically marks the exception type and location, reverts to the core content extraction step, and re-executes the transformation operation. For standard executable specifications that pass the check, the system writes them to persistent storage, providing standardized input for the code generation stage and ensuring that all output executable specifications have complete definition content and lossless ontology semantic mapping.

[0035] In one embodiment, step S3, which involves inputting the executable specification into a preset template engine for rendering to generate a source code file containing executable code and descriptive text, includes: S31, executable specifications are matched and bound to code generation templates; S32, template engine rendering and initial source code file generation; S33, Supplement to code description text and correction of formatting specifications; S34, Source code executability verification and standard file output.

[0036] In the specific implementation process, the system reads the standard executable specifications generated and stored in persistent storage from the preceding steps, retrieves the complete content of each specification, and synchronously associates the unique identifier of the corresponding entry with the execution method attribute. The system has a built-in standardized code generation template library, deployed in the local storage of the service nodes. This library contains three core code generation templates, corresponding to three types of execution method attributes: code execution prompts, execution interface calls, and execution methods. Each template has a pre-defined fixed code structure framework, reserved spaces for input definitions, output definitions, processing logic definitions, and areas for inserting explanatory text. Based on the execution method attributes bound to the executable specifications, the system completes the precise matching and binding of specifications with corresponding code generation templates. For example, a device temperature threshold judgment specification (executed by code) matches a functional code generation template; a device fault diagnosis specification (executed by code prompts) matches a large model prompt call code generation template; and a device data acquisition specification (executed by code interface calls) matches a REST interface call code generation template. After completing the matching and binding, the system loads the templates into memory.

[0037] The system sequentially fills the input, output, and processing logic definitions within the executable specification into the corresponding reserved positions of the matched code generation template, and then starts the preset template engine to perform the rendering operation. The template engine employs a structured content mapping mechanism, filling the function parameters or interface request parameters of the template with the parameter names, data types, and constraints defined in the input; filling the function return values ​​or interface response data parsing sections with the parameter names, data types, and structures defined in the output; and filling the function body or interface call logic with the execution rules, conditional judgments, and exception handling content defined in the processing logic. For the code execution specification for device temperature threshold judgment, the template engine fills the two numeric parameters (real-time device temperature and upper limit temperature threshold) defined in the input as two double-type parameters in the Java function; fills the two boolean parameters (the execution result of the alarm status logic) defined in the output as a boolean array returned by the function; and fills the conditional judgment statements of the temperature comparison conditional judgment alarm status assignment content defined in the processing logic into the conditional judgment statements of the function body, generating the initial Java source code file. For the execution specification of prompt words for equipment fault diagnosis, the template engine takes three text parameters—the defined equipment operating parameters set, equipment model, and fault phenomenon—as input parameters for the prompt word constructor. It takes two structured text parameters—the defined fault cause analysis and handling suggestions—as parsing fields for the large model response data. It also takes the prompt word concatenation rules and response data format validation content defined in the processing logic as the prompt word call logic, generating the initial Python source code file. For the execution specification of interface calls for equipment data acquisition, the template engine takes three parameters—the defined equipment unique identifier, collection parameter list, and collection period—as input parameters for the interface request constructor. It takes three parameters—the defined collection parameters, real-time value, collection timestamp, and interface call status—as output parameters for parsing and outputting the interface response data. It also takes the periodic call rules, request sending logic, and response exception handling content defined in the processing logic as the core execution part of the interface call, generating the initial Go source code file. After the system completes the rendering of a single specification, it binds and stores the generated initial source code file with the corresponding unique identifier, ensuring that the code is traceable to the original executable specification and ontology description.

[0038] The system retrieves extended definitions and corresponding type identifier structure descriptions from the executable specification, supplements the initial source code file with corresponding code description text, and simultaneously corrects the code formatting. The code description text includes four parts: function description, parameter description, return value description, and usage notes. The function description describes the core function of the code's underlying logic or action; the parameter description explains the meaning, data type, and value range of each input parameter; the return value description explains the meaning, data type, and structure of each output parameter; and the usage notes explain the code's calling conditions, dependencies, and exception handling requirements. Formatting corrections include three aspects: unified code indentation, unified variable and function naming conventions, and unified comment format. Code indentation uses a fixed number of spaces; variable and function naming uses a unified camelCase or underscore style; and comments use a standardized single-line or multi-line format. The initial Java source code file for equipment temperature threshold judgment is supplemented with the following functional description: It determines whether the real-time temperature of industrial equipment exceeds a preset threshold and outputs an alarm status and logical execution result. The parameters are explained as follows: real-time temperature is the collected current temperature value of the equipment; the upper temperature threshold is the preset safe upper temperature limit of the equipment; the return value is explained as follows: the first element of the array is the alarm status, and the second element is the logical execution result; usage precautions are noted, ensuring the temperature parameters are within a valid range before calling the function; code indentation is now fixed at a fixed number of spaces; variable naming uses lower camelCase; function naming uses upper camelCase; and comments use the JavaDoc multi-line comment format. The initial Python source code file for equipment fault diagnosis is supplemented with the following functional description: It generates fault cause analysis and handling suggestions that conform to industrial operation and maintenance standards based on relevant equipment operating parameters. The parameters are explained as follows: the source and filling requirements of each input parameter are explained; the return value is explained as follows: the structure and purpose of the output content are explained; usage precautions are noted, requiring the corresponding large model calling credentials and network environment to run the code; code indentation is now fixed at a fixed number of spaces; variable and function naming uses the snake naming convention; and comments use the Python standard multi-line docstring format. After the system completes the supplementary explanatory text and formatting corrections, it generates the corrected source code file.

[0039] The system performs executable verification on the corrected source code files. The verification includes three parts: syntax error checking, logic breakpoint checking, and parameter type matching checking. Syntax error checking calls the compiler frontend of the corresponding programming language to scan the code's syntax structure and check for syntax and format errors. Logic breakpoint checking simulates the core logic path of the code execution to check for missing logic or omitted conditional statements. Parameter type matching checking simulates input parameters that conform to the definitions to verify the matching of parameter types with the code logic. For the corrected Java source code file for the device temperature threshold judgment, the system calls the Java compiler frontend to check the syntax, confirming there are no syntax errors such as missing semicolons or mismatched symbols. It simulates a real-time device temperature of 30 degrees Celsius and a temperature threshold upper limit of 35 degrees Celsius to verify the completeness of the code logic execution path and that the return value is a boolean array with correct element values. It then simulates a real-time device temperature of 40 degrees Celsius and a temperature threshold upper limit of 35 degrees Celsius to verify the correctness of the alarm status and the assignment of the logic execution result. For the corrected Python source code files used in equipment fault diagnosis, the system calls the Python interpreter's syntax checking module to scan the code, confirming the absence of syntax and indentation errors. It simulates input matching the defined set of device operating parameters, device model, and fault symptoms to verify the integrity of the concatenated prompts and the match between the response data parsing rules and the output definition. For source code files that fail validation, the system automatically marks the exception type and location, reverts to the template engine rendering step, and re-executes the operation. For source code files that pass validation, they are identified as standard source code files, written to persistent storage, and synchronously associated with a unique executable specification identifier.

[0040] In one embodiment, step S4, which generates the unit test file corresponding to the source code file based on the definition of the executable specification, includes: S41, core specification definition and code execution entry point extraction; S42, Unit test framework setup and initial test case generation; S43, complete the logic coverage of full-scale execution scenario tests; S44, Test file coverage verification and standard file output.

[0041] In the specific implementation process, the system reads the standard source code file generated in the preceding steps, synchronously calls the standard executable specification bound to the source code file, and completely extracts the fixed input definitions, output definitions, and processing logic definitions within the specification. The system scans the complete content of the source code file line by line, locates the execution entry point of the code, captures the function name, parameter list, return value structure, and exception throwing rules of the code, and synchronously records the code's dependencies and runtime environment requirements. For the Java programming language source code file corresponding to the equipment temperature threshold judgment in the industrial digital twin scenario, the system locates the execution entry point as the core function for temperature threshold judgment, captures the parameter list as two double-precision floating-point type input parameters, the return value structure as a boolean type array, and the exception throwing rule as a parameter validation exception thrown when the input parameters exceed the valid range. For the Python programming language source code file corresponding to the equipment fault diagnosis in the industrial digital twin scenario, the system locates the execution entry point as the core function for fault diagnosis prompt word invocation and result parsing, captures the parameter list as three string type input parameters, the return value structure as a dictionary structure containing two string fields, and the dependency is a third-party library called by the large model.

[0042] The system matches the corresponding standardized unit testing framework based on the programming language type of the source code file. Java source code files are matched with the JUnit testing framework, Python source code files with the Pytest testing framework, and Go source code files with the GoTest testing framework. Based on the matched testing framework, the system builds the basic unit testing framework corresponding to the source code file, generating the basic structure of test classes or test functions, and reserving space for test case filling and assertion rule definition areas. Based on the extracted input and output definitions, the system generates initial test cases. These initial test cases correspond to the normal execution path of the source code, with input parameters being standard valid values ​​conforming to the input definitions, and assertion rules requiring the output results to match the standard requirements of the output definitions. For example, for a Java source code file used for judging equipment temperature thresholds in an industrial digital twin scenario, the system builds a JUnit5 unit testing framework, generates the corresponding test class, and the initial test case inputs a real-time equipment temperature of 30 degrees Celsius and a temperature threshold upper limit of 35 degrees Celsius. The assertion rule is that in the returned boolean array, the alarm status is false, and the logical execution result is true. The Python programming language source code file corresponds to the equipment fault diagnosis in the industrial digital twin scenario. The system builds the Pytest test framework, generates the corresponding test functions, and the initial test case inputs conform to the defined set of equipment operating parameters, equipment model and fault phenomenon content. The assertion rule is that in the returned dictionary structure, the fault cause analysis and handling suggestion fields are not empty and the format conforms to the preset requirements.

[0043] Based on the extracted processing logic definitions, the system disassembles the full execution branches of the source code, identifying boundary input scenarios, abnormal input scenarios, and abnormal handling scenarios. For each scenario, corresponding supplementary test cases are generated to complete the coverage of the test logic. Boundary input scenarios correspond to input parameters at critical values ​​defined in the input definition; abnormal input scenarios correspond to input parameters exceeding the valid range or not conforming to format requirements; and abnormal handling scenarios correspond to the abnormal handling logic branches in the source code. For the Java programming language source code file corresponding to the temperature threshold judgment of equipment in the industrial digital twin scenario, the system's disassembled execution branches include boundary scenarios where the temperature equals the upper limit of the threshold, abnormal input scenarios where the temperature is below the lower limit of the valid range, abnormal input scenarios where the temperature is above the upper limit of the valid range, and abnormal input scenarios where the input parameter is empty. The system generates corresponding supplementary test cases for each scenario. In the scenario where the temperature equals the upper limit of the threshold, the input device's real-time temperature is the same as the upper limit of the temperature threshold, the assertion rule is that the alarm status is false, and the logic execution result is true. In the scenario where the temperature is below the lower limit of the valid range, the input temperature value exceeds the valid range, the assertion rule is that the code throws the corresponding parameter verification exception, and the logic execution result is false. The system extracts Go programming language source code files for the interface calls used for device data acquisition within the industrial digital twin scenario. The execution branches include exceptions such as interface call timeouts, incorrect data format returns, and invalid device unique identifiers. For each scenario, the system generates corresponding supplementary test cases to complete the test logic coverage for all interface call scenarios. After generating all supplementary test cases, the system populates all test cases into the corresponding positions in the test framework, refines the assertion rules and execution order of the test cases, and generates a complete initial unit test file.

[0044] The system performs coverage verification on the generated initial unit test files. The verification process scans all lines of code and execution branches in the source code, counting the number of lines of code and execution branches that the unit test files can cover. Simultaneously, the system verifies the syntax compliance of the test cases by calling the syntax checking module for the corresponding programming language, scanning the syntax structure of the test files, and checking for syntax errors and formatting issues. The system also simultaneously verifies whether the assertion rules of the test cases match the output definitions of the source code, ensuring that the assertion rules of each test case completely match the expected output of the corresponding scenario. For the Java programming language unit test files corresponding to the equipment temperature threshold judgment in the industrial digital twin scenario, the system verifies the code line coverage of the test cases, confirming that all conditional judgment branches and exception handling branches have corresponding test case coverage, verifying that the syntax of the test cases conforms to the Java syntax specification and JUnit5 framework requirements, and verifying that the assertion rules of each test case completely match the expected output of the corresponding scenario. For unit test files that fail verification, the system automatically marks the uncovered lines of code and execution branches, reverting to the test case generation step to supplement the corresponding test logic. For unit test files that pass verification, they are identified as standard unit test files and written to persistent storage. They are then synchronously associated with the unique identifier of the corresponding source code file and the executable specification identifier, providing complete test support for the organization of all files and the output of the code package.

[0045] In one embodiment, step S5, which involves organizing the source code files and unit test files according to a preset directory structure and outputting an executable code package after passing syntax compliance verification, includes: S51, complete collection of source code and unit test files; S52, files are organized hierarchically according to a preset directory structure; S53, full file syntax compliance verification item by item; S54 provides complete executable code package encapsulation and standardized output.

[0046] In the specific implementation process, the system reads the standard source code files and standard unit test files generated in the preceding steps and stored separately in different functional partitions of persistent storage. Simultaneously, it retrieves the unique identifiers and executable specification identifiers associated with these two types of files to ensure that each source code file is accurately bound to its corresponding unit test file, avoiding file mismatches. The system then reads the bound file pairs in batches from their respective functional partitions into a temporary aggregation area in memory. This temporary aggregation area uses a key-value pair storage structure, where the key is the unique identifier of the entry, and the value is a set of files containing the corresponding source code file and unit test file, ensuring the orderliness and traceability of the aggregation process.

[0047] The system retrieves preset directory structure rules for engineering projects. These rules are deployed in local configuration files on service nodes, clearly defining the directory hierarchy for different programming language projects and the storage paths and naming conventions for different file types. The directory hierarchy for Java programming language projects includes a main source code directory, a source code test directory, and a dependency configuration file directory. The main source code directory is divided into subdirectories based on the business module to which each entry belongs. These subdirectories store the corresponding standard source code files, with naming conventions associated with the entry's unique identifier. The source code test directory is divided into subdirectories based on the same business module, storing the corresponding standard unit test files, with naming conventions adding a test identifier suffix to the source code file names. The directory hierarchy for Python programming language projects includes a source code package directory, a test package directory, and a dependency management file directory. Directory division and naming conventions follow the general requirements for Python engineering projects and are associated with the entry's unique identifier. Following the preset directory structure rules, the system creates the corresponding directory hierarchy in a temporary build area in memory. File pairs within this temporary aggregation area are then moved one by one to the subdirectories of the corresponding business modules, completing the hierarchical organization of all files.

[0048] The system performs a piece-by-piece syntax compliance check on all files in a hierarchically organized manner. The check process calls the syntax checking module for the corresponding programming language, scanning the entire content of each file to identify syntax errors, formatting errors, and symbol mismatches. Java files call the syntax checking function of the Java compiler frontend, Python files call the syntax checking module of the Python interpreter, and Go files call Go's static syntax analysis tool. The system simultaneously checks whether the file naming conventions and storage paths conform to the preset project directory structure rules, ensuring that the file organization fully meets the requirements. For files that fail the check, the system automatically marks the exception type and location, reverts to the corresponding file generation step, and re-executes the operation. For all files that pass the check, the system temporarily builds a complete directory structure within a designated area and copies it to a temporary packaging area for persistent storage.

[0049] The system performs an integrity check on the complete directory structure within the temporary packaging area, confirming that all required files exist and that no files are missing or corrupted. Simultaneously, the system generates a corresponding documentation package. This documentation includes four parts: the business purpose of the code package, a list of ontology entries, dependency environment requirements, and deployment steps. The business purpose describes the core functionality of the industrial digital twin scenario corresponding to the code package. The ontology entry list lists the unique identifiers of all entries and their corresponding business functions. The dependency environment requirements list the programming language versions, third-party library versions, and hardware configuration requirements required for the code package to run. The deployment steps list the complete process of decompressing, compiling, testing, and deploying the code package. The system adds the documentation to the root directory of the temporary packaging area, completing the code package content. The system uses a standardized compression format to package all content within the temporary packaging area into a complete executable code package. The compression format is determined according to user needs or preset rules, supporting mainstream compression formats such as ZIP, TAR, and GZ. The system will write the generated complete executable code package to the code package output partition of persistent storage, and synchronously generate a unique identifier and metadata information for the code package. The metadata information includes the generation time of the code package, the number of ontology entries, and the size of the compressed format file corresponding to the business scenario, providing support for the management and use of the code package.

[0050] Reference Figure 2 Here is a structural block diagram of an ontology logic and action code generation system based on an executable specification according to an embodiment of the present invention, comprising: The data receiving and parsing module is used to receive the ontology logical description file and the ontology action description file, traverse all entries in the two types of files, read the execution method attributes corresponding to each entry, classify all entries according to the execution method attributes, and simultaneously extract the type identifier and structural description information of each entry. The specification conversion module is used to convert the ontology logic description or ontology action description corresponding to each entry into an executable specification corresponding to the execution method attribute according to the classification results, and simultaneously combine the type identifier and structural description information of the corresponding entry to improve the definition of the executable specification. The code generation module is used to input the executable specification into the preset template engine, and the template engine renders and generates the source code file corresponding to the executable specification. The test generation module is used to generate unit test files corresponding to the source code files based on the input definitions, output definitions, and processing logic definitions of the executable specification. The file verification and output module is used to organize source code files and unit test files according to a preset directory structure, perform syntax compliance verification on all files, and output a complete executable code package after the verification is passed.

[0051] For the specific implementation of each module in the above system example, please refer to the above method embodiments, which will not be repeated here.

[0052] In summary, this invention constructs a fully automated closed-loop processing system from ontology description to engineered executable code, achieving lossless conversion and standardized output of ontology logic and action semantics into deployable program code. It performs full structured parsing of ontology logic description files and ontology action description files, traversing all entries within the files to read and group execution method attributes, and simultaneously extracting core type identifiers and structural description information of each entry. Using execution method attributes as the matching basis, different categories of ontology description content are converted into corresponding standardized executable specifications. The specification definition is refined by combining the associated type identifiers and structural description information of each entry, establishing a bridge between ontology semantics and program code, avoiding the semantic disconnect between ontology knowledge and implementation code. The standardized executable specifications are input into a preset template engine, and automated rendering is completed through precise matching between the specifications and code generation templates, generating source code files containing complete execution logic. Simultaneously, code description text is added, code format is standardized, and after executability verification, a standard source code file is output, achieving precise implementation from ontology logic to executable code. Based on the core definitions of the executable specification and the execution entry point of the source code, a matching unit test framework is built to generate test cases covering all execution scenarios. After completing test coverage verification, standard unit test files are output, providing supporting verification for the quality and execution stability of the generated code. The generated source code files and unit test files are hierarchically organized according to the pre-defined engineering directory structure. Each file undergoes a syntax compliance check. After passing the check, a complete executable code package is generated, ultimately achieving fully automated processing from ontology description to deployable engineering artifacts.

[0053] An embodiment of the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. It is understood that the computer-readable storage medium in this embodiment can be a volatile readable storage medium or a non-volatile readable storage medium.

[0054] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the present invention and embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual-rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM, etc.

[0055] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0056] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for generating ontology logic and action code based on executable specifications, characterized in that, Includes the following steps: The entry information in the obtained ontology logic description file and ontology action description file is parsed, and the classification results are obtained after classifying the execution method attributes of each entry information. The type identifier and structural description information of each entry are then extracted. Based on the classification results, the ontology logic description or ontology action description of the corresponding entry is converted into an executable specification containing specification structure element definitions, and the definition content of the executable specification is corrected using the type identifier and the structure description information. The executable specification is input into a preset template engine for rendering, generating a source code file containing executable code and explanatory text; Generate unit test files corresponding to the source code files based on the definition of the executable specification; The source code files and unit test files are organized according to a preset directory structure, and an executable code package is output after passing the syntax compliance check.

2. The ontology logic and action code generation method based on executable specifications according to claim 1, characterized in that, The steps of classifying entries based on their execution method attributes to obtain classification results, and extracting the type identifier and structural description information of each entry, include: Traverse each independent entry in the file, separated by entry delimiters, and extract the execution method attribute field, type identifier field, and structure description information field of the entry declaration from each entry. If any entry has missing fields, field values ​​that exceed the preset enumeration range, or structure description information that does not conform to the preset syntax format, then the target is marked as an invalid entry and removed from the set of entries to be processed, and only valid entries with complete fields and compliant format are retained. For the items retained after removal, they are grouped and categorized according to the execution method attributes, and the type identifier and structural description information corresponding to each item are extracted. The grouping and categorization are performed based on the value of the execution method attribute field. Items with the same execution method attribute are grouped into the same group set. During the grouping process, the type identifier field and structural description information field in each item are read synchronously. The type identifier field is used to indicate the category of the ontology element corresponding to the entry, and the structure description information field is used to define the structural constraints of the input parameters, output parameters and logical levels involved in the entry. The extracted type identifier and structure description information are stored in a structured data form in association with the original identifier of the entry. Establish a unique identifier for the grouped and categorized entries, and record the mapping relationship between the entries and the corresponding execution method attributes, type identifiers, and structural description information; The unique identifier is a globally unique identifier assigned to each valid entry within the system. The globally unique identifier is used to locate and trace the corresponding entry. The mapping relationship is stored in a mapping relationship table, with the unique identifier as the primary key index. The associated fields include execution method attribute value, type identifier value, serialized content of structural description information, and the group identifier to which the entry belongs.

3. The ontology logic and action code generation method based on executable specifications according to claim 1, characterized in that, The step of modifying the definition of the executable specification using the type identifier and the structure description information includes: Based on the execution method attribute of the entry, match the corresponding specification conversion template to convert the entry's ontology logic description or ontology action description into an initial executable specification; Based on the type identifier and structure description information, the parameter structure, data type or verification method in the initial executable specification are modified to obtain a standard executable specification; Perform an integrity check on the standard executable specification. If the check passes, it becomes the corrected executable specification.

4. The ontology logic and action code generation method based on executable specifications according to claim 3, characterized in that, The step of modifying the parameter structure, data type, or verification rules in the initial executable specification based on the type identifier and structure description information includes: The ontology element category corresponding to the current entry is determined based on the type identifier, and the corresponding extended definition content is supplemented for the initial executable specification based on the ontology element category; Based on the structural description information, the parameter hierarchy, data types, and naming conventions in the initial executable specification are uniformly corrected. The ontology element categories include ontology classes, ontology attributes, ontology relationships, or ontology instances.

5. The ontology logic and action code generation method based on executable specifications according to claim 1, characterized in that, The step of inputting the executable specification into a preset template engine for rendering to generate a source code file containing executable code and descriptive text includes: According to the executable specification, a corresponding preset code generation template is matched. The preset code generation template corresponds one-to-one with the execution method attributes and reserves space for input area, output area and processing logic area. The defined content is filled into the corresponding placeholders of the preset code generation template, and the template engine is driven to render and generate the initial source code file. The initial source code file is supplemented with functional description text corresponding to the processing logic, and the indentation level deviation and line break position deviation that occur during the rendering process are corrected to obtain a standard source code file.

6. The ontology logic and action code generation method based on executable specifications according to claim 1, characterized in that, The step of generating the unit test file corresponding to the source code file based on the definition of the executable specification includes: Extract the structure definition of the executable specification and the execution entry point of the source code file; Based on the structure definition and execution entry point, generate the initial unit test file according to the preset test generation template; Supplement the initial unit test file with test description text and correct any discrepancies between the test logic and the structure definition of the executable specification; Perform test coverage verification on the revised unit test file, and use the file that passes the verification as the unit test file.

7. The ontology logic and action code generation method based on executable specifications according to claim 1, characterized in that, The step of organizing the source code files and unit test files according to a preset directory structure, and outputting an executable code package after passing syntax compliance verification, includes: The generated source code files and unit test files are placed in the corresponding code subdirectories and test subdirectories according to the preset directory structure; Perform syntax compliance checks on all rearranged files; After verification, all the files and directory structure are packaged into an executable code package and output.

8. A system for generating ontology logic and action code based on an executable specification, characterized in that, The ontology logic and action code generation method based on executable specifications according to any one of claims 1-7, wherein the ontology logic and action code generation system based on executable specifications comprises: The data receiving and parsing module is used to receive the ontology logical description file and the ontology action description file, traverse all entries in the two types of files, read the execution method attributes corresponding to each entry, classify all entries according to the execution method attributes, and simultaneously extract the type identifier and structural description information of each entry. The specification conversion module is used to convert the ontology logic description or ontology action description corresponding to each entry into an executable specification corresponding to the execution method attribute according to the classification results, and simultaneously combine the type identifier and structural description information of the corresponding entry to improve the definition of the executable specification. The code generation module is used to input the executable specification into the preset template engine, and the template engine renders and generates the source code file corresponding to the executable specification. The test generation module is used to generate unit test files corresponding to the source code files based on the input definitions, output definitions, and processing logic definitions of the executable specification. The file verification and output module is used to organize source code files and unit test files according to a preset directory structure, perform syntax compliance verification on all files, and output a complete executable code package after the verification is passed.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the ontology logic and action code generation method based on the executable specification as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the ontology logic and action code generation method based on the executable specification as described in any one of claims 1 to 7.

Images