Code generation method and device based on system model, computer equipment, readable storage medium and program product

Abstract

The invention relates to a code generation method and device based on a system model, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: acquiring a system model constructed based on a first language; the first language is a semi-formalized modeling language; analyzing the system model and performing rule check; the rules comprise a standard rule and a user-defined rule, the standard rule indicates the rule meeting the first language requirement, and the user-defined rule indicates a constraint condition of code generation; under the condition that the rule check is passed, generating a target code of a second language matched with the system model based on an analysis result; the second language is a programming language. By adopting the method, the system model constructed by the semi-formalized modeling language can be accurately converted into the programming language code.

Description

Technical Field

[0001] This application relates to the field of automated code generation technology, and in particular to a code generation method, apparatus, computer equipment, computer-readable storage medium, and computer program product based on a system model. Background Technology

[0002] In fields such as aviation, aerospace, and automotive, there is often a need to design and implement complex, real-time, safety-critical systems. During system development, it is difficult to simultaneously ensure both security and practicality if implemented directly using a programming language (such as C). Therefore, semi-formal modeling languages ​​(such as AADL, Architecture Analysis and Design Language) are often used to build the system, and then the resulting system model is converted into a programming language, ensuring that the final implementation remains consistent with the initial design.

[0003] Traditional conversion methods rely on third-party open-source tools. For example, when converting an AADL model to C code, the third-party open-source tool Osate2 is often used to parse the model before conversion. However, using third-party open-source tools may introduce unknown parsing errors, easily leading to conversion failure. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for generating system model-based code that can accurately convert system models constructed using semi-formal modeling languages ​​into programming language code, addressing the aforementioned technical problems.

[0005] In a first aspect, this application provides a code generation method based on a system model, comprising: obtaining a system model constructed based on a first language; the first language being a semi-formal modeling language; parsing the system model and performing rule checks; the rules including standard rules and custom rules, wherein the standard rules are rules that indicate compliance with the requirements of the first language, and the custom rules indicate constraints for code generation; and, if the rule check passes, generating target code in a second language that matches the system model based on the parsing results; wherein the second language is a programming language.

[0006] In one embodiment, parsing the system model and performing rule checks includes: constructing an abstract syntax tree corresponding to the system model and containing relationships between nodes; performing standard rule checks based on the abstract syntax tree; and, if the standard rule checks pass, instantiating the abstract syntax tree to obtain an abstract instantiated syntax tree, and performing custom rule checks on the abstract instantiated syntax tree.

[0007] In one embodiment, constructing an abstract syntax tree that corresponds to the system model and includes relationships between nodes includes: traversing the content of the system model and performing syntax checks; constructing an initial abstract syntax tree based on the content that passes the syntax checks; and adding relationships between nodes in the initial abstract syntax tree to obtain a final abstract syntax tree.

[0008] In one embodiment, adding the associations between nodes in the initial abstract syntax tree to obtain the final abstract syntax tree includes: determining the associations between components in the system model, wherein the associations include at least one of inclusion, inheritance, or connection relationships; and adding the associations to the initial abstract syntax tree by indexing according to the correspondence between the components in the system model and the nodes in the initial abstract syntax tree to obtain the final abstract syntax tree.

[0009] In one embodiment, generating target code in a second language that matches the system model includes: generating target code in a second language that matches the system model based on predefined mapping rules from the first language to the second language.

[0010] In one embodiment, the generated target code includes interface functions corresponding to runtime code, and the method further includes: during the code compilation process, compiling the target code and the runtime code corresponding to the interface functions to obtain an executable file corresponding to the system model.

[0011] Secondly, this application also provides a code generation apparatus based on a system model, comprising: a rule checker for acquiring a system model constructed based on a first language; the first language being a semi-formal modeling language; parsing the system model and performing rule checks; the rules including standard rules and custom rules, wherein the standard rules are rules that indicate compliance with the requirements of the first language, and the custom rules indicate constraints for code generation; and a code generator for generating target code in a second language that matches the system model based on the parsing results, provided that the rule checks pass; the second language being a programming language.

[0012] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described code generation method based on the system model.

[0013] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described code generation method based on a system model.

[0014] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described system model-based code generation method.

[0015] The aforementioned code generation method, apparatus, computer device, computer-readable storage medium, and computer program product based on a system model parses and performs rule checks on a system model constructed in a first language (semi-formal modeling language). Only when the rule checks pass will target code in a second language (programming language) be generated based on the parsing results. This application, on the one hand, prohibits the conversion of content that does not meet the requirements of the first language, thus avoiding the introduction of errors into the system model to be converted; on the other hand, it converts the content, thus avoiding errors in the generated code. This ensures that errors that do not conform to the constraints of the second language are not introduced during the parsing and conversion of the system model, improving conversion security and enabling the accurate and error-free conversion of a system model constructed in a semi-formal modeling language into target code in a programmable language. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a structural block diagram of a code generation apparatus according to one embodiment of the present application;

