Software development kit generation method and apparatus, electronic device, and storage medium

Abstract

The present disclosure relates to a software development kit generation method and device, electronic equipment and storage medium. By obtaining metadata of a target ontology, constructing an intermediate semantic object of each field type in at least one field type based on the metadata, rendering and generating a source code file corresponding to each field type under a target programming language based on the intermediate semantic object of each field type and a preset code template, and generating a software development kit based on the source code file corresponding to each field type, compared with the prior art, the present disclosure constructs an intermediate semantic object for each type by obtaining ontology metadata containing object, link, operation and other field types, and generates a source code based on a template, and finally generates a software development kit. The scheme realizes full automation and end-to-end generation from a high-level semantic model to specific programming language code, improves semantic expression capability, and solves the problems of low development efficiency and high maintenance cost.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for generating software development kits. Background Technology

[0002] In modern software development, especially in enterprise applications involving complex business data models, developers frequently need to interact with a semantic data layer (often called an ontology) provided by the backend. An ontology maps raw data to real-world concepts, relationships, and operations, providing a consistent data view for upper-layer applications. However, developers face numerous challenges when interfacing with such ontology platforms on the client side (e.g., using Python).

[0003] Current software development kit (SDK) generation solutions require developers to manually concatenate Uniform Resource Locators (URIs) and parse the returned Lightweight Data Interchange (LDTIM) data, or use tools to generate client code based on Open Application Programming Interface (API) description documents. Furthermore, developers must manually write class code corresponding to the ontology structure to map it. These solutions suffer from low development efficiency, insufficient semantic expressiveness, and high maintenance costs. Summary of the Invention

[0004] To address the aforementioned technical problems, this disclosure provides a method, apparatus, electronic device, and storage medium for generating software development kits.

[0005] In a first aspect, embodiments of this disclosure provide a method for generating a software development kit, the method comprising: Obtain the metadata of the target ontology, wherein the metadata includes at least one field type, and the at least one field type includes object type, link type and operation type; Based on the metadata, an intermediate semantic object is constructed for each of the at least one field type, the intermediate semantic object being used to characterize the structured field representation corresponding to the field type in the target programming language; Based on the intermediate semantic object of each field type and the preset code template, the source code file corresponding to each field type in the target programming language is rendered and generated. A software development kit is generated based on the source code file corresponding to each field type.

[0006] In some embodiments, constructing an intermediate semantic object for each field type among the at least one field type based on the metadata includes: The metadata of the target ontology is parsed to obtain the parsed metadata; The abnormal data in the parsed metadata is corrected to obtain the corrected metadata; Based on the corrected metadata, an intermediate semantic object is constructed for each of the at least one field type.

[0007] In some embodiments, constructing an intermediate semantic object for each field type among the at least one field type based on the metadata includes: Iterate through each field type in the metadata and establish a mapping relationship between each field type and the target programming language. Based on the mapping relationship, each field type is mapped to an intermediate semantic object corresponding to each field type in the target programming language. The intermediate semantic object includes the type name of each field type, the attribute information included in each field type, and the documentation description of each field type.

[0008] In some embodiments, after obtaining the metadata of the target ontology, the method further includes: Based on the inheritance identifier field in the metadata, identify the inheritance relationship between the object types in the metadata; Based on the inheritance relationship, a corresponding class inheritance tree structure is added to the intermediate semantic object corresponding to the object type.

[0009] In some embodiments, after rendering and generating source code files corresponding to each field type in the target programming language based on the intermediate semantic object of each field type and the preset code template, the method further includes: Based on the link type in the metadata, determine the link relationship between the first object type and the second object type in the object type; Based on the link relationship, a corresponding attribute access method is created for the second object type in the source code file corresponding to the first object type; After generating the software development kit based on the source code file corresponding to each field type, the method further includes: In response to a query request for the second object type, a query builder instance is returned based on the attribute access method, and the query result of the query request is obtained based on the query builder instance.

[0010] In some embodiments, after determining the link relationship between a first object type and a second object type based on the link type in the metadata, the method further includes: Based on the link relationship between the first object type and the second object type, a reverse relationship is obtained from the second object type to the first object type. Based on the reverse relationship, a corresponding reverse access method is created for the first object type in the source code file corresponding to the second object type. The reverse access method is used to represent querying the first object type based on the second object type.

[0011] In some embodiments, generating a software development kit based on the source code file corresponding to each field type includes: Retrieve the tag information for each field type in the metadata; Based on the tag information of each field type, the source code files corresponding to each field type are clustered into the corresponding directory structure to obtain the software development kit.

