An ontology model-based software development kit generation method and related device

Abstract

The application discloses a software development kit generation method based on an ontology model and related equipment, and relates to the field of computers. The method comprises the following steps: obtaining element metadata corresponding to a target ontology model and capability assets registered under the target ontology model; converting initial naming identifiers in the element metadata and the capability assets into legal program identifiers corresponding to a target programming language according to an identifier conversion rule; generating a first source code set according to attribute constraint data and the legal program identifiers; performing dependency consistency verification on the first source code set; and generating a software development kit based on the first source code set and pre-configured authentication transmission layer code when the dependency consistency verification result indicates that the verification is passed. The application performs dependency consistency verification before generating the software development kit, avoids the collapse of the software development kit in the compilation stage, and supplements runtime service connection capability through the authentication transmission layer code, thereby reducing the business integration threshold.

Description

Technical Field

[0001] This invention relates to the field of computers, and in particular to a method and related equipment for generating software development kits based on ontology models. Background Technology

[0002] In the fields of software engineering and knowledge graphs, an ontology model is a semantic data model used to describe business domain concepts and their complex relationships. To facilitate client applications in quickly accessing and calling the data and business capabilities in the ontology model, it is usually necessary to develop a corresponding software development kit (SDK) for the platform.

[0003] In existing technologies, when providing client access capabilities for platforms based on ontology models, basic code template tools are typically used to directly map the conceptual structures and relationships in the ontology model one by one, mechanically converting them into data types and interface declaration code in the target programming language.

[0004] However, because ontology models often have extremely high semantic naming freedom and intricate internal element relationships, this direct mapping mechanism frequently results in numerous syntax rule conflicts and deep structural errors in the generated source code, making the generated code files prone to crashing during the compilation phase. Furthermore, a simple structural mapping mechanism cannot meet the service connectivity requirements of the client runtime; the generated code lacks the ability to independently execute remote calls, ultimately leading to a high business integration threshold when the generated software development kit is implemented in engineering. Summary of the Invention

[0005] To address the aforementioned technical problems and shortcomings, the purpose of this invention is to provide a software development kit (SDK) generation method based on an ontology model. This method can perform dependency consistency checks before generating the SSD, preventing the SSD from crashing during the compilation phase. Furthermore, it supplements runtime service connectivity capabilities through authentication transport layer code, thereby lowering the threshold for business integration.

[0006] To achieve the above objectives, in a first aspect, the present invention provides a method for generating software development kits based on an ontology model, comprising:

[0007] Obtain the element metadata corresponding to the target ontology model, as well as the capability assets registered under the target ontology model. The element metadata includes concept type definitions, relation type definitions, event type definitions, and corresponding custom attribute constraint data. The capability assets include preset function definitions, skill definitions, and input and output parameter data declared by the function definitions and skill definitions respectively.

[0008] The initial naming identifiers in the element metadata and capability assets are converted into legal program identifiers corresponding to the target programming language according to the preset identifier conversion rules.

[0009] Based on the attribute constraint data and the legal program identifier, a first source code set corresponding to the target programming language is generated. The first source code set includes object accessor code, relation accessor code, event accessor code, and callable method code.

[0010] Perform dependency consistency checks on the first source code set and obtain the dependency consistency check results;

[0011] When the consistency check result indicates that the check has passed, a software development kit is generated based on the first source code set and the pre-configured authentication transport layer code.

[0012] This invention, after generating a first source code set based on the element metadata and capability assets of the target ontology model and before generating a software development kit (SDK), sets up a dependency consistency verification step. This step verifies whether the program elements referenced in the first source code set have corresponding declarations. The SSD is only generated when the dependency consistency verification result indicates that the verification has passed. This allows for the detection of deep structural errors in the first source code set that cannot be resolved before encapsulation, preventing the SSD from crashing during the compilation stage due to the high degree of semantic naming freedom and complex internal element relationships in the target ontology model. Simultaneously, this invention converts the initial naming identifiers into legal program identifiers corresponding to the target programming language according to identifier conversion rules, reducing syntax conflicts caused by initial naming identifiers not conforming to the target programming language's syntax rules. Furthermore, this invention generates the SSD based on the first source code set and pre-configured authentication and transport layer code, supplementing the first source code set, which only completes the mapping of the target ontology model's structure and capabilities, with runtime identity authentication and network transmission capabilities. This enables the SSD to independently execute remote calls, thereby lowering the business integration threshold when client applications access the target ontology model platform.

[0013] In a second aspect, the present invention provides an electronic device comprising: a memory and one or more processors; the memory being coupled to the one or more processors, the memory being used to store computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the electronic device to perform the methods described in the first aspect and any possible implementation thereof.

[0014] Thirdly, the present invention provides a computer-readable storage medium storing computer instructions that, when executed on an electronic device, cause the electronic device to perform the methods described in the first aspect and any possible implementation thereof.

[0015] Fourthly, the present invention provides a computer program product including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect and any possible implementation thereof.

[0016] Understandably, the electronic device provided in the second aspect, the storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are all used to execute the method provided by this invention. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a method for generating a software development kit based on an ontology model according to an embodiment of the present invention.

[0018] Figure 2 This is a technical path diagram of a software development toolkit generation method according to an embodiment of the present invention;

[0019] Figure 3 This is a schematic diagram of the electronic device hardware architecture of a software development kit generation device according to an embodiment of the present invention. Detailed Implementation

[0020] The terminology used in the following embodiments of the present invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the specification and appended claims of the present invention, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in the present invention refers to any or all possible combinations comprising one or more of the listed items.

[0021] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments of the present invention, unless otherwise stated, "multiple" means two or more. The embodiments of the present invention will now be described in detail.

[0022] This embodiment provides a method for generating software development kits (SDKs) based on an ontology model. This method automatically transforms the business domain knowledge and capabilities described in the ontology model into a SSD that can be directly accessed and invoked by client applications, thereby reducing the engineering threshold for client applications integrating ontology model platforms.

[0023] Before describing the method of this embodiment, we first define the ontology model. In this embodiment, the ontology model is a semantic data model used to describe concepts in a business domain and the relationships between concepts. The ontology model can formally record the types of entities in the business domain, the ways in which entities are related, and the attributes that entities possess, thereby providing a unified semantic data foundation for upper-layer business systems. In this embodiment, the ontology model currently selected as the generation object is referred to as the target ontology model.

[0024] This method can be applied to software development kit (SDK) generation devices (hereinafter referred to as "generation devices"). The generation device can be a server or a computer device with data reading capabilities, character processing capabilities, and a code compilation environment. The generation device pre-deploys metadata reading components, identifier conversion components, source code generation components, dependency verification components, and packaging components. These components exchange intermediate processing results through internal data channels, thereby sequentially completing the processing flow from element metadata reading to SSD output.

[0025] The following is combined with Figure 1 The method for generating a software development kit based on an ontology model in this embodiment is specifically described, including steps S101 to S105:

[0026] S101, obtain the element metadata corresponding to the target ontology model, as well as the capability assets registered under the target ontology model.

[0027] Element metadata refers to the metadata used to describe the structural composition of the target ontology model. Element metadata includes concept type definitions, relation type definitions, event type definitions, and the corresponding attribute constraint data for each concept type definition, relation type definition, and event type definition. Concept type definitions describe the types of entities in the business domain, such as customers, orders, and equipment. Relationship type definitions describe the association between concept type definitions, such as the attribution association between customers and orders. Event type definitions describe the types of state changes that occur in the business domain, such as order status changes. Attribute constraint data describes the attributes contained in each concept type definition, relation type definition, and event type definition, as well as their corresponding constraints. Attribute constraints include the data type of the attribute, whether the attribute is required, the range of values ​​for the attribute, and the upper and lower limits on the number of attributes.

[0028] Capability assets refer to a collection of business capabilities registered under the target ontology model that can perform operations on the data within the target ontology model. Capability assets include pre-defined function definitions, skill definitions, and the input / output parameter data declared by each function and skill definition. Function definitions describe business logic units that can be invoked externally. Skill definitions describe composite business capabilities composed of one or more function definitions. Input / output parameter data describes the input parameters that a function or skill definition needs to receive and the output parameters that are returned when it is invoked; this data includes parameter names, parameter data types, and parameter order.

[0029] In practice, the generation device connects to the storage system that stores the target ontology model via a pre-defined data interface. The storage system can be a graph database or a metadata repository. The generation device uses the identifier of the target ontology model as a query condition to read the structured feature metadata document from the storage system and parses the feature metadata document into a data structure that the generation device can process internally.

[0030] The generation device also reads the capability asset registry in the storage system, retrieves the capability assets registered under the target ontology model from the capability asset registry, and stores the element metadata and capability assets in the storage space of the generation device for use in subsequent steps.