[0018] Figure 2 This is a flowchart illustrating a code generation method based on a system model according to one embodiment of this application;

[0019] Figure 3 This is a schematic diagram illustrating the principle of code generation based on a system model according to one embodiment of this application;

[0020] Figure 4 This is a schematic diagram illustrating the changes in the system model during code generation according to one embodiment of this application;

[0021] Figure 5 This is a schematic diagram illustrating the principle of a code generation method according to one embodiment of this application;

[0022] Figure 6 This is an internal structural diagram of a computer device according to one embodiment of the present application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0024] Before describing the detailed scheme of this application, the first and second languages ​​involved will be explained:

[0025] The first language can be a semi-formal modeling language, such as AADL, SysML (Systems Modeling Language), or UML (Unified Modeling Language).

[0026] AADL (Architecture Analysis and Design Language) is a semi-formal modeling language that supports model engineering design. It can support the design and analysis needs of complex, real-time, and safety-critical systems in fields such as aerospace and automotive. Since the official release of the AADL standard in 2004, the language has been improved and expanded based on industry experience. Its core documentation has been continuously revised and developed, evolving from AS5506 to the current AS5506D standard document. This document includes definitions of software components (such as processes, threads, and data), hardware components (such as processors, memory, and buses), and composite components (such as systems), as well as multiple (e.g., nine) standard attribute sets. Components are described in two ways: component type and component implementation. The component type defines the interface between the component and the outside world, such as characteristics, patterns, and attributes; the component implementation defines the internal interface of the component, such as sub-components, connections, and streams.

[0027] A second language, specifically a programming language, can be compiled and executed by a computer, such as C or C++.

[0028] In system development, semi-formal modeling languages ​​are often used to build systems, and then the resulting system model is converted into a programming language. Because semi-formal modeling languages ​​(such as AADL) and programming languages ​​(such as C) have different language structures, their semantics cannot be completely equivalent. Therefore, in practical applications, the key requirement during code generation is to ensure the semantic equivalence of critical models.

[0029] Taking AADL, a semi-formal modeling language, as an example, traditionally available AADL code generation tools include SireumHAMR (High-Assurance Modeling and Rapid Engineering for Embedded Systems). Sireum HAMR is a code generation and system building framework for embedded systems, whose architecture is specified using the Architecture Analysis and Design Language (AADL). HAMR supports the development of new components and the wrapping of old components by generating code that provides the interface infrastructure between components. The HAMR tool itself does not parse AADL files; it first relies on Ocarina (a standalone AADL model processor written in Ada) to parse the input AADL before completing code generation. Another example is the patents with application numbers 2022106642270 and 2010100280790, where the parsing of the AADL model relies on the third-party open-source tool Osate2 (an open-source integrated development environment based on Eclipse, specifically for designing and analyzing embedded real-time system architectures described using AADL), which carries the risk of introducing unknown parsing errors.

[0030] Compared to the traditional solutions mentioned above, this application fully implements functions such as system model parsing, standard rule checking, custom rule checking, and automatic code generation. During code generation, relevant rules can be set based on the content of the system model, ensuring that no errors are introduced during system model parsing and conversion, thus improving conversion security. In other words, this application proposes a convenient and secure code generation scheme that can convert a system model built based on a semi-formal modeling language into semantically equivalent target code while ensuring the accuracy of key semantic information.

[0031] The code generation method based on a system model provided in this application can be applied to, for example... Figure 1 The code generation apparatus 100 (also referred to as a code generation tool) shown is illustrated. Exemplarily, the code generation apparatus 100 may include a rule checker 101 and a code generator 102. In some embodiments, the code generation apparatus 100 may be implemented on a computer device (such as a terminal or server); in other embodiments, the code generation apparatus 100 may be implemented on a system including a terminal and a server (e.g., different modules of the code generation apparatus 100 are deployed on different devices that can communicate with each other).

[0032] For example, the terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0033] In one exemplary embodiment, such as Figure 2 As shown, a code generation method based on a system model is provided, and the method is illustrated using a code generation device 100 deployed in a computer device as an example. Specifically, the code generation method based on the system model includes the following steps 202 to 206. Wherein:

[0034] Step 202: Obtain the system model built based on the first language; the first language is a semi-formal modeling language.

[0035] The system model is a pre-built system architecture model with preset functions based on a first language. In some embodiments, the system model can be represented by a model file and an attribute set. In some scenarios, the first language may specifically be AADL, and the system model built based on AADL may specifically be an embedded model, which is represented by an AADL file and an attribute set.