[0012] Secondly, embodiments of this disclosure provide a software development kit (SDK) generation apparatus, the apparatus comprising: The acquisition module is used to acquire the metadata of the target ontology, wherein the metadata includes at least one field type, and the at least one field type includes object type, link type and operation type; A construction module is configured to construct an intermediate semantic object for each of the at least one field type based on the metadata, wherein the intermediate semantic object is used to characterize the structured field representation corresponding to the field type in the target programming language; The rendering module is used to render and generate source code files corresponding to each field type in the target programming language based on the intermediate semantic object of each field type and the preset code template. The generation module is used to generate a software development kit based on the source code file corresponding to each field type.

[0013] Thirdly, embodiments of this disclosure provide an electronic device, including: Memory; Processor; and Computer programs; The computer program is stored in memory and configured to be executed by a processor to implement the method as described in the first aspect.

[0014] Fourthly, embodiments of this disclosure provide a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the method as described in the first aspect.

[0015] Fifthly, embodiments of this disclosure also provide a computer program product comprising a computer program or instructions that, when executed by a processor, implement the method as described in the first aspect.

[0016] The software development kit (SDK) generation method, apparatus, electronic device, and storage medium provided in this disclosure acquire metadata of a target ontology, construct intermediate semantic objects for each of the at least one field type based on the metadata, render and generate source code files corresponding to each field type in the target programming language based on the intermediate semantic objects of each field type and a preset code template, and generate a SSD based on the source code files corresponding to each field type. Compared with the prior art, this disclosure acquires ontology metadata containing field types such as objects, links, and operations, constructs intermediate semantic objects for each type, generates source code based on templates, and finally generates a SSD. This solution achieves fully automated, end-to-end generation from a high-level semantic model to specific programming language code, improves semantic expressiveness, eliminates the need for manual writing and maintenance, and solves the problems of low development efficiency and high maintenance costs. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0018] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 Flowchart of a software development kit generation method provided in this embodiment of the disclosure; Figure 2 A flowchart illustrating a method for generating a software development kit (SDK) according to another embodiment of this disclosure; Figure 3 A flowchart illustrating a method for generating a software development kit (SDK) according to another embodiment of this disclosure; Figure 4 A schematic diagram of the structure of the software development kit generation apparatus provided in the embodiments of this disclosure; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0020] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0021] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0022] In modern software development, especially in enterprise applications involving complex business data models, developers frequently need to interact with a semantic data layer (often called an ontology) provided by the backend. An ontology maps raw data to real-world concepts, relationships, and operations, providing a consistent data view for upper-layer applications. However, developers face numerous challenges when interfacing with such ontology platforms on the client side (e.g., using Python).

[0023] Current software development kit (SDK) generation solutions require developers to manually concatenate Uniform Resource Locators (URIs) and parse the returned Lightweight Data Interchange (LDTIM) data, or use tools to generate client code based on Open Application Programming Interface (API) description documents. Furthermore, developers must manually write class code corresponding to the ontology structure to map it. These solutions suffer from low development efficiency, insufficient semantic expressiveness, and high maintenance costs.

[0024] To address this problem, this disclosure provides a method for generating a software development kit, which will be described below with reference to specific embodiments.

[0025] Figure 1 This is a flowchart illustrating a method for generating a software development kit (SDK) according to an embodiment of this disclosure. The method is executed by an electronic device, which can be a portable mobile device such as a smartphone, tablet, laptop, in-vehicle navigation device, or smart sports equipment; or a fixed device such as a personal computer, smart home appliance, or server. The server can be a single server, a server cluster, a distributed cluster, or a centralized cluster. This method can be applied to scenarios involving the generation of software development kits.

[0026] It is understood that the software development kit generation method provided in this disclosure can also be applied in other scenarios.

[0027] The following is about Figure 1 The method for generating a software development kit (SDK) is described below. This method can be applied to electronic devices, and the specific steps involved are as follows: S101. Obtain the metadata of the target ontology.

[0028] The metadata includes at least one field type, which includes object type, link type, and operation type.