[0031] S102 converts the initial naming identifiers in the element metadata and capability assets into legal program identifiers corresponding to the target programming language according to the preset identifier conversion rules.

[0032] The initial naming identifier refers to the original name used by element metadata and capability assets in the target ontology model. Because the target ontology model has a high degree of semantic naming freedom, the initial naming identifier may contain Chinese characters, spaces, hyphens, or other characters that the target programming language does not allow for direct use as program identifiers. The initial naming identifier may also begin with a number or be the same as a reserved keyword in the target programming language. If the initial naming identifier is written directly into the source code without processing, it will cause syntax rule conflicts during the compilation phase. Therefore, the initial naming identifier needs to be converted into a legal program identifier.

[0033] The target programming language refers to the programming language to be used by the software development kit (SDK), such as Java, Python, or TypeScript. A valid program identifier is a program identifier that conforms to the syntax rules of the target programming language and can be correctly recognized by the target programming language compiler.

[0034] Identifier conversion rules are a set of processing rules pre-configured in the identifier conversion component.

[0035] In the specific implementation process, the generating device reads each initial naming identifier and performs the following processing on the initial naming identifier in sequence according to the identifier conversion rules.

[0036] First, the generating device identifies characters in the initial naming identifier that do not conform to the target programming language identifier character set requirements, and removes or replaces these non-compliant characters.

[0037] Secondly, the generating device determines whether the first character of the processed identifier meets the requirements of the target programming language for the first character of the identifier. If the first character does not meet the requirements, a prefix character that meets the requirements is added to the beginning of the identifier.

[0038] Then, the generating device compares the processed identifier with the set of reserved keywords of the target programming language. If the processed identifier falls into the set of reserved keywords, the processed identifier is adjusted according to the identifier conversion rules to avoid the reserved keywords.

[0039] Finally, the generating device normalizes the processed identifier according to the naming conventions of the target programming language, obtaining the legal program identifier corresponding to the initial named identifier.

[0040] When the processed identifier conflicts with an already generated legitimate program identifier, the generating device adds a distinguishing suffix according to the identifier conversion rules, so that the legitimate program identifiers are not duplicated.

[0041] The generation device records the mapping relationship between each initial naming identifier and its corresponding legal program identifier in an identifier mapping table, so that it can be referenced when generating source code later.

[0042] S103, based on the attribute constraint data and the legal program identifier, generate the first source code set corresponding to the target programming language.

[0043] The first source code set refers to the collection of source code files written in the target programming language, generated based on the element metadata and capability assets of the target ontology model. The first source code set includes object accessor code, relation accessor code, event accessor code, and callable method code. Object accessor code provides client applications with the ability to read and write data objects corresponding to concept type definitions. Relation accessor code provides client applications with the ability to query and traverse associated data corresponding to relation type definitions. Event accessor code provides client applications with the ability to subscribe to and process events corresponding to event type definitions. Callable method code provides client applications with the ability to invoke function and skill definitions in the capability assets.

[0044] In practice, the source code generation component is pre-configured with code templates corresponding to the target programming language. For each concept type definition, the generation device reads the attribute constraint data corresponding to that concept type definition and retrieves the concept type definition and the legal program identifiers corresponding to each of its attributes from the identifier mapping table.

[0045] The generation device fills the class name and field name positions in the code template with the valid program identifier, determines the program data type of each field according to the data type in the attribute constraint data, and generates the corresponding value validity judgment logic in the code template according to whether the attribute is required and the value range in the attribute constraint data, thereby generating the object accessor code.

[0046] For each relation type definition, the generation device generates relation accessor code for querying and traversing along the association direction, based on the concept type definitions of the two ends connected by the relation type definition and the corresponding legal program identifiers.

[0047] For each event type, the generation device defines the corresponding attribute constraint data and legal program identifiers based on the event type definition, and generates event accessor code for subscribing to events and receiving event data.

[0048] For each function definition and skill definition in the capability asset, the generation device generates callable method code with a defined method name, input parameter list, and return value type, based on the input and output parameter data declared by each function definition and skill definition and the corresponding valid program identifier.

[0049] The generating device organizes the aforementioned object accessor code, relation accessor code, event accessor code, and callable method code into several source code files, thereby obtaining the first source code set.

[0050] S104, perform dependency consistency verification on the first source code set and obtain the dependency consistency verification result.

[0051] Dependency consistency verification refers to checking the reference relationships between and within each source code file in the first source code set to determine whether all referenced program elements in the first source code set have corresponding declarations. The dependency consistency verification result indicates whether the first source code set passes the dependency consistency verification, and includes two possible values: passed and failed.

[0052] Because there are mutual references between the object accessor code, relational accessor code, event accessor code, and callable method code in the first source code set—for example, relational accessor code needs to reference the data types defined by the object accessor code, and callable method code needs to reference the data types corresponding to the input and output parameter data—it is possible that after the first source code set is generated, there may be cases where referenced program elements lack corresponding declarations in the first source code set. If the first source code set is used directly without verification, the software development kit will fail to compile due to unresolved references.

[0053] In the specific implementation process, the generation device first collects the program elements declared in each source code file of the first source code set. The program elements include type names, field names and method names, and then gathers the declared program elements into a declaration set.

[0054] The generation device then scans for references appearing in the first source code set. For each reference, the generation device determines whether the program element pointed to by the reference exists in the declaration set.

[0055] If all program elements referenced in the first source code set exist in the declaration set, then the generating device generates a dependency consistency check result indicating that the check has passed.

[0056] If a reference in the first source code set points to a program element that is not included in the declaration set, the generating device generates a dependency consistency check result indicating that the check failed.

[0057] By performing dependency consistency verification in step S104, deep structural errors such as unresolved references in the first source code set can be detected before the software development kit is generated, thereby preventing the software development kit from crashing during the compilation phase.

[0058] S105, when the consistency check result indicates that the check has passed, a software development kit is generated based on the first source code set and the pre-configured authentication transport layer code.

[0059] The authentication transport layer code refers to a reusable piece of code pre-configured in the generation device to provide client applications with authentication and network transmission capabilities. This code verifies the client application's credentials when it calls object accessor code, relationship accessor code, event accessor code, or callable method code. It then sends the call request through the network channel to the server of the platform hosting the target ontology model and receives the response data from the server. Since the first source code set only maps the structure and capabilities of the target ontology model and does not possess the ability to independently execute remote calls, the authentication transport layer code is needed to supplement the runtime service connectivity capabilities of the first source code set.

[0060] In the specific implementation process, when the generation device determines that the dependency consistency verification result indicates that the verification has passed, the generation device combines the first source code set with the pre-configured authentication transport layer code, so that the object accessor code, relation accessor code, event accessor code and callable method code in the first source code set can complete identity authentication and remote data interaction through the authentication transport layer code when they are invoked.

[0061] Subsequently, the generation device invokes the packaging component to compile and package the combined source code into a software development kit (SDK) according to the packaging specifications corresponding to the target programming language. The SSD can be a software package file conforming to the distribution format of the target programming language. When the dependency consistency check result indicates that the check has failed, the generation device does not perform the SSD generation operation, thereby avoiding the packaging of the first source code set containing structural errors into an SSD.

[0062] On the other hand, when the dependency consistency check result indicates that the check fails, the generation device does not perform the operation of generating a software development kit based on the first source code set and the authentication transport layer code. Instead, it locates the program element in the first source code set that is referenced but lacks a corresponding declaration based on the reference information of the failed check recorded during the dependency consistency check process, and generates check feedback data containing the missing declaration information.

[0063] The generation device generates an anomaly alarm based on the verification feedback data and blocks the current software development kit (SDK) build task. Subsequently, the generation device enters a suspended listening state, waiting for the data repair of the platform where the target ontology model is located. When an update event is detected in the target ontology model corresponding to the missing declaration information's element metadata or capability assets, the generation device obtains the repaired element metadata or capability assets and re-triggers steps S102 to S104 based on the repaired data until the dependency consistency verification result indicates that the verification has passed. Then, step S105 is executed to generate the SSD, thereby avoiding the build system from falling into an infinite loop and preventing the first source code set with unresolved references from being encapsulated as the SSD.

[0064] Through step S105, the generating device obtains a software development kit that can reflect the data and capabilities of the target ontology model and has runtime service connectivity capabilities, thereby reducing the business integration threshold when client applications access the target ontology model platform.

[0065] like Figure 2 As shown, this embodiment employs the above-described method and steps. The generation device first obtains element metadata and capability assets from the target ontology model. Subsequently, the generation device sequentially performs identifier conversion, source code generation, dependency consistency verification, and authentication transport layer code assembly, ultimately producing a software development kit and providing access methods for data access and business capability invocation to client applications such as mobile applications and mini-programs.

[0066] The technical concept of the embodiments of the present invention is mainly reflected in the appendix. Figure 1 The process flow shown consists of two stages.