[0036] In some embodiments, a subset of AADL can be selected based on the modeling use case and related business requirements, and the attribute set of each component in the AADL subset can be expanded. The system model can be described by the selected AADL subset and the attributes of each component in the AADL subset.

[0037] In some embodiments, due to the characteristics of semi-formal modeling languages, the code generation device 100 can select a suitable subset of AADL based on the functionality of the system model to be constructed, according to principles such as minimization, feasibility, and completeness, and expand the attribute sets of each component in the subset. The system model is described based on each component in the selected AADL subset and the expanded attribute sets. It is understood that the aforementioned AADL subset and attribute sets can be recognized by the code generation device 100.

[0038] An attribute set is a data collection describing the attributes of components supported by the first language. It can include standard attribute sets and custom attribute sets. For example, for a thread component in a model file (such as an AADL file), its corresponding attributes could be information indicating the thread type (e.g., a periodic thread) and the periodic time interval. A standard attribute set can be understood as the collection of attributes for each component officially defined by the first language. In practical applications, attributes for components involved in the system model can also be customized, i.e., custom attribute sets.

[0039] Furthermore, a pre-built system model can be input into the code generation device 100 so that the code generation device 100 can process the system model and obtain the generated target code.

[0040] Step 204: parse the system model and perform rule checks; the rules include standard rules and custom rules. Standard rules are rules that conform to the requirements of the first language, while custom rules are constraints that are generated by the code.

[0041] In some embodiments, the rule checker 101 can parse and check the system model, and after determining that the rule check is passed, input the parsing result to the code generator 102. Specifically, parsing the system model can involve parsing the components in the system model and the relationships between them. During the parsing process, rule checks can be performed on the intermediate representation obtained from the parsing.

[0042] For example, when the first language is AADL, the AADL file describing the system model and the attribute set can be input into the rule checker 101. The rule checker 101 parses the system model and performs rule checks, such as checking relevant standard rules from the SAE AS5506D standard and custom rules defined by the code generation device 100, to identify potential errors in the input system model and avoid unknown errors introduced during the parsing process. If the rule check fails, it indicates the presence of an error. Upon detecting an error, the code generation process can be stopped immediately, and an error message can be displayed.

[0043] In some embodiments, standard rules related to the components involved in the system model can be filtered from the full set of standard rules to perform standard rule checks on the system model in a targeted manner, reducing unnecessary checking work and improving rule checking efficiency.

[0044] In some implementations, rules include standard rules and custom rules; correspondingly, rule checks include standard rule checks and custom rule checks. Standard rules indicate rules that conform to the requirements of the first language; therefore, standard rule checks verify whether the intermediate representation of the system model conforms to the first language requirements. Custom rules indicate constraints for code generation; therefore, custom rule checks verify whether the intermediate representation of the system model conforms to those constraints. Custom rules primarily check for content that may cause errors in code generation or lead to discrepancies in the generated code, thereby avoiding potential problems with the input of the code generator 102 and improving the tool's security.

[0045] For example, standard rules may specifically include at least one of syntax rules, naming rules, validity rules, or consistency rules. Syntax rules are rules that indicate conformity to the syntax requirements of the first language; naming rules define rules for representing the names of defined identifiers and references to previously defined identifiers; validity rules define semantic restrictions on the AADL specification; and consistency rules define consistency restrictions on system instances.

[0046] Taking AADL as the first language as an example, the following examples illustrate the checking of relevant standard rules in the SAE AS5506D standard:

[0047] The syntax rules for package spaces are as follows:

[0048] package_spec ::=

[0049] package defining_package_name

[0050] ( public package_declarations [ private package_declarations ]

[0051] | private package_declarations )

[0052] end defining_package_name;

[0053] To define a package space, the `package` keyword must be followed by the package name. At the end of the package space definition, the `end` keyword must be followed by the same package name as the `package` keyword. This syntax rule will be checked during the standard rule review process; if it is not met, the code generation device 100 will report an error.

[0054] For example, the naming rules for packages are as follows:

[0055] A package name consists of one or more package identifiers, separated by double colons (::). Defined package names must be unique within the global namespace. This naming convention is checked during the standard rule review process; if the naming convention is not met, the code generation device 100 will report an error.

[0056] For example, the legality rules could be: subroutine type declarations can only contain parameters, stream specification clauses, and property associations. Subroutine implementations can only contain subroutine call clauses, join clauses, stream clauses, and property associations.

[0057] For example, a consistency rule could be: a subcomponent's classifier cannot recursively contain subcomponents with the same classifier. In other words, there should be no circular dependency between components.