[0029] In this step, the electronic device can acquire the metadata of the target ontology. Specifically, the metadata of the target ontology can be obtained from raw data, such as database tables and log streams. Optionally, an ontology refers to a semantic data model that maps raw data to real-world concepts. An ontology typically contains at least one field type, which can include object type, link type, and action type. Object type: Defines real-world entities, such as "airplane," "customer," and "order." Each object type contains attributes; for example, an airplane might contain attributes such as id (identifier), name, and manufacturer. Link type: Defines the relationships between objects, such as "customer" owning "order" and "airplane" owning "flight." Action type: Defines the actions performed on objects, such as "update order status," and typically includes preset logic and validation rules.

[0030] S102. Based on metadata, construct an intermediate semantic object for each field type in at least one field type.

[0031] The intermediate semantic object is used to represent the structured field representation corresponding to the field type in the target programming language.

[0032] In this step, the electronic device can construct an intermediate semantic object for each field type in at least one field type based on metadata. This intermediate semantic object represents the structured field representation corresponding to the field type in the target programming language. Essentially, this step maps the data types defined in the ontology to types in the target programming language (such as Python).

[0033] In some embodiments, S102 may include, but is not limited to, S1021, S1022, and S1023: S1021. Parse the metadata of the target ontology to obtain the parsed metadata.

[0034] In this step, after obtaining the metadata of the target ontology, the electronic device will parse the metadata of the target ontology, parse the metadata into a data structure in memory, and obtain the parsed metadata.

[0035] S1022. Correct the abnormal data in the parsed metadata to obtain the corrected metadata.

[0036] In this step, data cleaning and correction logic is performed. The electronic device can correct any anomalous data in the parsed metadata, resulting in corrected metadata. Anomalous data can include data errors or missing data. Specifically, missing non-critical information is filled in: the description field for each field type is checked. If the description for the Aircraft object type is found to be empty, it is filled with a default docstring, such as "Aircraft objecttype". This ensures that even if the metadata is incomplete, the generated code still has basic readability. The corrected metadata has a more standardized and complete structure, providing reliable input for subsequent steps.

[0037] S1023. Based on the corrected metadata, construct an intermediate semantic object for each field type in at least one field type.

[0038] In this step, the electronic device constructs an intermediate semantic object for each field type in at least one field type based on the corrected metadata.

[0039] S103. Based on the intermediate semantic object of each field type and the pre-set code template, render and generate the source code file corresponding to each field type in the target programming language.

[0040] In this step, the electronic device can load pre-designed code templates for the target programming language, such as Jinja2 template files. Further, based on the intermediate semantic objects for each field type and the pre-defined code templates, it renders and generates source code files corresponding to each field type in the target programming language. These code templates are the "skeleton" of the code, containing structures such as class definitions and method signatures, and using variable placeholders (such as {{class_name}}, {{fields}}). Then, the intermediate semantic objects for each field type are passed as context to the template engine. The template engine fills the corresponding placeholders in the template with the data from the intermediate semantic objects, and after rendering, generates the source code files corresponding to each field type.

[0041] This embodiment enhances the robustness of the generation process by correcting anomalies in the parsed metadata before constructing the intermediate semantic object. It can handle potentially non-standard or incomplete metadata inputs in the real world, preventing the generation process from being interrupted due to data problems, thereby improving the practicality and reliability of the entire solution.

[0042] S104. Generate a software development kit based on the source code file corresponding to each field type.

[0043] In this step, the electronic device can generate a software development kit (SDK) based on the source code files corresponding to each field type. Specifically, the source code files for each field type are placed in their respective folders and packaged into a complete SSD that developers can install via command line.

[0044] This disclosure embodiment obtains the metadata of the target ontology, constructs an intermediate semantic object for each field type in at least one field type based on the metadata, renders and generates source code files corresponding to each field type in the target programming language based on the intermediate semantic objects for each field type and a pre-defined code template, and generates a software development kit based on the source code files corresponding to each field type. Compared with the prior art, this disclosure embodiment obtains ontology metadata containing field types such as objects, links, and operations, constructs intermediate semantic objects for each type, generates source code based on templates, and finally generates a software development kit. This solution achieves fully automated, end-to-end generation from a high-level semantic model to specific programming language code, improves semantic expressiveness, eliminates the need for manual writing and maintenance, and solves the problems of low development efficiency and high maintenance costs.

[0045] Figure 2 A flowchart of a software development kit generation method provided in another embodiment of this disclosure is shown below. Figure 2 As shown, the method includes the following steps: S201. Obtain the metadata of the target ontology.

[0046] The metadata includes at least one field type, which includes object type, link type, and operation type.

[0047] Specifically, the implementation process and principle of S201 and S101 are the same, and will not be repeated here.