[0067] Firstly, after generating the first source code set but before generating the software development kit (SDK), a dependency consistency check is implemented. The target ontology model has high semantic naming freedom and complex internal element relationships. Directly mapping the first source code set can easily lead to deep structural errors, such as missing declarations for referenced program elements. The generation device checks the references in the first source code set through dependency consistency checks. Only when the check passes does it proceed to the next stage; if the check fails, the SSD generation operation is not executed. This allows for the detection of unresolved structural errors before encapsulation, preventing the SSD from crashing during the compilation phase.

[0068] Secondly, the software development kit (SDK) is not simply a package of the first source code set, but rather a combination of the first source code set and pre-configured authentication and transport layer code. The first source code set only maps the structure and capabilities of the target ontology model and does not possess the ability to independently execute remote calls. The generation device introduces authentication and transport layer code into the first source code set, supplementing it with runtime authentication and network transmission capabilities. This enables the object accessor code, relation accessor code, event accessor code, and callable method code in the SSD to perform authentication and remote data interaction when invoked.

[0069] By combining the above two steps, the method in this embodiment not only eliminates deep structural errors in the first source code set before generating the software development kit, but also adds runtime service connectivity capabilities to the software development kit, thereby reducing the business integration threshold when client applications access the target ontology model platform.

[0070] The embodiments of the present invention employ the above-described method, and by sequentially executing steps such as acquiring element metadata and capability assets, converting initial naming identifiers to legal program identifiers, generating the first source code set, verifying dependency consistency, and encapsulating the software development kit in the generation device, the following technical effects can be achieved:

[0071] First, by converting the initial naming identifier into a legal program identifier that conforms to the syntax rules of the target programming language according to the preset identifier conversion rules, the naming problems caused by the high semantic naming freedom of the target ontology model, such as illegal characters, starting with numbers, and conflicts with reserved keywords, can be eliminated, thereby reducing the occurrence of syntax rule conflicts in the first source code set during the compilation stage.

[0072] Secondly, by performing dependency consistency checks on the first source code set, deep structural errors such as missing corresponding declarations of referenced program elements can be detected before packaging the software development kit. Furthermore, if the dependency consistency check result indicates that the check has failed, the packaging operation will not be performed, thereby avoiding packaging the first source code set with structural errors into the software development kit and reducing the possibility of the software development kit crashing during the compilation stage.

[0073] Furthermore, by combining the verified first source code set with the pre-configured authentication transport layer code, runtime identity authentication and remote data interaction capabilities are added to the first source code set that has only completed structure and capability mapping, enabling the generated software development kit to independently execute remote calls.

[0074] Therefore, this embodiment can generate a software development kit that reflects the data and capabilities of the target ontology model and has runtime service connectivity capabilities, thereby reducing the business integration threshold when client applications access the target ontology model platform.

[0075] To facilitate understanding of the technical concept of this embodiment, a specific example will be used to illustrate it in the context of an application scenario in the field of smart retail.

[0076] For example, a retail company has established a target ontology model describing retail operational business knowledge on a data platform and wants to provide a software development kit (SDK) written in Java to a mobile application, enabling the mobile application to directly read data from the target ontology model and call the registered business capabilities within it. In this application scenario, the target programming language is Java, and the generating device is a server deployed on the data platform.

[0077] First, the generating device reads the element metadata and capability assets of the target ontology model from the graph database. The element metadata includes three concept type definitions: customer information, orders, and digital goods; relationship type definitions describing the order association between customer information and orders; and event type definitions describing order status changes, each carrying attribute constraint data. Capability assets include function definitions for querying order details and skill definitions for generating intelligent replenishment suggestions.

[0078] Secondly, the generating device converts the initial naming identifier according to the identifier conversion rules. For example, it converts Customer Info containing spaces into the valid program identifier CustomerInfo, converts the 3C Product supplementary prefix character starting with a number into P3CProduct, adjusts the class that is the same as the reserved keyword to classField, and records each mapping relationship in the identifier mapping table.

[0079] Subsequently, the generating device fills the class name and field name positions in the code template with the legal program identifier based on the attribute constraint data and the legal program identifier. It generates the value validity judgment logic based on the order amount value range not being less than 0, thereby generating object accessor code, relation accessor code, event accessor code, and callable method code, which are organized into the first source code set.

[0080] Then, the generation device collects the program elements declared in the first source code set to form a declaration set, and checks one by one whether the program elements referenced by each reference exist in the declaration set. When the Order type name referenced by the relational accessor code can be found in the declaration set, it confirms that the reference can be resolved, and then generates a dependency consistency check result indicating that the check has passed.

[0081] Finally, the generating device combines the first source code set with the authentication transport layer code, enabling each accessor code to complete identity authentication and remote data interaction via the authentication transport layer code when it is invoked. Then, it is packaged into a software development kit according to the Java language packaging specification, so that the mobile application can directly read data and invoke business capabilities after introducing the software development kit.

[0082] In some embodiments, step S104 involves performing dependency consistency verification on the first source code set to obtain a dependency consistency verification result, including steps S1041 to S1044.

[0083] S1041, parse the code text in the first source code set into a set of abstract syntax trees.

[0084] An abstract syntax tree (AST) is a tree-like representation of the code text in a source code file, organized according to the syntax rules of the target programming language. Each node in the AST corresponds to a syntactic component in the code text, including type declarations, field declarations, method declarations, method calls, and type references. The AST set is the collection of ASTs obtained by parsing each source code file in the first source code set.

[0085] In the specific implementation process, the generation device reads each source code file in the first source code set and uses a syntax parser corresponding to the target programming language to perform lexical and syntactic analysis on the code text in the source code file.

[0086] The generation device first segments the character sequence in the code text into lexical units, and then organizes the lexical units into a hierarchical tree structure according to the syntax rules of the target programming language, thereby obtaining the abstract syntax tree corresponding to the source code file.

[0087] The generation device sequentially performs the above parsing process on all source code files in the first source code set, and aggregates the resulting abstract syntax trees into an abstract syntax tree set.

[0088] Compared to directly matching strings in the code text, using an abstract syntax tree can distinguish between declaration and reference positions in the code text, providing a structured processing basis for subsequent extraction of call reference identifiers.

[0089] S1042, traverse each node in the abstract syntax tree set and extract the call reference identifier contained in each node.

[0090] In this context, a node refers to a constituent unit in the abstract syntax tree that corresponds to a specific syntactic component. A call reference identifier is an identifier that appears at a reference location in the source code file and is used to point to the referenced program element; for example, the method name pointed to at a method call, the field name pointed to at a field access point, and the type name pointed to at a type reference.

[0091] In the specific implementation process, the generation device traverses each abstract syntax tree in the abstract syntax tree set according to a preset traversal order, which can be a depth-first traversal order.

[0092] When the generation device traverses each node, it determines whether the node's syntax category belongs to the reference category. Reference categories include method calls, field accesses, and type references. When the node's syntax category belongs to the reference category, the generation device reads the name of the program element pointed to by the node and records that program element name as a call reference identifier.

[0093] The generating device sequentially performs the above judgment and extraction processes on all nodes in the abstract syntax tree set to obtain all call reference identifiers appearing in the first source code set.

[0094] S1043, verify whether the call reference identifier exists in the set of declared identifiers consisting of valid program identifiers, and filter out undeclared reference data that did not match successfully.

[0095] The declaration identifier set refers to the collection of legal program identifiers declared by each source code file in the first source code set. Each legal program identifier in the declaration identifier set corresponds to a declaration location of a program element. Undeclared reference data refers to data consisting of call reference identifiers for which a corresponding declaration location cannot be found in the declaration identifier set.

[0096] In the specific implementation process, the generation device first extracts the nodes belonging to the declaration category from the abstract syntax tree set. The declaration category includes type declarations, field declarations and method declarations, and gathers the legal program identifiers corresponding to the nodes of the declaration category into a declaration identifier set.

[0097] The generating device then checks whether each call reference identifier extracted in step S1042 exists in the declaration identifier set. If the call reference identifier exists in the declaration identifier set, the generating device determines that the call reference identifier is a successful match.

[0098] When a call reference identifier does not exist in the set of declared identifiers, the generating device determines that the call reference identifier has not been matched and records the unmatched call reference identifier in the undeclared reference data.

[0099] The generating device performs the above verification process on all reference identifiers in sequence, thereby filtering out undeclared reference data.

[0100] S1044, Generate dependency consistency check results based on whether undeclared referenced data is empty.

[0101] In the actual implementation process, the generating device determines whether the undeclared reference data is empty.

[0102] When the undeclared reference data is empty, it means that all call reference identifiers appearing in the first source code set can be found in the corresponding declaration position in the declaration identifier set. That is, there is no situation where the reference cannot be resolved in the first source code set, and the generation device generates a dependency consistency check result that has passed the verification.