[0058] It is understood that the examples of syntax rules, naming rules, legality rules, and consistency rules mentioned above are for illustrative purposes only and are not intended to limit the rules. In practical applications, the rules can be flexibly set according to the actual situation.

[0059] For example, the custom rule may specifically include at least one of the rules of the attribute / component types and related combinations supported by the constraint code generator 102, or the rules of the content that constrains the generation of abnormal code (such as infinite loops or recursion).

[0060] Taking AADL as the first language as an example, the rules for the attribute / component types and related combinations supported by the constraint code generator 102 can be as follows: a. The simple data types allowed in the AADL system model supported by the tool are: Boolean, Integer_8, Integer_16, Integer_32, Integer_64, Unsigned_8, Unsigned_16, Unsigned_32, Unsigned_64, Float, Float_32, Float_64, and Character; when defining the data type of the interface in the component declaration, if the interface is a simple data type, it must use the form Base_Types::Boolean; b. The system implementation must have one processor sub-component and at least one process sub-component, and must have the attribute actual_processor_binding; the process implementation must contain at least one thread sub-component; the thread implementation must have a calls and dispatch_protocol attribute; subroutines can be empty.

[0061] Rules that constrain the content that generates exception code could be, for example: in the implementation of a subprogram, a maximum of 3 levels of nesting is supported, and nesting between subprograms is not supported; when a subprogram connects to other subprograms via calls, one-to-many connections are supported; in other cases, only one-to-one connections between components are supported.

[0062] Step 206: If the rule check passes, generate target code in a second language that matches the system model based on the parsing results; the second language is a programming language.

[0063] In some embodiments, if the rule checks pass, that is, if both the standard rule checks and the custom rule checks pass, the code generator 102 can generate target code in a second language that matches the system model based on the parsing results.

[0064] In some embodiments, generating target code in a second language that matches the system model includes: generating target code in a second language that matches the system model based on predefined mapping rules from a first language to a second language.

[0065] The mapping rule refers to the correspondence between semantically equivalent content described in the first language and content described in the second language. Mapping rules can be pre-constructed based on the language requirements of both the first and second languages, allowing the code generator 102 to convert first-language content into semantically equivalent second-language content. This enables the system model to be quickly and accurately converted into target code in the second language.

[0066] It is understandable that corresponding mapping rules can be constructed for different second languages ​​to be used for system model transformation. That is, a corresponding code generator can be designed for each second language, which can realize the reuse of rule checker 101 and meet different business needs while saving resources.

[0067] In some embodiments, if any rule check in the standard rules or custom rules fails, the code generation device 100 may issue an error, such as generating and presenting a prompt message and / or cause analysis indicating that the rule check failed, to instruct the user to rebuild or adjust the system model.

[0068] The aforementioned code generation method based on a system model parses and checks the system model constructed in a first language (semi-formal modeling language) according to rules. Only when the rule check passes will the target code in a second language (programming language) be generated based on the parsing results. This application prohibits the conversion of content that does not meet the requirements of the first language, thus avoiding the introduction of errors into the system model to be converted; on the other hand, it prohibits the conversion of content that does not conform to the constraints of the second language, thus avoiding errors in the generated code. This ensures that no errors are introduced during the parsing and conversion of the system model, improves conversion security, and enables the accurate and error-free conversion of the system model constructed in the semi-formal modeling language into the target code of the programmable language.

[0069] The following example uses AADL as the first language and C as the second language, and combines... Figure 3 To describe the scheme of this application, such as Figure 3 As shown, this application selects a subset of AADL based on the usage scenario and related requirements, including a component subset and an attribute subset. Then, based on the content of the AADL subset, it clarifies the relevant standard rules in the AADL standard and defines the inspection content of the custom rules. Next, based on the description in the AADL standard, it designs mapping rules from AADL to C language. Finally, according to the rule inspection content and the AADL-to-C mapping rules, it implements a rule checker and a code generator. This rule checker and code generator can then convert the system model built using AADL into C code that is semantically consistent with the model. The generated code can be combined with runtime code for compilation and execution. The solution in this application ensures the semantic integrity and correctness of the AADL-to-C code conversion process and prevents the introduction of errors during code generation.

[0070] The following section provides a detailed explanation of the system model parsing and rule checking:

[0071] In some embodiments, parsing the system model and performing rule checks includes: constructing an abstract syntax tree corresponding to the system model and containing relationships between nodes, and performing standard rule checks; if the standard rule checks pass, instantiating the abstract syntax tree to obtain an abstract instantiated syntax tree, and performing custom rule checks. Further, if the custom rule checks pass, generating target code in the second language that matches the system model based on the abstract instantiated syntax tree and predefined mapping rules from the first language to the second language.