[0048] S202. Traverse each field type in the metadata and establish a mapping relationship between each field type and the target programming language.

[0049] In this step, the electronic device can iterate through each field type in the metadata. First, type mappings are established. For example, the electronic device maintains a mapping table that maps each field type defined in the ontology to a type in the target programming language (such as Python). For example: ontology type STRING → Python type str; ontology type INTEGER → Python type int; ontology type DATE → Python type datetime.date; ontology type OBJECT <aircraft>→Python types such as 'Aircraft' (type hint string) are not specifically limited here.

[0050] S203. Based on the mapping relationship, map each field type to an intermediate semantic object corresponding to each field type in the target programming language.

[0051] The intermediate semantic object includes the type name of each field type, the attribute information included in each field type, and the documentation description of each field type.

[0052] In this step, an intermediate semantic object is constructed. For example, for each object type (such as Aircraft), the system creates an intermediate semantic object (e.g., an instance of the IRClassDefinition class). This intermediate semantic object contains the following key information: type_name: The name of the field type, such as "Aircraft".

[0053] attributes_info: A list of attribute information. It iterates through all attributes of this object type in the ontology. For each attribute, based on the mapping relationship described above, it records the attribute information of this object type in the target programming language. For example, an airplane contains attributes such as id (identifier), name (name), and manufacturer (manufacturer). Its name attribute is recorded in the target programming language as (name: "name", py_type: str, required: True).

[0054] docstring: Documentation for this field type, typically extracted from the description field in the metadata, or using the default value.

[0055] For link types and operation types, corresponding intermediate semantic objects are also constructed to record information such as the names of their field types, a list of attribute information, and documentation.

[0056] This embodiment establishes a mapping relationship from metadata field types to the target programming language, and constructs an intermediate semantic object containing type names, attribute information, and documentation accordingly, achieving precise transmission of semantic information. This ensures that the generated source code has accurate and complete type annotations and documentation. It solves the problems of lack of type safety and low development efficiency, provides a solid foundation for automatic type completion and static type checking in integrated development environments, and greatly improves the development experience and code quality.

[0057] In some embodiments, Figure 2 Steps S202 and S203 shown can be used as Figure 1 One specific implementation of step S102 shown.

[0058] S204. Identify the inheritance relationship between object types in the metadata based on the inheritance identifier field in the metadata.

[0059] In this step, the electronic device searches for inheritance identifier fields in the metadata and further identifies the inheritance relationship between object types based on these fields. For example, it finds a field in the metadata of the MilitaryAircraft object type: "extends": "Aircraft". This indicates that MilitaryAircraft is a subtype of Aircraft, meaning there is an inheritance relationship between the two object types.

[0060] S205. Based on inheritance relationships, add the corresponding class inheritance tree structure to the intermediate semantic object corresponding to the object type.

[0061] In this step, the electronic device adds a corresponding class inheritance tree structure to the intermediate semantic object corresponding to the object type based on the inheritance relationship. For example, when building the intermediate semantic object (IRClassDefinition) for MilitaryAircraft, it not only records its own attributes (such as weapon_system), but also adds a class inheritance tree structure representing the inheritance relationship internally. For example, a parent_class_name field with the value "Aircraft" is set in the intermediate semantic object. At the same time, a dependency table is maintained to record the inheritance chain from MilitaryAircraft to Aircraft. Then, in the subsequent code rendering stage, the parent_class_name field in the intermediate semantic object is checked. Since this field is not empty, the template engine renders it as inheritance syntax and automatically calls the attribute information of the parent class. In this way, the inheritance relationship of the ontology is accurately and automatically mapped to the class inheritance system of the target programming language, achieving code reuse and semantic consistency.

[0062] This embodiment identifies and processes inheritance relationships in metadata and reflects them in the class inheritance tree structure of intermediate semantic objects, achieving a lossless mapping from ontology-level inheritance semantics to programming language inheritance syntax. This not only makes the generated code more in line with object-oriented design principles, improving code reusability and readability, but also clearly reflects the hierarchical relationships between business entities in the client code, enhancing the semantic expressiveness of the software development kit.

[0063] S206. Based on the intermediate semantic object of each field type and the pre-set code template, render and generate the source code file corresponding to each field type in the target programming language.

[0064] Specifically, the implementation process and principle of S206 and S103 are the same, and will not be repeated here.

[0065] S207. Generate a software development kit based on the source code file corresponding to each field type.

[0066] Specifically, the implementation process and principle of S207 and S104 are the same, and will not be repeated here.