[0103] When the undeclared reference data is not empty, it indicates that there is a call reference identifier in the first source code set that cannot be found in the declaration identifier set, that is, there is a situation where the reference cannot be resolved in the first source code set. The generation device generates a dependency consistency check result indicating that the check failed, and outputs the undeclared reference data together to locate the specific location where the reference cannot be resolved.

[0104] Through steps S1041 to S1044, the generating device performs structured parsing and verification of the first source code set using an abstract syntax tree, and is able to discover deep structural errors in the first source code set where references cannot be resolved.

[0105] In some embodiments, the step S1044 of generating a dependency consistency verification result based on whether the undeclared reference data is empty also includes steps S10441 to S10444, which are used to further eliminate circular dependencies that may exist in the first source code set on the basis that the undeclared reference data is empty.

[0106] S10441, When the undeclared referenced data is empty, construct a global code dependency directed graph based on the reference relationships between nodes in the abstract syntax tree set.

[0107] In this context, the reference relationship refers to the directional relationship between two program elements when a program element declared in one source code file points to a program element declared in another source code file by calling a reference identifier.

[0108] A global code dependency directed graph is a directed graph that uses source code files in the first source code set as vertices and reference relationships as directed edges, covering all reference relationships in the first source code set.

[0109] In the specific implementation process, the generation device traverses each node in the abstract syntax tree set. For each node of a reference category, it determines the source code file containing that node as the referrer, and determines the source code file containing the referenced program element as the referenced party based on the valid program identifier pointed to by that node. The generation device treats the referrer and the referenced party as vertices in the global code dependency directed graph, and establishes a directed edge from the referrer to the referenced party.

[0110] The generation device performs the above processing on all reference relationships in the first source code set in sequence, thereby constructing a global code dependency directed graph that covers all reference relationships in the first source code set.

[0111] S10442, based on the loop detection algorithm, extracts closed-loop dependency path data from the global code dependency directed graph.

[0112] Among them, the loop detection algorithm refers to the algorithm used to detect whether there is a loop in a directed graph consisting of several directed edges connected end to end. The loop detection algorithm can be a strongly connected component solution algorithm based on depth-first search.

[0113] Closed-loop dependency path data refers to the path data formed by the vertices that constitute a loop in the directed graph of global code dependencies and the directed edges connecting these vertices. Closed-loop dependency path data reflects the circular dependencies that exist in the first source code set.

[0114] Circular dependency refers to a situation where two or more source code files reference each other directly or indirectly through reference relationships, thus forming a reference loop that connects the two files.

[0115] In the specific implementation process, the generating device uses the global code dependency directed graph as input to the loop detection algorithm, runs the loop detection algorithm to traverse the vertices and directed edges in the global code dependency directed graph, and finds loops formed by several directed edges connected end to end.

[0116] When a loop exists in the global code dependency directed graph, the generating device records each vertex that constitutes the loop and the directed edges connecting each vertex in the closed-loop dependency path data.

[0117] When there are no loops in the global code dependency directed graph, the generating device will set the closed-loop dependency path data to empty.

[0118] S10443, when the closed-loop dependency path data is not empty, replace the static type declaration code corresponding to the closed-loop dependency path data in the first source code set with the lazy-loaded proxy interface code to obtain the acyclic source code set that eliminates circular dependencies.

[0119] Among them, static type declaration code refers to the code in the first source code that needs to determine the specific definition of the referenced type during the compilation stage, so as to form a direct dependency relationship between source code files. For example, type declaration code that directly holds an instance of a type declared by another source code file in the form of a field.

[0120] Lazy loading of proxy interface code refers to indirectly referencing the referenced type in the form of a proxy interface. During the compilation phase, it only depends on the proxy interface and does not directly depend on the specific definition of the referenced type. The specific definition of the referenced type is loaded only when it is actually accessed during the runtime phase.

[0121] A circular source code set refers to the set of source code files that no longer have reference cycles, obtained by replacing the static type declaration code that constitutes circular dependencies with lazy-loaded proxy interface code, based on the first source code set.

[0122] In the specific implementation process, when the closed-loop dependency path data is not empty, the generation device locates the static type declaration code that constitutes the reference loop in the first source code set based on the vertices recorded in the closed-loop dependency path data. For each located static type declaration code, the generation device replaces the direct reference to the referenced type in the static type declaration code with a reference to the lazy-loaded proxy interface code. This ensures that the referenced type is no longer directly depended on during the compilation phase, but its specific definition is loaded via the lazy-loaded proxy interface code when it is actually accessed during the runtime phase.

[0123] After the above replacement process, the source code files that constitute the reference loop no longer have direct dependencies during the compilation stage, thus breaking the reference loop. The generation device sequentially performs the above replacement process on the static type declaration code involved in the closed-loop dependency path data, resulting in a loop-free source code set with eliminated circular dependencies.

[0124] On the other hand, when the closed-loop dependency path data is empty, it means that there is no loop in the global code dependency directed graph consisting of several directed edges connected end to end. That is, there is no circular dependency in the first source code set. Therefore, the generation device does not perform the process of replacing the static type declaration code with the lazy-loaded proxy interface code. Instead, it directly treats the first source code set as an acyclic source code set without circular dependencies and enters step S10444 to generate a dependency consistency verification result indicating that the verification has passed based on the acyclic source code set.

[0125] S10444, based on the acyclic source code set, generates a dependency consistency check result indicating that the check has passed.

[0126] Specifically, the generation device first confirms that the acyclic source code set has met two conditions: the first condition is that the undeclared reference data corresponding to the acyclic source code set is empty, that is, all call reference identifiers appearing in the acyclic source code set can be found in the corresponding declaration position in the declaration identifier set; the second condition is that there is no circular dependency in the acyclic source code set, that is, there is no cycle in the global code dependency directed graph formed by the source code files in the acyclic source code set as vertices and the reference pointing relationship as directed edges.

[0127] After confirming that the acyclic source code set meets both of the above conditions, the generation device determines that the acyclic source code set has neither unresolved references nor circular dependencies, and generates a dependency consistency check result with a value of "passed". The acyclic source code set is then associated with this dependency consistency check result and output, so that the subsequent step S105 uses the acyclic source code set as the first source code set that has passed the dependency consistency check for generating the software development kit.

[0128] Through steps S10441 to S10444, the generation device, having confirmed that there are no unresolved references in the first source code set, further detects and eliminates circular dependencies in the first source code set, thereby preventing the software development kit from failing to complete type resolution during the compilation stage due to circular dependencies. It should be noted that the acyclic source code set obtained after the replacement process in step S10443 will serve as the source code used in the subsequent step S105 to generate the software development kit.

[0129] In some application scenarios, considering that the dependency consistency check based on the abstract syntax tree set in step S104 can only identify the dependency relationship directly reflected in the declaration position and reference position in the code text, but cannot identify the dependency relationship recorded in the form of strings or annotations and only parsed into specific program elements at runtime, this embodiment also includes steps S1035 to S1036 in step S103, and steps S1045 to S1048 in step S104, to make implicit dependencies at runtime explicit and eliminate them.

[0130] S1035 assigns a globally unique and immutable semantic token to each concept type definition, relation type definition, event type definition in the element metadata, and each function definition and skill definition in the capability asset. The semantic token is then associated with the initial naming identifier and legal program identifier of the program element and recorded in the semantic token registry.

[0131] Semantic tokens are identifiers that remain unchanged and unique across all versions of the target ontology model. They are independent of legitimate program identifiers, and the semantic tokens remain unchanged even if the legitimate program identifiers change due to name conflict handling.

[0132] When generating the first source code set, the generation device embeds semantic tokens in the corresponding object accessor code, relation accessor code, event accessor code, or callable method code set in a metadata-annotated manner. This provides a basis for addressing referenced program elements according to stable identifiers during runtime, avoiding reliance on volatile string names for addressing.

[0133] S1036, rewrite the implicit dependency code expressed in string form in the first source code set into token-addressed code that is addressed by semantic tokens, and insert boundary probe code at the first parsing position of the implicit dependency code.

[0134] Implicit dependencies, including those determined at runtime such as reflection calls, event routing, serialization alias mapping, plugin scanning, and dynamic proxies, involve relationships between referenced program elements. The generation device replaces the portion of the implicit dependency code that points to the referenced program element via string names with token-addressing code that points to the referenced program element via semantic tokens. Furthermore, it inserts boundary probe code at each location where the semantic token is first resolved to a specific program element. This boundary probe code records the reference relationship between the referrer's source code file and the resolved referenced source code file at runtime, thus reliably capturing implicit dependencies that were originally determined at runtime as computable reference relationships.

[0135] S1045, in the pre-release phase before the release of the software development kit, the first source code set is driven by the replay corpus. The reference pointing relationship obtained by the runtime phase is collected by the boundary probe code, and the runtime dependency edge set is generated.