[0072] The Abstract Syntax Tree (AST) is a tree-like representation of the abstract grammatical structure that is closer to that of a first language. In this embodiment, it can indicate the logical structure of the system model. The Abstract Instantiation Syntax Tree (AIT) is a tree-like representation obtained by instantiating the Abstract Syntax Tree.

[0073] Please refer to Figure 4 , Figure 4 This illustration shows the changes in the description of the system model during code generation according to one embodiment of this application. In some embodiments, the rule checker 101 converts the system model (including model files and attribute sets) into an abstract syntax tree and instantiates it to obtain an abstract instantiated syntax tree. The abstract instantiated syntax tree is input to the code generator 102, which outputs the target code.

[0074] In some embodiments, constructing an abstract syntax tree that corresponds to the system model and contains relationships between nodes includes: traversing the content of the system model and performing a syntax check; constructing an initial abstract syntax tree based on the content that passes the syntax check; and adding relationships between nodes in the initial abstract syntax tree to obtain the final abstract syntax tree.

[0075] Specifically, the rule checker 101 can scan the model files (such as AADL files) and attribute sets in the system model, read the character (Token) streams, perform lexical and syntactic analysis for syntax checking, and gradually build an abstract syntax tree based on the content that passes the syntax check. The abstract syntax tree built in this process (i.e., the initial abstract syntax tree) is closer to the description in the first language (such as AADL), and its structure is closer to that of the first language.