[0067] This embodiment of the disclosure obtains the metadata of the target ontology, traverses each field type in the metadata, establishes a mapping relationship for each field type from the metadata to the target programming language, and maps each field type to an intermediate semantic object corresponding to each field type in the target programming language according to the mapping relationship. Further, based on the inheritance identifier field in the metadata, the inheritance relationship between object types in the metadata is identified, and based on the inheritance relationship, a corresponding class inheritance tree structure is added to the intermediate semantic object corresponding to the object type. Then, based on the intermediate semantic object of each field type and a pre-set code template, source code files corresponding to each field type in the target programming language are rendered and generated, and a software development kit is generated based on the source code files corresponding to each field type. Through this method, this embodiment of the disclosure establishes a mapping relationship from metadata field types to the target programming language, and constructs an intermediate semantic object containing type names, attribute information, and documentation accordingly, achieving accurate transmission of semantic information. This ensures that the generated source code has accurate and complete type annotations and documentation. By identifying and processing the inheritance relationship in the metadata and reflecting it in the class inheritance tree structure of the intermediate semantic object, a lossless mapping from ontology-level inheritance semantics to programming language inheritance syntax is achieved, enhancing the semantic expressiveness of the software development kit.

[0068] Figure 3 A flowchart of a software development kit generation method provided in another embodiment of this disclosure is shown below. Figure 3 As shown, the method includes the following steps: S301. Obtain the metadata of the target ontology.

[0069] The metadata includes at least one field type, which includes object type, link type, and operation type.

[0070] Specifically, the implementation process and principle of S301 and S101 are the same, and will not be repeated here.

[0071] S302. Based on metadata, construct an intermediate semantic object for each field type in at least one field type.

[0072] The intermediate semantic object is used to represent the structured field representation corresponding to the field type in the target programming language.

[0073] Specifically, the implementation process and principle of S302 and S102 are the same, and will not be repeated here.

[0074] S303. Based on the intermediate semantic object of each field type and the pre-set code template, render and generate the source code file corresponding to each field type in the target programming language.

[0075] Specifically, the implementation process and principle of S303 and S103 are the same, and will not be repeated here.

[0076] S304. Based on the link type in the metadata, determine the link relationship between the first object type and the second object type in the object type.

[0077] In this step, the electronic device identifies the link types in the metadata and determines the link relationship between the first object type and the second object type based on the link type. For example, if a link type is identified where "airplane" operates "flights", then "airplane" points to "flights".

[0078] In some embodiments, after determining the link relationship between the first object type and the second object type in the object types based on the link type in the metadata in step S304, the method further includes steps A and B: Step A: Based on the link relationship between the first object type and the second object type, obtain the reverse relationship from the second object type to the first object type; Step B: Based on the reverse relationship, create a corresponding reverse access method for the first object type in the source code file corresponding to the second object type. The reverse access method is used to represent querying the first object type based on the second object type.

[0079] In this embodiment, when a link relationship is identified between a first object type and a second object type, a reverse relationship can be obtained from the second object type to the first object type. Furthermore, based on this reverse relationship, a corresponding reverse access method is created for the first object type in the source code file corresponding to the second object type. Specifically, a global "link-reverse relationship" mapping table can be established. For example, if a reverse relationship is obtained between "flight" and "airplane", during the code generation phase, when processing the template for the flight object type, a reverse relationship between flight and airplane will be detected. At this point, a regular airplane list attribute will not be generated. Instead, a reverse access method is added to the source code file corresponding to the generated flight object type. This allows developers to easily find the Aircraft to which a Flight object belongs.

[0080] This embodiment automatically infers and generates reverse access methods based on the forward link relationship, supplementing the unidirectional relationship with bidirectional query capabilities. This further enhances the completeness and ease of use of the generated software development kit. Developers can query from either side of the association without additional coding, achieving more flexible and powerful data navigation capabilities and improving development efficiency.

[0081] S305. Based on the linking relationship, create a corresponding property access method for the second object type in the source code file corresponding to the first object type.

[0082] In this step, the electronic device can create corresponding attribute access methods for the second object type in the source code file corresponding to the first object type, based on the link relationships. During the code generation phase, when processing the template of the Aircraft object type, links originating from it are detected. At this point, a regular list of flights attributes is not generated. Instead, an attribute access method is added to the source code file corresponding to the generated Aircraft object type, similar to using the @property decorator in Python. This allows developers to easily find the Flight to which an Aircraft object belongs.