[0136] The replay corpus refers to the collection of call request samples used to drive the execution of the first source code set, covering the execution paths of various implicit dependency codes. The generation device sequentially inputs each call request sample into the first source code set, driving the actual execution of implicit dependency code. Boundary probe code records and reports reference relationships, which are then aggregated to form a runtime dependency edge set. Since implicit dependencies at runtime can only be resolved after the corresponding code paths are actually executed, the generation device constructs call request samples according to concept type definitions, relation type definitions, event type definitions, function definitions, and skill definitions. This ensures that the replay corpus covers as much of the implicit dependency code as possible, allowing implicit dependencies that would otherwise only be exposed after formal execution to be collected and analyzed during the dependency consistency verification phase.

[0137] S1046, merge the runtime dependency edge set with the global code dependency directed graph constructed in step S10441 to obtain the global runtime dependency directed graph.

[0138] The generation device uses the vertices and directed edges of the global code dependency directed graph as initial content, then traverses each reference relationship in the runtime dependency edge set, adds the source code files of the referrer and the referenced to the vertex and establishes the corresponding directed edges, thereby obtaining the global runtime dependency directed graph, so that the originally invisible implicit dependency relationship is explicitly expressed as directed edges.

[0139] In this embodiment, the global runtime dependency directed graph is a directed graph constructed using source code files in the first source code set as vertices, and directed edges in the global code dependency directed graph and reference relationships in the runtime dependency edge set as directed edges. The global runtime dependency directed graph includes both dependencies directly reflected in the code text and implicit dependencies that are resolved during runtime.

[0140] S1047, the generating device extracts runtime closed-loop dependency path data from the global runtime dependency directed graph based on the loop detection algorithm, and when the runtime closed-loop dependency path data is not empty, calculates the minimum set of feedback edges that need to be removed to make the global runtime dependency directed graph an acyclic directed graph, and marks each directed edge in the minimum set of feedback edges as a high-risk dependency edge.

[0141] The minimum feedback edge set refers to the set of directed edges that, when removed, breaks all cycles while minimizing the number of directed edges removed. Compared to processing all directed edges at once, the minimum feedback edge set minimizes the number of directed edges that need to be rewritten while breaking all runtime cycles. Since runtime cycles caused by implicit dependencies are often exposed and cause class loading failures or initialization deadlocks only during the first call, hot reloading, or when specific parameters are triggered, identifying high-risk dependency edges during the verification phase can transform runtime faults that were originally avoided by manual experience into graph optimization problems that can be automatically solved before release.

[0142] S1048, the generating device replaces the token addressing code corresponding to each high-risk dependency edge in the minimum feedback edge set with the delayed binding gateway code, and re-executes steps S1045 to S1047 for multiple rounds of iteration until the runtime closed-loop dependency path data is empty.

[0143] The delayed binding gateway code does not parse the referenced program elements during the software development kit initialization phase. Instead, it parses and binds the referenced program elements only when they are actually accessed via semantic tokens. This is used to handle implicit dependencies formed by token addressing during runtime, and is different from the delayed loading proxy interface code used in step S10443 to handle direct dependencies formed by static type declaration code.

[0144] The device is generated to locate the token addressing code corresponding to each high-risk dependency edge and replace it with the delayed binding gateway code, breaking the corresponding runtime loop. Since the change in the resolution timing of the implicit dependency code after replacement may lead to new reference relationships, the device is re-driven by the replay corpus, re-collects and merges, and recalculates the runtime closed-loop dependency path data and the minimum feedback edge set. In each round, delayed binding gateway code is injected only for the high-risk dependency edges identified in that round, until the runtime closed-loop dependency path data in a certain round is empty, which is considered convergence. Based on this, a dependency consistency verification result indicating that the verification has passed is generated.

[0145] Through steps S1035 to S1048, the generating device explicitly transforms runtime implicit dependencies that cannot be reflected in the abstract syntax tree set into computable directed edges, and uses the minimum feedback edge set to limit the injection scope of the delayed binding gateway code to a small number of high-risk dependency edges, thereby avoiding class loading failures or initialization deadlocks caused by implicit dependencies during the runtime of the software development kit, while minimizing modifications to the first source code set.

[0146] In some embodiments, step S102, which converts the element metadata and the initial naming identifier in the capability asset into a legal program identifier corresponding to the target programming language according to a preset identifier conversion rule, includes steps S1021 to S1023.

[0147] S1021, Identify the non-standard character set in the initial naming identifier and convert the non-standard character set into the initial pinyin string.

[0148] The non-standard character set refers to the set of characters in the initial naming identifier that do not conform to the character set requirements of the target programming language identifier. The non-standard character set includes Chinese characters, spaces, and hyphens, which cannot be directly used in the target programming language program identifier. The initial pinyin string is the string obtained by converting the non-standard character set into Latin letters according to its pronunciation.

[0149] In the specific implementation process, the generation device reads each character in the initial naming identifier one by one, compares each character with the identifier character set of the target programming language, and identifies characters that do not belong to the identifier character set of the target programming language as non-standard character sets.

[0150] The generating device converts Chinese characters in the non-standard character set into their corresponding Latin letters according to a preset pinyin conversion dictionary. It also removes or replaces spaces or hyphens in the non-standard character set with suitable hyphen characters, thereby converting the non-standard character set into the initial pinyin string.

[0151] The generating device combines the initial pinyin string with the characters in the initial naming identifier that originally met the requirements of the identifier character set in the original order to obtain the candidate legal program identifier.

[0152] S1022, when the initial pinyin string has a name conflict with an existing identifier in the target namespace, obtain the unique identification code of the underlying data allocated by the initial name identifier in the target ontology model.

[0153] The target namespace refers to the naming region in the target programming language used to limit the scope of identifiers and require that the identifiers within it are not duplicated.

[0154] Name conflict refers to a situation where a candidate legitimate program identifier is the same as an identifier that already exists in the target namespace, resulting in duplicate identifiers within the same namespace.

[0155] The unique identifier of the underlying data refers to the unique identifier assigned by the target ontology model to each data entry corresponding to the initial named identifier when storing feature metadata and capability assets. This unique identifier is not repeated within the target ontology model.

[0156] In the specific implementation process, the generation device compares the candidate legitimate program identifiers with the existing identifiers in the target namespace one by one. When a candidate legitimate program identifier is the same as an existing identifier in the target namespace, the generation device determines that there is a name conflict. At this time, the generation device reads the underlying data unique identifier assigned to that data entry in the target ontology model based on the data entry of the initial naming identifier.

[0157] S1023, append the unique identifier of the underlying data to the end of the initial pinyin string according to the preset delimiter to obtain the deduplicated valid program identifier.

[0158] The preset separator refers to a pre-configured connecting character used to connect the initial Pinyin string with the unique identifier of the underlying data and that conforms to the character set requirements of the target programming language identifier. The preset separator can be an underscore character.

[0159] In the specific implementation process, the generating device first performs legalization processing on the unique identification code of the underlying data, so that the processed unique identification code of the underlying data conforms to the character set requirements of the target programming language identifier.

[0160] The generating device then appends a preset separator to the end of the initial pinyin string, and then appends the processed underlying data unique identifier to the end of the preset separator, thus obtaining the concatenated string.

[0161] Since the unique identifiers of the underlying data are not repeated within the target ontology model, the concatenated string is no longer the same as the existing identifiers in the target namespace. The generating device uses the concatenated string as the deduplicated valid program identifier.

[0162] When the initial pinyin string does not conflict with any existing identifier in the target namespace, the generating device directly uses the candidate valid program identifier corresponding to the initial pinyin string as the valid program identifier and does not perform concatenation processing.

[0163] In some other embodiments, step S102 converts the element metadata and the initial naming identifier in the capability asset into a legal program identifier corresponding to the target programming language according to a preset identifier conversion rule, including steps S1024 to S1027.

[0164] S1024, Identify the Chinese character set in the initial naming identifier and convert the Chinese character set into an initial pinyin string that does not contain tone features.

[0165] Here, the Chinese character set refers to the set of characters belonging to Chinese characters in the initial naming identifier. Tone features refer to the tonal information inherent in the pronunciation of Chinese characters. An initial pinyin string without tone features refers to a pinyin string formed by converting the Chinese character set to Latin letters according to pronunciation and without carrying tone information.

[0166] In the specific implementation process, the generation device reads each character in the initial naming identifier one by one, and identifies the characters belonging to Chinese characters as Chinese character sets. According to the preset pinyin conversion dictionary, the generation device converts each Chinese character in the Chinese character set into its corresponding Latin letter pinyin, and does not retain the tone information of Chinese characters during the conversion process, thus obtaining an initial pinyin string without tone features.