[0076] For example, an engineering node can be used as the root node of an abstract syntax tree, and child nodes of this root node can be constructed based on packages, attribute sets, etc., parsed from the model file (e.g., Figure 4 The abstract syntax tree contains nodes such as package 1, package 2, package 3, standard attribute set, and custom attribute set. The child nodes of the corresponding package node are constructed based on the components included in the package node, and the child nodes of the corresponding attribute set node are constructed based on the attribute information in the attribute set.

[0077] In some embodiments, the rule checker 101 can parse all the information in the system model into an abstract syntax tree. During the parsing of the system model, the syntax rules and some naming rules (such as the uniqueness of named entities) can be checked. Only after the check passes will the corresponding abstract syntax tree be constructed.

[0078] Furthermore, after constructing the initial abstract syntax tree, the rule checker 101 can add the relationships between the nodes in the initial abstract syntax tree to obtain the final abstract syntax tree. Specifically, adding the relationships between the nodes in the initial abstract syntax tree to obtain the final abstract syntax tree includes: determining the relationships between the components in the system model, where the relationships include at least one of containment, inheritance, or connection relationships; and adding the relationships to the initial abstract syntax tree using an index based on the correspondence between the components in the system model and the nodes in the initial abstract syntax tree to obtain the final abstract syntax tree.

[0079] The relationship includes at least one of the following: containment, inheritance, or connection. Containment means one component contains another; inheritance means one component can be created based on another; connection refers to the data flow relationship between components, such as data from component A being input into component B.

[0080] Specifically, the rule checker 101 can obtain the relationship between different components by analyzing the model file (such as the AADL file), and then map the relationship between different components to the relationship between nodes in the abstract syntax tree based on the correspondence between each component and each component node in the abstract syntax tree, thus obtaining the final abstract syntax tree.

[0081] In some embodiments, the rule inspector 101 can add indexes to nodes in the form of flags to indicate the relationships between that node and other nodes. For example, adding a flag to node A indicates that node A is contained in node B; adding a flag to node C indicates that node C needs to inherit attribute information from node D, and so on. It is understood that adding relationships between nodes does not change the tree structure of the abstract syntax tree.

[0082] In this way, the relationships between components can be mapped to the abstract syntax tree through indexing, enabling the abstract syntax tree to more comprehensively represent the system model.

[0083] In the above embodiments, the content of the system model is traversed and a syntax check is performed to construct an initial abstract syntax tree based on the content that has passed the syntax check. Then, the relationships between different components are added to the abstract syntax tree to obtain a complete abstract syntax tree. This ensures that the final abstract syntax tree can accurately and completely represent the information in the system model and avoid information omission.

[0084] Next, the rule checker 101 can perform standard rule checks on the final abstract syntax tree, such as checking for naming rules, validity rules, or consistency rules. If the standard rule check passes, the abstract syntax tree is instantiated to obtain an abstract instantiated syntax tree, and then the abstract instantiated syntax tree is checked for custom rules.

[0085] Specifically, during instantiation, rule checker 101 traverses the entire abstract syntax tree (AST), determining the root node of the abstract instantiated syntax tree (SMT) based on specified information. It then extracts the corresponding components from the AST based on the index of the root node, obtaining the child nodes and adding their attribute information. This process is repeated step-by-step, determining the corresponding child nodes based on the determined node indices and adding attribute information to construct the SMT. It should be noted that during instantiation, for certain nodes in the instantiated AST, checks can be performed immediately after the node is generated (these checks can specifically be partial standard rule checks, such as partial consistency rule checks. For example, consistency rule checks can be performed after a software node is generated). Only after these checks pass can other nodes be generated, ensuring the accuracy of the SMT construction.

[0086] By instantiating, an abstract syntax tree that is closer to the description of a first language can be converted into an abstract instantiated syntax tree that is closer to the description of a second language, making it easier to generate target code for the second language.

[0087] Furthermore, after instantiation is completed, an abstract instantiated syntax tree is obtained. The rule checker 101 can check based on custom rules. If the abstract instantiated syntax tree passes the custom rule check, it can be input into the code generator 102, which will generate the corresponding target code.

[0088] In the above embodiments, parsing the system model and performing standard rule checks and custom rule checks based on the intermediate representations obtained from the parsing (such as abstract syntax trees and abstract instantiated syntax trees) can ensure the accuracy of converting the system model into target code.

[0089] In some embodiments, different mapping rules can be set based on different second languages ​​to develop different code generators. When needed, the corresponding code generator can be adapted based on the specific second language, thus enabling the reuse of other modules and achieving flexible adaptation to application scenarios while reducing resource consumption.

[0090] Specifically, the code generator 102 can traverse the abstract instantiation syntax tree to obtain relevant information about the system model, and generate the corresponding target code based on this information and mapping rules.

[0091] In some embodiments, the mapping rule may specifically be a rule for converting the components into code in a programming language. For example, the mapping rule may include at least one of the following:

[0092] a. Convert system components into the outermost folder of the code project structure. Specifically, system components provide a collection of interoperable application software. Because this collection is an abstract concept, it will be the outermost folder in the generated code project structure, containing all the generated code.

[0093] b. Assign the processor component's attributes to the process bound to the corresponding processor and the threads within that process. Specifically, a processor component represents an abstract model of the hardware and software, responsible for scheduling and executing threads bound to that processor. The relevant attributes of the processor component will be inherited by the process bound to that processor and the threads within that process. Furthermore, because the processor component is an abstract concept, it will not be reflected in the generated code.

[0094] c. A process component represents a model of a virtual address space. A process contains processes and their sub-components (mainly threads and subroutines). Process components are primarily used to model a virtual address space containing concurrent tasks or active objects. The meaning of this model is consistent with the semantics in main.c in the C language. Each process component will generate a separate folder.

[0095] d. Thread components represent models of concurrent tasks or active objects (scheduling units that can execute concurrently with other threads), primarily based on the input-computation-output model of thread and port communication and execution. Thread components are mapped to C code function interfaces that create threads based on the information of the thread component, and the created threads execute according to the modeling information.

[0096] e. A subroutine component represents a description of a function interface or a sequence of function interface calls. The parameters of the function interface will be determined based on the characteristics of the subroutine component, and a pointer will be used to represent a parameter value that can be output.

[0097] f. Data components represent the modeling of data types. Based on the parameters of the data components, the corresponding data structure in C code will be generated. If the data type is a complex data type such as a structure, enumeration, or array, the tool will also generate corresponding data serialization and deserialization interfaces to facilitate data transmission.

[0098] It is understood that the above mapping rules are for illustrative purposes only and are not intended to be limiting. In actual applications, more, fewer, or different mapping rules can be set.

[0099] In some embodiments, the generated target code includes interface functions corresponding to runtime code. The method further includes: compiling the target code and the runtime code corresponding to the interface functions together during the code compilation process to obtain an executable file corresponding to the system model.

[0100] It should be noted that first-language languages ​​lack the concept of dynamic semantics; therefore, there is no runtime code corresponding to the system model. In this embodiment, the code corresponding to the system model is decoupled from the runtime code, and the runtime code is provided in the form of an interface. That is, when generating the target code, interface functions corresponding to the runtime code are added to the appropriate locations in the target code based on the system logic described by the system model. Furthermore, during the code compilation process, the target code and the runtime code corresponding to the interface functions can be compiled together to generate the corresponding executable file.

[0101] In some embodiments, the runtime code corresponding to the interface function can be a pre-defined set of code, or it can be customized or adjusted based on the actual application. The runtime code mainly includes functional code related to thread parameter configuration and thread scheduling, and users can also implement it according to the runtime interface description in the user manual.

[0102] For example, the interface functions corresponding to the runtime code may include at least one of the following:

[0103] The `TaskHandler new_task(ContextHandler ctx, struct TaskConf conf)` method is used to create a new task; the `ConnectionHandler new_connection(ContextHandler ctx, ConnectionId id, enum ConnectionType conn_type, struct ConnectionConfig cfg)` method is used to create a new connection; and the `ContextHandler create_context(void)` method is used to create a context, where the context is a runtime data context used to store runtime-related data and interfaces.

[0104] In the above embodiments, the generated code will call the runtime interface in the appropriate places according to the logic of the system described by the model, thereby separating the generated code and the supported runtime code, that is, decoupling the target code and the runtime code; in addition, users can modify the specific implementation of the interface function of the runtime code according to the corresponding scenario, which further improves the practicality of the solution.

[0105] The following is for reference. Figure 5 The code generation method based on the system model in this application is described in detail below:

[0106] In some embodiments, the code generation apparatus 100 may include the following modules:

[0107] 1. Abstract Syntax Tree Module:

[0108] The Abstract Syntax Tree (AST) module is a data module primarily used to describe the abstract syntax tree structure of AADL and to provide interfaces for creating AST instance nodes and accessing AST instance information.

[0109] 2. Abstract instantiation syntax tree module:

[0110] The Abstract Instantiation Syntax Tree (AIT) module is also a data module, mainly used to describe the abstract instantiation tree structure and provide interfaces for creating AIT nodes and accessing AIT node information.

[0111] 3. Support module:

[0112] The support module is mainly used to support the operation of the code generation device, and its main functions include command line parsing, prompt message support, and memory management.

[0113] 4. Rule Inspector 101:

[0114] The rule checker 101 includes a front-end module, an analysis model, an instantiation module, and a custom rule checking module. Specifically: the front-end module includes a syntax parsing unit and a lexical parsing unit, used to parse the input system model according to the syntax rules in the first language standard and convert the system model into an abstract syntax tree; the analysis module adds indexes to the abstract syntax tree and performs standard rule checks; the instantiation module instantiates the abstract syntax tree to obtain an abstract instantiated syntax tree; and the custom rule checking module performs custom rule checks to prevent unsupported content from entering the code generator, thereby improving the tool's security.

[0115] 5. Code Generator 102:

[0116] The code generator includes a code generation module that processes the abstract instantiated syntax tree to generate target code that is semantically consistent with the input system model.

[0117] The following section will provide a detailed explanation of the code generation method based on the system model, in conjunction with the modules described above:

[0118] First, the command-line parsing unit of the support module parses the command-line instructions input by the user into the code generation tool, obtaining information such as the path to the input AADL file, the path to the output C code project, and the name of the root system implementation for instantiation. The front-end module then scans the attribute set and AADL model file for syntax rule checks and outputs an abstract syntax tree (AST) corresponding to the system model. The analysis module adds node indexes to the AST, i.e., adds the relationships between various component nodes, and then performs standard rule checks, outputting an AST that conforms to syntax rules, naming rules, consistency rules, and legality rules, and corresponds to the system model. The instantiation module instantiates the system implementation specified in the command line as the root, outputting an AST corresponding to the system model. The custom rule checking module then performs custom rule checks based on the AST and tool-defined rule checks, outputting an AST that conforms to all relevant rule checks, and prohibiting components that do not support code generation from entering the code generation module. Finally, the code generation module traverses the AST and generates target code that is semantically consistent with the input system model, based on the first-language-to-second-language mapping rules.

[0119] In the above process, the support module will support functions such as prompts and memory management for the code generation tool, while the AST module and AIT module will provide relevant interfaces for creating and accessing AST instance nodes and AIT instance nodes.

[0120] During the rule checks described above, if the input system model is found to be inconsistent with syntax rules, naming rules, consistency rules, legality rules, and custom rules, the code generation tool will issue an error message and stop the process.

[0121] In the above embodiments, the system model described in the first language is progressively converted into a corresponding abstract syntax tree and abstract instantiated syntax tree, and syntax rules, naming rules, consistency rules, legality rules, and custom rules are checked during the conversion process. Therefore, it is possible to prevent the generation of second language code from being generated by content that does not meet the standard rules and custom rules, thereby improving the security of the code generation process while ensuring that the generated target code is semantically equivalent to the input system model.

[0122] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0123] Based on the same inventive concept, this application also provides a system model-based code generation apparatus for implementing the above-described system model-based code generation method. The solution provided by this apparatus is similar to the implementation described in the above-described method; therefore, the specific limitations in one or more system model-based code generation apparatus embodiments provided below can be found in the limitations of the system model-based code generation method described above, and will not be repeated here.