[0083] This embodiment creatively implements an intuitive chained query syntax by converting the link relationships defined in the metadata into dynamic attribute access methods in the source code and returning a query builder with pre-defined filtering conditions at runtime. It addresses the pain points of low semantic level and lack of graph traversal capabilities, encapsulating complex graph queries into object attribute access that aligns with developer intuition, significantly reducing the cognitive burden and technical barrier to using ontology data.

[0084] S306. Obtain the tag information for each field type in the metadata.

[0085] In this step, each field type in the metadata can have a module or category tag. For example, the object type has the tag "Object," and the link type has the tag "Link." After the source code file is generated, the electronic device will read this tag information. Tags can be used as a basis for directory classification.

[0086] S307. Based on the label information of each field type, cluster the source code files corresponding to each field type into the corresponding directory structure to obtain the software development kit.

[0087] In this step, the electronic device clusters the source code files corresponding to each field type into the corresponding directory structure based on the label information of each field type, thus obtaining a software development kit (SDK). For example, the source code files generated for all field types labeled "Object" are placed in the ` / generated_sdk / models / Object / ` directory. The source code files generated for all field types labeled "Link" are placed in the ` / generated_sdk / models / Link / ` directory. Simultaneously, the electronic device packages the files in each directory and its subdirectories to obtain the SSD.

[0088] S308. In response to a query request for a second object type, return a query builder instance based on the attribute access method, and obtain the query result of the query request based on the query builder instance.

[0089] In this step, upon receiving a query request for a second object type, a query builder instance is returned based on attribute access, and the query results are obtained based on the query builder instance. Specifically, for example, upon receiving a query request for flights `my_plane.operated_flights`, a query builder instance `QueryBuilder` is returned based on attribute access, and the query results are obtained based on the query builder instance. In some embodiments, this instance can have a pre-defined filter condition `aircraft_id="plane123"`. Subsequent `.filter(...)`, `.order_by(...)`, and `.limit(...)` methods are chained on this builder instance, continuously accumulating query conditions. When the query results are finally needed, the query builder serializes all accumulated conditions into a format acceptable to the backend application programming interface (such as a lightweight data exchange format with a specific structure), initiates a network request, and deserializes the returned data into a list of Flight objects. This implements lazy loading and chained queries.

[0090] In some embodiments, asynchronous mode and semantic caching can be supported. Specifically, a secondary thread is created to monitor and handle data processing requests without affecting the main thread's tasks, thus implementing asynchronous mode. Optionally, historical query conditions can be recorded, and when querying again, historical query conditions can be automatically injected, eliminating the need for re-entry, thus implementing historical semantic caching. Optionally, an expiration policy is maintained; when an update or manipulation of ontology object type data is detected, it is automatically synchronized to the source code files, and the software development kit is regenerated to ensure data consistency.

[0091] In some embodiments, a filter class method is generated for each field type based on the builder pattern. When a user queries a certain field type, a structured query condition fragment conforming to the backend interface specification is generated, and finally the structured query condition fragment is sent uniformly by the find() query function.

[0092] This disclosure embodiment obtains the metadata of the target ontology and, based on the metadata, constructs an intermediate semantic object for each field type in at least one field type. Then, based on the intermediate semantic object for each field type and a pre-defined code template, it renders and generates source code files corresponding to each field type in the target programming language. Based on the link types in the metadata, it determines the link relationship between a first object type and a second object type. Based on the link relationship, it creates a corresponding attribute access method for the second object type in the source code file corresponding to the first object type. Further, it obtains the tag information for each field type in the metadata and, based on the tag information, clusters the source code files corresponding to each field type into a corresponding directory structure to obtain a software development kit (SDK). Then, in response to a query request for the second object type, it returns a query builder instance based on the attribute access method, and obtains the query result based on the query builder instance. Compared to existing technologies, this disclosure embodiment achieves code organization based on business semantics by clustering different types of source code files into different directories according to the tag information in the metadata. This results in a generated SSD with a clear and modular directory structure, facilitating developer understanding, import, and management, and improving the engineering level and long-term maintainability of the final product.

[0093] The solutions in the various embodiments of this disclosure can be used individually or in combination without conflict. For example, S104, generating a software development kit based on the source code file corresponding to each field type, and S308, responding to a query request for a second object type, returning a query builder instance based on the attribute access method, and obtaining the query result of the query request based on the query builder instance, can be used in combination, and no specific limitation is made here.