[0167] Compared to pinyin strings that carry tone information, initial pinyin strings that do not contain tone features consist only of Latin letters and can meet the character set requirements of the target programming language identifier.

[0168] S1025, when the initial pinyin string without tone features has a name conflict with an existing identifier in the target namespace, obtain the tone number sequence corresponding to the Chinese character set, and concatenate the tone number sequence to the end of the initial pinyin string without tone features to generate the first-level modifier string.

[0169] The tone number sequence refers to a sequence of numbers formed by representing the tone of each Chinese character in the Chinese character set with numbers and then arranging the characters in order. The first-level modifier string is the string obtained by appending the tone number sequence to the end of the initial pinyin string, which does not contain tone features.

[0170] In the specific implementation process, the generating device compares the initial pinyin string, which does not contain tone features, with the existing identifiers in the target namespace one by one.

[0171] When an initial pinyin string that does not contain tone features is identical to an existing identifier in the target namespace, the generating device determines that there is a name conflict. In this case, the generating device reads the tone of each Chinese character in the Chinese character set, represents the tone of each Chinese character as a number, and combines the numbers into a tone number sequence according to the order of the Chinese characters in the initial name identifier.

[0172] The generating device appends a sequence of tone numbers to the end of an initial pinyin string that does not contain tone features, thereby generating a first-level modified string.

[0173] Since two Chinese characters with the same pinyin can be distinguished by their tone numbers, the first-level modifier string can distinguish some name conflicts caused by removing the tone.

[0174] S1026, when there is still a name conflict in the target namespace for the first-level modifier string, extract the hierarchical dependency path data associated with the initial naming identifier in the target ontology model.

[0175] Among them, hierarchical dependency path data refers to the path data formed by the nodes at all levels from the root node to the node where the element metadata or capability asset is located in the hierarchical structure of the target ontology model, which is the element metadata or capability asset corresponding to the initial naming identifier.

[0176] In the specific implementation process, the generation device compares the first-level modifier string with existing identifiers in the target namespace one by one. When the first-level modifier string is the same as an existing identifier in the target namespace, the generation device determines that there is still a name conflict in the first-level modifier string. At this time, the generation device locates the node corresponding to the initial name identifier in the hierarchical structure of the target ontology model, and reads the nodes at each level along the hierarchical structure from the root node to that node, and combines the nodes at each level into hierarchical dependency path data according to the order of traversal.

[0177] Since different element metadata or capability assets occupy different hierarchical positions in the target ontology model, hierarchical dependency path data can reflect the unique hierarchical position of the initial naming identifier in the target ontology model.

[0178] S1027, the target hash feature value is obtained by calculating the hierarchical dependency path data using a preset hash algorithm, and the target hash feature value is appended to the end of the first-level modifier string to obtain the deduplicated legal program identifier.

[0179] The preset hash algorithm refers to a pre-configured algorithm that can map input data of arbitrary length to fixed-length feature values. The target hash feature value refers to the fixed-length feature value obtained after calculating the hierarchical dependency path data using the preset hash algorithm.

[0180] In the specific implementation process, the generation device takes the hierarchical dependency path data as the input of the preset hash algorithm, runs the preset hash algorithm to calculate the hierarchical dependency path data, and obtains the target hash feature value.

[0181] The generating device performs legalization processing on the target hash feature value to make the processed target hash feature value conform to the character set requirements of the target programming language identifier. Then, the processed target hash feature value is appended to the end of the first-level modifier string to obtain the concatenated string.

[0182] Since the target hash feature values ​​obtained by different hierarchical dependent path data after being calculated by the preset hash algorithm are different, the concatenated string is no longer the same as the existing identifier in the target namespace. The generating device uses the concatenated string as the deduplicated legal program identifier.

[0183] Through steps S1024 to S1027, the generating device eliminates name conflicts step by step in a progressive manner: removing the initial pinyin string after removing the tone, concatenating the first-level modification string of the tone number sequence, and concatenating the string of the target hash feature value. This ensures that each legal program identifier is unique while maintaining the readability of the identifier.

[0184] In some embodiments, step S103, which generates a first source code set corresponding to the target programming language based on attribute constraint data and legal program identifiers, includes steps S1031 to S1034.

[0185] S1031 generates object accessor code, relation accessor code, and event accessor code based on attribute constraint data and valid program identifiers.

[0186] In the specific implementation process, the generation device reads the attribute constraint data and the corresponding legal program identifier for each concept type definition, fills the legal program identifier into the class name position and field name position in the code template, determines the program data type of each field according to the data type in the attribute constraint data, and generates value validity judgment logic according to whether the attribute in the attribute constraint data is required and the value range, thereby generating object accessor code.

[0187] For each relation type definition, the generation device generates relation accessor code for querying and traversing along the association direction, based on the concept type definitions of the two ends connected by the relation type definition and the corresponding legal program identifiers.

[0188] For each event type, the generation device defines the corresponding attribute constraint data and legal program identifiers based on the event type definition, and generates event accessor code for subscribing to events and receiving event data.

[0189] S1032, extract the target parameter definition data from the input and output parameter data declared by the function definition and skill definition respectively.

[0190] Among them, the target parameter definition data refers to the parameter definition data extracted from the input and output parameter data declared by the function definition and skill definition, which is required to generate the callable method code. The target parameter definition data includes parameter name, parameter data type, parameter order, and configuration information used to indicate the return method of the output parameter.

[0191] In the specific implementation process, the generation device reads the input and output parameter data declared by each function definition and each skill definition in the capability asset. The generation device extracts the parameter names, parameter data types, and parameter order used to generate callable method code from the input and output parameter data, and further reads the configuration information used to indicate the return mode of the output parameters from the input and output parameter data. The extracted data is then combined into target parameter definition data.

[0192] The generation device associates the target parameter definition data with the corresponding valid program identifiers of function or skill definitions for use in the subsequent generation of callable method code.

[0193] S1033, when the target parameter definition data is configured with a streaming response identifier, generate a callable method code set based on the target parameter definition data and a valid program identifier.

[0194] The streaming response flag is a flag configured in the target parameter definition data to indicate that the output parameters are returned in chunks in a streaming manner. When the output parameter data volume is large or the output parameters need to be generated and returned simultaneously, the output parameters of the function definition or skill definition will be returned in chunks in a streaming manner, and the target parameter definition data is configured with a streaming response flag.

[0195] Callable method code set refers to the collection of callable method code generated for the same function definition or the same skill definition, which includes multiple calling methods. Callable method code set includes regular callable method code and streaming callable method code.

[0196] Regular callable method code refers to callable method code that waits for the output parameters to be generated in a single call before receiving the complete output parameters all at once.

[0197] Chunk transfer protocol is a network transmission protocol that divides output parameters into several data blocks and transmits them sequentially.

[0198] Streaming callable method code refers to callable method code that supports chunked transfer protocols and can receive and process output parameters chunk by chunk as they are returned sequentially in the form of data blocks.

[0199] In the specific implementation process, the generating device reads the configuration information in the target parameter definition data that indicates the return method of the output parameters, and determines whether the target parameter definition data is configured with a streaming response identifier.

[0200] When the target parameter definition data is configured with a streaming response identifier, the generating device generates regular callable method code based on the target parameter definition data and the corresponding valid program identifier. On the other hand, it generates streaming callable method code with chunked transport protocol support based on the target parameter definition data and the corresponding valid program identifier. The regular callable method code and the streaming callable method code are then combined into a callable method code set.

[0201] When the target parameter definition data is not configured with a streaming response identifier, the generation device generates regular callable method code based on the target parameter definition data and the corresponding valid program identifier, and uses the regular callable method code as the callable method code set.

[0202] By distinguishing whether a streaming response flag is configured to generate different callable method code, the generated software development kit can support both one-time return of output parameters and block return of output parameters.

[0203] S1034, the generating device generates a first source code set based on object accessor code, relation accessor code, event accessor code, and callable method code set.

[0204] In the specific implementation process, the generating device organizes the object accessor code, relation accessor code, event accessor code generated in step S1031, and the set of callable method code generated in step S1033 into several source code files.

[0205] The generation device organizes the interrelated object accessor code, relational accessor code, event accessor code, and callable method code sets into their respective source code files according to the source code file organization specifications of the target programming language, and establishes reference relationships between the source code files to obtain the first source code set.

[0206] Since the callable method code set contains both regular callable method code and fluent callable method code, the resulting first source code set supports both the calling method where the client application receives all output parameters at once and the calling method where the client application receives output parameters block by block.

[0207] In some embodiments, after generating a software development kit based on the first source code set and the pre-configured authentication transport layer code in step S105, the method further includes steps S106 to S110 for version synchronization of the software development kit after a change in the target ontology model.

[0208] S106, listen for data change events generated by the target ontology model, and obtain the incremental element metadata of the target ontology model after the change.