[0124] In one exemplary embodiment, a code generation apparatus based on a system model is provided, comprising: a rule checker 101 and a code generator 102, wherein:

[0125] Rule checker 101 is used to obtain the system model built based on the first language; the first language is a semi-formal modeling language; it parses the system model and performs rule checks; the rules include standard rules and custom rules. Standard rules are rules that indicate compliance with the requirements of the first language, and custom rules indicate the constraints for code generation.

[0126] Code generator 102 is used to generate target code in a second language that matches the system model based on the parsing results, provided that the rule check passes. The second language is a programming language.

[0127] In some embodiments, the rule checker 101 includes a front-end module, an analysis module, an instantiation module, and a custom rule checking module. The front-end module is used to construct an initial abstract syntax tree corresponding to the system model; the analysis module is used to construct an abstract syntax tree containing the relationships between nodes and perform standard rule checks; the instantiation module is used to instantiate the abstract syntax tree to obtain an abstract instantiated syntax tree if the standard rule checks pass; and the custom rule checking module is used to perform custom rule checks on the abstract instantiated syntax tree.

[0128] In some embodiments, the analysis module is specifically used to traverse the content of the system model and perform syntax checks, construct an initial abstract syntax tree based on the content that passes the syntax checks, and add the relationships between the nodes in the initial abstract syntax tree to obtain the final abstract syntax tree.