[0094] Figure 4 This is a schematic diagram of the structure of a software development kit (SDK) generation apparatus provided in an embodiment of this disclosure. The SSD generation apparatus can be an electronic device as described in the above embodiment, or it can be a component or part within that electronic device. The SSD generation apparatus provided in this embodiment can execute the processing flow provided in the software development kit generation method embodiment, such as... Figure 4 As shown, the software development kit (SDK) generation device 50 includes: an acquisition module 51, a construction module 52, a rendering module 53, and a generation module 54. The acquisition module 51 acquires metadata of the target ontology, including at least one field type, which includes an object type, a link type, and an operation type. The construction module 52 constructs an intermediate semantic object for each of the at least one field type based on the metadata. The intermediate semantic object represents the structured field representation of the field type in the target programming language. The rendering module 53 renders and generates source code files corresponding to each field type in the target programming language based on the intermediate semantic object and a preset code template. The generation module 54 generates the SSD based on the source code files corresponding to each field type.

[0095] Optionally, when the construction module 52 constructs an intermediate semantic object for each of the at least one field type based on the metadata, it is specifically used to: parse the metadata of the target ontology to obtain parsed metadata; correct abnormal data in the parsed metadata to obtain corrected metadata; and construct an intermediate semantic object for each of the at least one field type based on the corrected metadata.

[0096] Optionally, when the construction module 52 constructs an intermediate semantic object for each field type among the at least one field type based on the metadata, it is specifically used to: traverse each field type in the metadata, establish a mapping relationship between each field type and the target programming language; map each field type to an intermediate semantic object corresponding to each field type in the target programming language according to the mapping relationship, wherein the intermediate semantic object includes the type name of each field type, the attribute information included in each field type, and the documentation description of each field type.

[0097] Optionally, after obtaining the metadata of the target ontology, the device 50 further includes: an adding module 55; the adding module 55 is used to identify the inheritance relationship between the object types in the metadata based on the inheritance identifier field in the metadata; and based on the inheritance relationship, add a corresponding class inheritance tree structure to the intermediate semantic object corresponding to the object type.

[0098] Optionally, after the intermediate semantic object of each field type and the preset code template are used to render and generate the source code file corresponding to each field type in the target programming language, the device 50 further includes: a creation module 56; the creation module 56 is used to determine the link relationship between the first object type and the second object type in the object type based on the link type in the metadata; and based on the link relationship, create a corresponding attribute access method for the second object type in the source code file corresponding to the first object type; After generating the software development kit based on the source code file corresponding to each field type, the device 50 further includes a query module 57; the query module 57 is used to respond to a query request for the second object type, return a query builder instance based on the attribute access method, and obtain the query result of the query request based on the query builder instance.

[0099] Optionally, after determining the link relationship between the first object type and the second object type based on the link type in the metadata, the creation module 56 is further configured to: obtain a reverse relationship from the second object type to the first object type based on the link relationship between the first object type and the second object type; and create a corresponding reverse access method for the first object type in the source code file corresponding to the second object type based on the reverse relationship, wherein the reverse access method is used to represent querying the first object type based on the second object type.

[0100] Optionally, when the generation module 54 generates a software development kit based on the source code files corresponding to each field type, it is specifically used to: obtain the tag information of each field type in the metadata; and based on the tag information of each field type, cluster the source code files corresponding to each field type into the corresponding directory structure to obtain the software development kit.

[0101] Figure 4 The software development kit generation apparatus of the illustrated embodiment can be used to execute the technical solutions of the above method embodiments. Its implementation principle and technical effects are similar, and will not be repeated here.

[0102] Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of this disclosure. See below for details. Figure 5 It shows a schematic diagram of a structure suitable for implementing the electronic device 600 in the embodiments of this disclosure. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0103] like Figure 5 As shown, electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 602 or a program loaded from storage device 608 into random access memory (RAM) 603 to implement the software development kit generation method as described in the embodiments of this disclosure. The RAM 603 also stores various programs and data required for the operation of electronic device 600. The processing device 601, ROM 602, and RAM 603 are interconnected via bus 604. An input / output (I / O) interface 605 is also connected to bus 604.

[0104] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, magnetic tapes, hard disks, etc.; and communication devices 609. Communication device 609 allows electronic device 600 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 An electronic device 600 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0105] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts, thereby implementing the software development kit (SDK) generation method described above. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, it performs the functions defined in the methods of embodiments of this disclosure.