[0209] Data change events refer to events that occur when element metadata in the target ontology model is added, modified, or deleted, indicating changes in element metadata. Incremental element metadata refers to the portion of element metadata in the target ontology model that has been added, modified, or deleted after the change, relative to the period before the change.

[0210] In practice, the generation device registers a listener for data change events with the platform hosting the target ontology model through a pre-defined data interface. When element metadata in the target ontology model is added, modified, or deleted, the target ontology model generates a data change event, which the generation device receives.

[0211] The generating device reads the metadata of added, modified, or deleted elements from the storage system of the target ontology model based on the change information carried by the data change event, and uses the read element metadata as incremental element metadata.

[0212] S107, the generating device performs a structural comparison between the incremental element metadata and the historical element metadata used when constructing the first source code set, and generates a corresponding ontology semantic difference map.

[0213] Historical element metadata refers to the element metadata used when constructing the first source code set. Structural comparison refers to the process of comparing incremental element metadata with historical element metadata item by item at the structural level, including concept type definitions, relation type definitions, event type definitions, and their corresponding attribute constraint data. The ontology semantic difference map is a data structure used to record the differences in structural information between incremental element metadata and historical element metadata, including additions, modifications, and deletions.

[0214] In the specific implementation process, the generation device saves the historical element metadata used when constructing the first source code set. The generation device compares each definition in the incremental element metadata with the corresponding definition in the historical element metadata item by item, identifying definitions that have been added, modified, or deleted.

[0215] The generating device organizes the identified additions, modifications, and deletions into an ontology semantic difference map according to the relationships between the definitions.

[0216] S108. Based on the ontology semantic difference map, locate the failed code file in the first source code set where structural drift has occurred.

[0217] Structural drift refers to a situation where the content of the source code files in the first source code set is no longer consistent with the changed incremental element metadata after the historical element metadata on which the source code files are based has changed. Invalid code files refer to source code files in the first source code set that are no longer consistent with the changed incremental element metadata due to structural drift.

[0218] In the specific implementation process, the generation device searches for the source code file corresponding to each changed definition in the correspondence between the previously recorded initial naming identifier and the source code file, based on the various definitions that have been added, modified, or deleted in the ontology semantic difference map.

[0219] The generating device identifies the source code files it finds as failure code files that have experienced structural drift, thereby locating all failure code files in the first source code set.

[0220] S109, based on the incremental element metadata, the target programming language fragment corresponding to the failed code file is regenerated to obtain a partially updated code file.

[0221] Among them, the partially updated code file refers to the source code file obtained after regenerating the target programming language fragment corresponding to the invalid code file based on the incremental element metadata.

[0222] In the specific implementation process, the generating device reads the definition of the change corresponding to the failure code file in the ontology semantic difference map and the corresponding attribute constraint data in the incremental element metadata for each failure code file.

[0223] The generating device converts the changed initial naming identifier into a legal program identifier according to step S102, and then, according to step S103, regenerates the target programming language fragment corresponding to the changed definition in the failed code file based on the attribute constraint data and the legal program identifier, thereby obtaining a partially updated code file.

[0224] Since the generation device only regenerates the target programming language fragments corresponding to the failed code files, and does not regenerate the source code files in the first source code set that have not undergone structural drift, it can reduce the amount of processing required to regenerate the source code.

[0225] S110, replace the invalid code file with a partially updated code file to obtain a second source code set, and use the second source code set as verification input data to re-trigger the dependency consistency verification step to generate the target software development kit after version synchronization.

[0226] The second source code set refers to the collection of source code files obtained by replacing invalid code files with locally updated code files, based on the first source code set. Version synchronization refers to the process of ensuring that the element metadata reflected in the software development kit (SDK) is consistent with the incremental element metadata after changes to the target ontology model. The target SSD refers to the SSD generated after version synchronization, reflecting the changed content of the target ontology model.

[0227] In the specific implementation process, the generating device replaces the corresponding invalid code files in the first source code set with local update code files, while retaining the source code files in the first source code set that have not undergone structural drift, thereby obtaining the second source code set.

[0228] The generation device uses the second source code set as the verification input data, re-triggers the dependency consistency verification step in step S104, performs dependency consistency verification on the second source code set, and obtains the dependency consistency verification result for the second source code set.

[0229] When the dependency consistency check result for the second source code set indicates that the check passes, the generation device generates a software development kit based on the second source code set and the pre-configured authentication transport layer code, and uses the generated software development kit as the target software development kit after version synchronization.

[0230] Through steps S106 to S110, the generating device can automatically locate and regenerate the failure code file that has undergone structural drift after the target ontology model changes, and generate the target software development kit after version synchronization after dependency consistency verification, so that the content reflected by the software development kit is consistent with the changes in the target ontology model.

[0231] In some embodiments, considering that the target ontology model will frequently evolve in practical applications, the initial naming identifier may be renamed, migrated, split, or merged. The identifier conversion rule in step S102 can only eliminate name conflicts in the target namespace within the same version, and cannot guarantee that the legal program identifiers presented to the outside world by the same program element remain continuous between different versions of the target ontology model. This can lead to a break in the external interface of the software development kit after version synchronization. In this embodiment, step S102 also includes step S1028, and in the version synchronization process of steps S107 to S110, steps S1071 to S1076 are also included to maintain the continuity of the external interface of the software development kit during the evolution of the target ontology model.

[0232] S1028. Assign a globally unique and immutable semantic anchor to the element metadata or capability asset corresponding to the initial naming identifier, establish an evolutionary ledger that records the correspondence between the semantic anchor and the legal procedure identifier, and use the legal procedure identifier as the main name generated by the semantic anchor projection when generating the legal procedure identifier, and record the display name corresponding to the initial naming identifier as an alias in the evolutionary ledger.

[0233] Semantic anchors are identity identifiers that are independent of display names and legal procedural identifiers and remain unchanged across all versions of the target ontology model. The evolutionary ledger records the legal procedural identifier, display name, and hierarchical dependency path data corresponding to each semantic anchor in each version.

[0234] Before identifier conversion, the generation device assigns a unique semantic anchor point to each program element corresponding to the initial named identifier, which does not change with the display name. The semantic anchor point, along with the converted legal program identifier, display name, and hierarchical dependency path data, is recorded in the evolution ledger. This ensures that even if the display name changes during the evolution process, the same program element still has a traceable identity across different versions, providing a basis for maintaining interface continuity during version synchronization.

[0235] S1071 performs graph alignment between the ontology semantic difference map and the evolutionary ledger, and identifies changes in incremental element metadata relative to historical element metadata as renaming changes, migration changes, splitting changes, merging changes, and deletion changes based on the continuity of semantic anchor points.

[0236] Graph alignment refers to matching each change recorded in the ontology semantic difference graph with each semantic anchor in the evolutionary ledger based on semantic anchors, thereby determining the generation, disappearance, and separation / merging of semantic anchors involved in each change.

[0237] When a semantic anchor remains consistent before and after a change but only its name changes, it is considered a renaming change. When only the hierarchical dependency path data changes, it is considered a migration change. When a semantic anchor before a change is associated with multiple semantic anchors after a change, it is considered a splitting change. When multiple semantic anchors before a change are associated with the same semantic anchor after a change, it is considered a merging change. When a semantic anchor before a change is no longer associated with any program element after a change, it is considered a deletion change.

[0238] Compared to the conventional method of comparing only display names, aligning based on semantic anchor diagrams can distinguish between situations where the business semantics have not changed substantially but only the name or hierarchy has been adjusted, and situations where the business semantics have actually been separated or combined. This avoids misjudging that program elements have been deleted and rebuilt due to adjustments in display names.

[0239] S1072, for renaming-type changes and migration-type changes, read the old and new legal program identifiers corresponding to the same semantic anchor before and after the change from the evolution ledger, generate compatible forwarding stub code with the old legal program identifier as the external name, so that when it is called, it forwards the call parameters to the implementation corresponding to the new legal program identifier as is and returns the result as is.

[0240] Since the semantic anchors corresponding to the changes in the renaming class and the migration class remain unchanged before and after the change, that is, the business semantics have not changed substantially, the old version of the client application called by the old legal procedure identifier can access the changed implementation through the compatible forwarding stub code, thus maintaining the interface continuity without modifying the old version of the client application.

[0241] S1073, for splitting class changes, read the old legal program identifiers corresponding to the semantic anchors before the change and the new legal program identifiers corresponding to each semantic anchor after the change from the evolution ledger, generate one-to-many adapter code with the old legal program identifier as the external name, so that when it is called, it will distribute a call to the implementations corresponding to each new legal program identifier after the change according to the splitting correspondence, and generate result reassembler code, which will recombine the results returned by each implementation according to the original result structure of the old legal program identifier into a single result, so that the old version of the client application can still obtain structurally consistent results in the calling method before the change after the concept is split.