[0129] In some embodiments, the analysis module is specifically used to determine the relationships between components in the system model, including at least one of inclusion, inheritance, or connection relationships; based on the correspondence between components in the system model and nodes in the initial abstract syntax tree, the relationships are added to the initial abstract syntax tree by indexing to obtain the final abstract syntax tree.

[0130] In some embodiments, the code generator 102 is specifically used to generate target code in a second language that matches the system model, based on predefined mapping rules from a first language to a second language.

[0131] In some embodiments, the generated target code includes interface functions corresponding to runtime code. The code generation device further includes a compilation module, which is used to compile the target code and the runtime code corresponding to the interface functions during the code compilation process to obtain an executable file corresponding to the system model.

[0132] Each module in the aforementioned system module-based code generation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0133] In one exemplary embodiment, a computer device is provided, which may be a terminal or a server, and its internal structure diagram may be as follows: Figure 6 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a code generation method based on a system model.

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

[0135] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0136] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0137] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0138] 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. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0139] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0140] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A code generation method based on a system model, characterized in that, The method includes: Obtain a system model built based on a first language; the first language is a semi-formal modeling language; The system model is parsed and rule checks are performed; the rules include standard rules and custom rules, the standard rules are rules that indicate compliance with the requirements of the first language, and the custom rules indicate the constraints for code generation; If the rule check passes, target code in a second language that matches the system model is generated based on the parsing results; the second language is a programming language.

2. The method according to claim 1, characterized in that, The process of parsing the system model and performing rule checks includes: Construct an abstract syntax tree that corresponds to the system model and includes the relationships between nodes, and perform standard rule checks; If the standard rule check passes, the abstract syntax tree is instantiated to obtain an abstract instantiated syntax tree, and then a custom rule check is performed.

3. The method according to claim 2, characterized in that, The construction of the abstract syntax tree, which corresponds to the system model and contains the relationships between nodes, includes: The system model is traversed and its contents are checked for syntax. An initial abstract syntax tree is constructed based on the contents that pass the syntax check. Add the relationships between the nodes in the initial abstract syntax tree to obtain the final abstract syntax tree.

4. The method according to claim 3, characterized in that, The step of adding the relationships between nodes in the initial abstract syntax tree to obtain the final abstract syntax tree includes: Determine the relationships between the components in the system model, wherein the relationships include at least one of inclusion, inheritance, or connection. Based on the correspondence between the components in the system model and the nodes in the initial abstract syntax tree, the association is added to the initial abstract syntax tree by indexing to obtain the final abstract syntax tree.

5. The method according to claim 1, characterized in that, The generation of target code in a second language that matches the system model includes: Based on predefined mapping rules from the first language to the second language, target code in the second language that matches the system model is generated.

6. The method according to any one of claims 1 to 5, characterized in that, The generated target code includes interface functions corresponding to the runtime code, and the method further includes: During the code compilation process, the target code and the runtime code corresponding to the interface function are combined for compilation to obtain an executable file corresponding to the system model.

7. A code generation device based on a system model, characterized in that, The device includes: A rule checker is used to obtain a system model built based on a first language; the first language is a semi-formal modeling language; the system model is parsed and rule checks are performed; the rules include standard rules and custom rules, the standard rules are rules that indicate compliance with the requirements of the first language, and the custom rules indicate the constraints for code generation; A code generator is used to generate target code in a second language that matches the system model based on the parsing results, provided that the rule check passes. The second language is a programming language.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. 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 steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images