[0106] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0107] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol), and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks ("LANs"), wide area networks ("WANs"), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0108] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0109] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: Obtain the metadata of the target ontology, wherein the metadata includes at least one field type, and the at least one field type includes object type, link type and operation type; Based on the metadata, an intermediate semantic object is constructed for each of the at least one field type, the intermediate semantic object being used to characterize the structured field representation corresponding to the field type in the target programming language; Based on the intermediate semantic object of each field type and the preset code template, the source code file corresponding to each field type in the target programming language is rendered and generated. A software development kit is generated based on the source code file corresponding to each field type.

[0110] Optionally, when one or more of the above-described procedures are executed by the electronic device, the electronic device may also execute other steps of the above embodiments.

[0111] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0112] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0113] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0114] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0115] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0116] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0117] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0118] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.< / aircraft>

Claims

1. A method for generating a software development kit, characterized in that, The method includes: Obtain the metadata of the target ontology, wherein the metadata includes at least one field type, and the at least one field type includes object type, link type and operation type; Based on the metadata, an intermediate semantic object is constructed for each of the at least one field type, the intermediate semantic object being used to characterize the structured field representation corresponding to the field type in the target programming language; Based on the intermediate semantic object of each field type and the preset code template, the source code file corresponding to each field type in the target programming language is rendered and generated. A software development kit is generated based on the source code file corresponding to each field type.

2. The method according to claim 1, characterized in that, The step of constructing an intermediate semantic object for each field type in the at least one field type based on the metadata includes: The metadata of the target ontology is parsed to obtain the parsed metadata; The abnormal data in the parsed metadata is corrected to obtain the corrected metadata; Based on the corrected metadata, an intermediate semantic object is constructed for each of the at least one field type.

3. The method according to claim 1, characterized in that, The step of constructing an intermediate semantic object for each field type in the at least one field type based on the metadata includes: Iterate through each field type in the metadata and establish a mapping relationship between each field type and the target programming language. Based on the mapping relationship, each field type is mapped to an intermediate semantic object corresponding to each field type in the target programming language. The intermediate semantic object includes the type name of each field type, the attribute information included in each field type, and the documentation description of each field type.

4. The method according to claim 1, characterized in that, After obtaining the metadata of the target ontology, the method further includes: Based on the inheritance identifier field in the metadata, identify the inheritance relationship between the object types in the metadata; Based on the inheritance relationship, a corresponding class inheritance tree structure is added to the intermediate semantic object corresponding to the object type.

5. The method according to claim 1, characterized in that, After rendering and generating the source code file corresponding to each field type in the target programming language based on the intermediate semantic object of each field type and the preset code template, the method further includes: Based on the link type in the metadata, determine the link relationship between the first object type and the second object type in the object type; Based on the link relationship, a corresponding attribute access method is created for the second object type in the source code file corresponding to the first object type; After generating the software development kit based on the source code file corresponding to each field type, the method further includes: In response to a query request for the second object type, a query builder instance is returned based on the attribute access method, and the query result of the query request is obtained based on the query builder instance.

6. The method according to claim 5, characterized in that, After determining the link relationship between the first object type and the second object type based on the link type in the metadata, the method further includes: Based on the link relationship between the first object type and the second object type, a reverse relationship is obtained from the second object type to the first object type. Based on the reverse relationship, a corresponding reverse access method is created for the first object type in the source code file corresponding to the second object type. The reverse access method is used to represent querying the first object type based on the second object type.

7. The method according to claim 1, characterized in that, The process of generating a software development kit based on the source code file corresponding to each field type includes: Retrieve the tag information for each field type in the metadata; Based on the tag information of each field type, the source code files corresponding to each field type are clustered into the corresponding directory structure to obtain the software development kit.

8. A software development kit (SDK) generation apparatus, characterized in that, include: The acquisition module is used to acquire the metadata of the target ontology, wherein the metadata includes at least one field type, and the at least one field type includes object type, link type and operation type; A construction module is configured to construct an intermediate semantic object for each of the at least one field type based on the metadata, wherein the intermediate semantic object is used to characterize the structured field representation corresponding to the field type in the target programming language; The rendering module is used to render and generate source code files corresponding to each field type in the target programming language based on the intermediate semantic object of each field type and the preset code template. The generation module is used to generate a software development kit based on the source code file corresponding to each field type.

9. An electronic device, characterized in that, include: Memory; processor; as well as Computer programs; The computer program is stored in the memory and configured to be executed by the processor to implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.

Images