[0242] S1074, for merged changes, read multiple old legal program identifiers corresponding to each semantic anchor point before the change from the evolutionary ledger, and new legal program identifiers corresponding to the semantic anchor points after the change. Generate many-to-one aggregation facade code for each old legal program identifier, so that when it is called, the call is mapped to the same implementation corresponding to the new legal program identifier after the change, and extract the part corresponding to the original result structure of the old legal program identifier from the returned result and return it, so that the old version client application called by any old legal program identifier can still access the merged implementation in the calling method before the change after the concept is merged.

[0243] S1075, for deletion-type changes, the generating device reads the old valid program identifier corresponding to the previous version from the evolution ledger, and generates obsolete placeholder code with the old valid program identifier as its external name. When this code is invoked, it returns a preset obsolete message to indicate that the corresponding program element has been deleted. Compared to directly removing the source code file corresponding to the old valid program identifier, retaining the obsolete placeholder code can prevent older client applications from crashing directly because they cannot find the implementation when calling deleted program elements, allowing for a smooth transition with a predictable obsolete message.

[0244] S1076, Based on the evolution ledger, establish a versioned alias table that records the correspondence between the legal program identifiers and call signatures corresponding to each semantic anchor point in each version. Configure signature negotiation logic at the external call entry point of the software development kit, so that when the entry point receives a call, it queries the versioned alias table based on the legal program identifier and call signature used by the caller. Calls initiated with the old legal program identifier and old signature are routed to the implementation layer via the compatible forwarding stub code, one-to-many adapter code, many-to-one aggregation facade code, or deprecated placeholder stub code generated in steps S1072 to S1075. Calls initiated with the new legal program identifier and new signature are directly routed to the implementation layer, so that the old version and the new version client application share the same implementation layer.

[0245] After obtaining the second source code set in step S110, the generating device incorporates the aforementioned compatible codes, versioned alias tables, and signature negotiation logic into the second source code set to re-trigger dependency consistency verification. After the verification passes, a software development kit is generated based on the second source code set and the pre-configured authentication transport layer code as the target software development kit after version synchronization.

[0246] Through steps S1028 and S1071 to S1076, the generating device transforms the renaming, migration, splitting, merging, and deletion of the target ontology model into compileable processing that automatically identifies and generates corresponding compatible code based on semantic anchors. This allows older client applications to continue calling the software without recompiling when the business semantics have not changed substantially, thereby maintaining the continuity of the software development kit's external interface in the case of high-frequency evolution of the target ontology model.

[0247] The following describes an exemplary software development kit (SDK) generation device provided in an embodiment of the present invention. Figure 3 This is an exemplary hardware architecture diagram of the software development kit generation device provided in an embodiment of the present invention.

[0248] In some embodiments, the software development kit (SDK) generation apparatus may be an electronic device, or the software development kit generation apparatus may include an electronic device. The electronic device includes a processor, memory, and a network interface connected via a system bus. The processor of the electronic device provides computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the electronic device stores data. The network interface of the electronic device is used to communicate with other external terminals or servers via a network connection. In some embodiments, the network interface may be a wired network interface; in some embodiments, the network interface may also be a wireless network interface. When the computer program is executed by the processor, it implements the methods in the embodiments of the present invention.

[0249] Those skilled in the art will understand that Figure 3 The architecture shown is merely a block diagram of a portion of the architecture related to the present invention and does not constitute a limitation on the electronic device to which the present invention is applied. Specific electronic devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0250] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

[0251] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0252] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on an electronic device, all or part of the processes or functions described in the embodiments of the present invention are generated. The electronic device may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0253] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for generating software development kits based on ontology models, characterized in that, include: Obtain the element metadata corresponding to the target ontology model, and the capability assets registered under the target ontology model. The element metadata includes concept type definitions, relation type definitions, event type definitions, and attribute constraint data corresponding to each custom type. The capability assets include preset function definitions, skill definitions, and input and output parameter data declared by the function definitions and skill definitions respectively. The element metadata and the initial naming identifier in the capability assets are converted into legal program identifiers corresponding to the target programming language according to preset identifier conversion rules. Based on the attribute constraint data and the legal program identifier, a first source code set corresponding to the target programming language is generated. The first source code set includes object accessor code, relation accessor code, event accessor code, and callable method code. Perform dependency consistency verification on the first source code set to obtain the dependency consistency verification result; When the dependency consistency check result indicates that the check has passed, a software development kit is generated based on the first source code set and the pre-configured authentication transport layer code.

2. The method for generating a software development kit based on an ontology model according to claim 1, characterized in that, The step of performing dependency consistency verification on the first source code set to obtain the dependency consistency verification result includes: Parse the code text in the first source code set into a set of abstract syntax trees; Traverse each node in the abstract syntax tree set and extract the call reference identifier contained in each node; Verify that the call reference identifier exists in the set of declared identifiers composed of the legal program identifiers, and filter out undeclared reference data that did not match successfully; The dependency consistency check result is generated based on whether the undeclared reference data is empty.

3. The method for generating a software development kit based on an ontology model according to claim 2, characterized in that, The step of generating the dependency consistency check result based on whether the undeclared reference data is empty includes: When the undeclared reference data is empty, a global code dependency directed graph is constructed based on the reference relationships between nodes in the abstract syntax tree set; The closed-loop dependency path data is extracted from the global code dependency directed graph based on the loop detection algorithm; When the closed-loop dependency path data is not empty, the static type declaration code corresponding to the closed-loop dependency path data in the first source code set is replaced with lazy-loaded proxy interface code to obtain an acyclic source code set that eliminates circular dependencies. Based on the acyclic source code set, generate the dependency consistency check result indicating that the check has passed.

4. The method for generating a software development kit based on an ontology model according to claim 1, characterized in that, The step of converting the element metadata and the initial naming identifier in the capability assets into a legal program identifier corresponding to the target programming language according to a preset identifier conversion rule includes: Identify the non-standard character set in the initial naming identifier and convert the non-standard character set into the initial pinyin string; When the initial pinyin string conflicts with an existing identifier in the target namespace, obtain the unique identifier of the underlying data allocated by the initial name identifier in the target ontology model; The unique identifier of the underlying data is concatenated to the end of the initial pinyin string according to a preset separator to obtain the deduplicated valid program identifier.

5. The method for generating a software development kit based on an ontology model according to claim 1, characterized in that, The step of converting the element metadata and the initial naming identifier in the capability assets into a legal program identifier corresponding to the target programming language according to a preset identifier conversion rule includes: Identify the Chinese character set in the initial naming identifier and convert the Chinese character set into an initial pinyin string that does not contain tone features; When the initial pinyin string has a name conflict with an existing identifier in the target namespace, the tone number sequence corresponding to the Chinese character set is obtained, and the tone number sequence is concatenated to the end of the initial pinyin string to generate a first-level modifier string; When the first-level modifier string still has name conflicts in the target namespace, extract the hierarchical dependency path data associated with the initial naming identifier in the target ontology model; The target hash feature value is calculated by using a preset hash algorithm on the hierarchical dependency path data, and the target hash feature value is appended to the end of the first-level modifier string to obtain the deduplicated legal program identifier.

6. The method for generating a software development kit based on an ontology model according to claim 1, characterized in that, The step of generating a first source code set corresponding to the target programming language based on the attribute constraint data and the legal program identifier includes: Based on the attribute constraint data and the legal program identifier, generate object accessor code, relation accessor code, and event accessor code; Extract the target parameter definition data from the input and output parameter data declared by the function definition and the skill definition respectively; When the target parameter definition data is configured with a streaming response identifier, a callable method code set is generated based on the target parameter definition data and the legal program identifier. The callable method code set includes regular callable method code and streaming callable method code with chunked transport protocol support. The first source code set is generated based on the object accessor code, the relationship accessor code, the event accessor code, and the callable method code set.

7. A method for generating a software development toolkit based on an ontology model according to any one of claims 1-6, characterized in that, Following the generation of a software development kit based on the first source code set and a pre-configured authentication transport layer code, the method further includes: Listen for data change events generated by the target ontology model and obtain incremental element metadata of the target ontology model after the change. The incremental element metadata is structurally compared with the historical element metadata used when constructing the first source code set to generate a corresponding ontology semantic difference map. Based on the ontology semantic difference map, the failed code file that has experienced structural drift is located in the first source code set; Based on the incremental element metadata, the target programming language fragment corresponding to the failed code file is regenerated to obtain a partially updated code file; The invalid code file is replaced with the partially updated code file to obtain a second source code set, and the second source code set is used as the verification input data to re-trigger the dependency consistency verification step to generate the target software development kit after version synchronization.

8. An electronic device, characterized in that, Includes memory and one or more processors; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the electronic device to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium storing computer instructions, characterized in that, When the computer instructions are executed on the electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-7.

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed on the electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-7.

Images