Method for automatically generating object model from PIM to PSM

Abstract

The invention discloses an automatic generation method from PIM to PSM of an object model, which comprises the following steps: analyzing a TDL file of the PIM model through an object model compiling tool, and completing lexical, grammatical and semantic analysis; converting the PIM model into an IDL file and a C + + code according to an analysis result of the TDL file; compiling an IDL file by using an IDL compiler of OpenDDS and TAO, and generating a platform related model PSM file in combination with the C + + code; and deploying the generated PSM file to a test platform to realize a servitization application program of test resources. According to the method, the conversion efficiency from the PIM model to the PSM model is remarkably improved, and the workload of manually writing codes is reduced. According to the method and the system, the flexibility of cross-platform support is enhanced, the implementation process of remote calling and data distribution is simplified, the maintainability and the expansibility of the system are improved, and the method and the system are particularly suitable for development of a complex large-scale distributed system and resource management of a test platform.

Description

Technical Field

[0001] The present invention relates to the field of software development and system modeling, and more specifically to an automatic generation method from an object model PIM to PSM. Background Art

[0002] In the joint test system, test resources need to be described through digital modeling. The current common practice is to use the Platform Independent Model (PIM) to define the interface characteristics of resources. This model does not depend on the specific platform and facilitates the cross-platform application of resource models. However, in actual applications, the PIM model needs to be converted into C++ code related to a specific platform, namely the Platform Specific Model (PSM), and compiled and linked with the middleware to generate an executable test resource service application.

[0003] At present, the conversion process from PIM to PSM mostly relies on manually written conversion code, which is not only inefficient but also prone to errors. In order to meet the needs of modern intelligent systems for efficient automation, a tool and method that can automatically realize the conversion of object models from PIM to PSM is urgently needed. Summary of the invention

[0004] In view of this, the present invention provides an automatic generation method of an object model PIM to PSM, which can automatically parse the source code file of the PIM model and generate the target code file of the PSM model, and can solve the problem that the conversion process from PIM to PSM mostly relies on manual writing of conversion code, which is inefficient and prone to errors; and can adapt to the needs of modern intelligent systems for efficient automation.

[0005] In order to achieve the above object, the present invention adopts the following technical solution:

[0006] The present invention provides a method for automatically generating an object model PIM to PSM, comprising the following steps:

[0007] S10, parsing the TDL file of the PIM model through the object model compilation tool to complete lexical, grammatical and semantic analysis;

[0008] S20, converting the PIM model into an IDL file and C++ code according to the parsing result of the TDL file;

[0009] S30, using the IDL compiler provided by OpenDDS and TAO to compile the IDL file, and combining the C++ code to generate the platform-related model PSM file;

[0010] S40, deploying the generated PSM file to the test platform to realize the service-oriented application of the test resources.

[0011] Furthermore, the step S10 further includes: after the lexical, grammatical and semantic analyses are completed, respectively checking the corresponding error tables; when the error table is not empty, terminating the compilation.

[0012] Furthermore, in step S10, the lexical analysis includes:

[0013] Read the contents from the TDL file character by character, identify the keywords, symbols and identifiers in the file, and generate a word list and a lexical error table.

[0014] Furthermore, in step S10, the syntax analysis includes:

[0015] Based on lexical analysis, the word list is converted into an abstract syntax tree;

[0016] According to the predefined TDL grammar rules, keywords and symbols are combined into grammatical structures to form a hierarchical grammar tree;

[0017] Duplicate declarations, missing semicolons, base class or interface definition errors are identified and recorded in the syntax error table.

[0018] Furthermore, in step S10, the semantic analysis includes:

[0019] Check whether each node in the abstract syntax tree complies with the defined semantic rules, ensure that the definition in the PIM model complies with the semantic logic, and generate a semantic error table; the defined semantic rules include:

[0020] Check for conflicts in class, package, attribute, and method names;

[0021] Verify the legitimacy of inheritance relationship;

[0022] Checks that data type definitions can be found in the symbol table, ensuring that each identifier has a defined type.

[0023] Furthermore, the step S20 includes:

[0024] According to the parsing results of the TDL file, the classes, attributes and methods in the PIM model are converted into structures and interfaces in the IDL file according to the predefined TDL and IDL mapping rules;

[0025] The state distribution object class, basic data types and state distribution object class pointers in the PIM model are converted into C++ codes according to the predefined TDL and C++ mapping rules.

[0026] Furthermore, the step S30 includes:

[0027] Use TAO's IDL compiler to compile the IDL file, combine it with the C++ code, generate client class files and server class files; define the server interface and implement the logic of remote call;

[0028] Use OpenDDS_IDL compiler to compile IDL files and generate C++ class files for data distribution, including: generating status attribute definition client class files, generating remote method interface class files, generating status attribute definition server class files, and generating remote method implementation abstract class files; define data distribution type support classes and data monitoring classes to implement data subscription and publishing.

[0029] Furthermore, the step S40 includes:

[0030] Deploy the generated PSM file to the test platform, and realize the management and operation of resources in a distributed environment through the interaction between the agent and the server;

[0031] During deployment, the servers will be distributed on different test platform nodes to provide control and modification of test resources;

[0032] The agent receives the latest state of the object and accesses the operations provided by the server through remote calls, synchronizing the data and state between different nodes in the test platform;

[0033] Through the collaborative work of agents and servers, experimental resources are transmitted between different platform nodes, remote method calls and data synchronization are achieved, and ultimately a service-oriented application is formed.

[0034] It can be seen from the above technical solution that, compared with the prior art, the present invention discloses a method for automatically generating an object model PIM to PSM. The method automatically parses the TDL file of PIM, generates a corresponding C++ code file after lexical, grammatical and semantic analysis, and uses IDL compilers such as Open_DDS and TAO to generate PSM files. The method significantly improves the efficiency of PIM to PSM model conversion and reduces the workload of manual code writing. The flexibility of cross-platform support is enhanced, while the implementation process of remote calls and data distribution is simplified, and the maintainability and scalability of the system are improved, which is particularly suitable for the development of complex large-scale distributed systems and test platform resource management. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0036] Figure 1 This is a flow chart of the method for automatically generating the object model PIM to PSM provided by the present invention.

[0037] Figure 2 A schematic diagram of the composition of the object model compilation tool provided by the present invention.

[0038] Figure 3 This is a static class diagram of the object model compilation tool provided by the present invention.

[0039] Figure 4 The overall activity diagram of the object model compilation tool provided by the present invention.

[0040] Figure 5 This is a diagram of the TDL file parsing process provided by the present invention.

[0041] Figure 6 A diagram of the lexical analysis process provided by the present invention.

[0042] Figure 7 A grammatical analysis process diagram provided by the present invention.

[0043] Figure 8 A diagram of the semantic analysis process provided by the present invention.

[0044] Fig. 9 A relationship diagram between the server and the agent provided by the present invention.

[0045] Fig.10 This is a diagram of the data transmission method in the test system provided by the present invention.

[0046] Fig.11 The present invention provides a flow chart for using TAO to develop an application program and implement remote method calling.

[0047] Fig.12 This is a schematic diagram of the interface provided by the present invention.

[0048] Fig.13 This is an interface diagram of the object model compilation tool provided by the present invention. DETAILED DESCRIPTION

[0049] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0050] In the joint test field, when systematizing test resources, it is necessary to first establish a digital model of test resources, that is, use the platform-independent model PIM to describe the interface characteristics of test resources in the digital domain; then, convert the platform-independent object model into platform-dependent C++ code, that is, PSM model, and compile and link with the middleware to generate a service-oriented application program for test resources. In order to keep up with the pace of the intelligent era, the present invention designs an automatic generation method from the object model PIM to PSM.

[0051] Reference Figure 1 As shown, the embodiment of the present invention discloses a method for automatically generating an object model PIM to PSM, comprising the following steps:

[0052] S10, parsing the TDL file of the PIM model through the object model compilation tool to complete lexical, grammatical and semantic analysis;

[0053] S20, converting the PIM model into an IDL file and C++ code according to the parsing result of the TDL file;

[0054] S30, using the IDL compiler provided by OpenDDS and TAO to compile the IDL file, and combining the C++ code to generate the platform-related model PSM file;

[0055] S40, deploying the generated PSM file to the test platform to realize the service-oriented application of the test resources.

[0056] Among them, PIM is a platform-independent TDL description file, which contains elements such as packages, SDOs, local classes, and messages; PSM is a platform-dependent C++ class file. The automatic generation of object model PIM to PSM is the design of object model compilation tools. Figure 2 As shown, the structure of the object model compilation tool is shown.

[0057] The tool consists of two parts: source file parsing and target file generation. The first part is the source language format file parsing, that is, parsing the PIM described by TDL, including four stages: lexical analysis, syntax analysis, semantic analysis and error handling. The second part is to generate files in the target language format, that is, convert part of TDL into IDL, generate part of the PSM file by the IDL compiler of Open_DDS and TAO, and convert other TDL into C++ code.

[0058] By constructing Figure 3 The static model of the object model compilation tool shown is used as a reference template for design to improve design efficiency.

[0059] The static model of the object model compilation tool consists of a class. Due to space limitations, the functions and properties of this class are omitted. The class diagram only lists the functions and properties directly related to the functions of the object model compilation tool. This class has only one public function, which is to compile TDL files. Other functions are private. This class independently completes functions such as TDL file parsing, client class file generation, and server class file generation. By calling the opendds_idl compiler and tao_idl compiler, it realizes functions such as automatic compilation of IDL files.

[0060] The present invention can automatically parse the PIM model and generate a PSM file, significantly reducing manual intervention and improving development efficiency. Through the tool-based parsing and generation process, various errors can be accurately captured and processed. Combining the functions of TAO and OpenDDS, the implementation of remote method calls and data distribution is simpler. Through service-oriented applications, resources in the test platform can be efficiently managed and scheduled through a distributed system, supporting large-scale distributed deployment and remote control of resources.

[0061] The technical solution of the present invention is described below by way of example in four parts:

[0062] 1. Source file analysis:

[0063] Figure 4 This is the overall activity diagram of the object model compilation tool, which explains the entire process of the object model compilation tool to fully compile a TDL file. The object model compilation tool first parses the TDL file. If the parsing is unsuccessful, the compilation ends. If the parsing is successful, all state distribution object nodes are found from the abstract syntax tree, and the corresponding C++ code files are generated for the content of each node.

[0064] The process of TDL file parsing is as follows Figure 5 As shown. After the lexical analysis, syntax analysis, and semantic analysis are completed, the error table will be checked. If the error table is empty, the next step will be continued. If the error table is not empty, the flag indicating that the TDL file parsing is unsuccessful will be returned immediately, and the compilation will end.

[0065] The object model compilation tool does not need to correct the TDL file with errors, but only compiles the correct TDL file. The tool requires the error handling part to terminate the compilation process if an error is found. The other three parts of the TDL file parsing process are:

[0066] 1. Lexical Analysis

[0067] Lexical analysis is the analysis of source files at the character level. Figure 6 This is the lexical analysis process. This part inputs a character stream object (the character stream object stores all the characters of the source file), outputs a word list, and generates lexical error information. The process is relatively simple. It analyzes the characters one by one to determine whether a new word needs to be generated until all the characters in the character stream object are analyzed. Among them, the most critical is the word structure design. For the case where the word consists only of a string, by adding a type attribute, a simple judgment is made on the type of the string while splitting out a string, thereby reducing the workload of grammatical analysis. In addition, in order to facilitate the locking of the location where the lexical error occurs, the number of rows and columns attributes are added to the word.

[0068] The processing flow of lexical analysis on a single character is shown in Table 1.

[0069] Table 1 Single character processing flow

[0070]

[0071] The special symbols recognized by this process include "space", "{", "}", "*", "<", ">", "," ",";", "(", ")", "tab", " / ", ";", etc., which need to be processed differently. Create a new word of symbol type according to the content of the symbol, and extract the string from the previous symbol to the symbol. Create a new word of identifier type or a new word of keyword type according to the content of the string. If an error is found during the processing, create a new error and store it in the error table. The errors that can be recognized by lexical analysis are shown in Table 2.

[0072] Table 2 Lexical error list

[0073]

[0074]

[0075] 2. Syntax Analysis

[0076] Syntax analysis is the most critical and complex in TDL file parsing. For complex computer languages ​​such as C++, in order to implement syntax analysis, it is first necessary to design a grammar that can fully describe the computer language. Among various grammars, the most commonly used is the top-down LL(1) grammar. Studies have found that the workload of designing a compiler tool using the LL(1) grammar is too large, while the syntax of the TDL language, the analysis object of the present invention, is relatively simple and can be analyzed using ordinary programming. Figure 7 It is the process of grammatical analysis.

[0077] The most critical work of syntax analysis is to generate an abstract syntax tree. By grouping word sequences, the words are divided into multiple nested combinations from large to small. Tree nodes are created from the outermost combination. A group of word sequences corresponds to a tree node, and the nested tree nodes are the child nodes of the outer tree nodes. The design of the tree node generation steps is shown in Table 3.

[0078] Table 3 Abstract syntax tree node generation steps

[0079]

[0080] This step judges the i-th word C[i] in the word list C. If the word C[i] is a keyword in a certain object metamodel definition, it will enter the corresponding definition processing subroutine. The definition processing subroutine analyzes whether the declaration of the module is correct, continues to read the words in the word list, and judges whether the word after the word "{" is a new definition block. If so, recursively call this step, enter the new definition processing subroutine for processing, and end the subroutine after recognizing the word "}" and the word ";". Since module definition errors will affect the judgment of subsequent words, when the definition processing subroutine finds a syntax error, it immediately returns false and terminates the syntax analysis. The variable i is passed as a parameter to each definition subroutine. The definition subroutine starts reading words from C[i] in the word list. i increases with the number of words read. When the definition subroutine completes the analysis of the definition block, the variable i will also be moved to the last word of the definition block, thereby ensuring that C[i] of each input step is the starting position of the next object metamodel definition. If word C[i] is not a keyword in the object metamodel definition, it means that there is an error in the position of word C[i] in the TDL file, and an error status is returned. The definition processing subroutine includes a package definition processing subroutine, a state distribution object class definition processing subroutine, a local class definition processing subroutine, a message definition processing subroutine, a vector definition processing subroutine, an interface definition processing subroutine, an enumeration definition processing subroutine, an exception definition processing subroutine, a state distribution object pointer definition processing subroutine, an operation definition processing subroutine and an attribute definition processing subroutine, which judges the TDL definition and generates a package node, a state distribution object class node, a local class node, a message node, a vector node, an interface node, an enumeration node, an exception node, a state distribution object pointer node, an operation node, and an attribute node.

[0081] When creating tree nodes such as packages, state distribution object classes, messages, local classes, enumerations, exceptions, interfaces, etc., the definition of the object metamodel is stored in the symbol table to prepare for determining the data type of the attribute in semantic analysis.

[0082] The keywords of syntax analysis are "package", "class", "local", "message", "enum", "vector", "interface", "in", "out", "inout", "readonly", "private", "oneway", "*", etc. According to the keywords, different definition processing subroutines are entered. If the processing subroutines find errors, new errors are created and stored in the error table, the definition processing subroutines are immediately terminated, the flag representing the processing error is returned, and the compilation is terminated. The errors that can be identified by syntax analysis are shown in Table 4.

[0083] Table 4 Syntax error list

[0084]

[0085]

[0086] 3. Semantic Analysis

[0087] When creating child nodes, the syntax analysis does not consider whether the child nodes are allowed to exist. The semantic analysis adds this part of the processing, such as Figure 8 The following is the process of semantic analysis.

[0088] The semantic analysis traverses the abstract syntax tree and checks each child node. The errors that the semantic analysis can identify are shown in Table 5. The inspection contents of the child nodes are as follows:

[0089] (1) The name of a child node cannot be a keyword in the C++ language, and cannot be repeated with the name of a sibling node.

[0090] (2) If the child node is a package node, only package nodes, state distribution object class nodes, local class nodes, message nodes, enumeration nodes, exception nodes, and interface nodes are allowed to exist under the package node.

[0091] (3) If the child node is a state distribution object class node, only attribute nodes and function nodes are allowed under the class node. Only one parent class is allowed for a class node, and the attributes and functions of all parent classes in the derived hierarchy of the state distribution object class are not allowed to be repeated with the attribute and function definitions of the state distribution object class. The class node is allowed to implement multiple interfaces. If an interface exists, the functions in all interfaces and the functions in all base classes of the interface are not allowed to be repeated with the function definitions of the state distribution object class. The same attribute names are considered duplicates, and the same function signatures are considered duplicates.

[0092] (4) If the child node is a local class node, only attribute nodes and function nodes are allowed under the local class node. There is only one parent class allowed for a local class node, and the attributes and functions of all parent classes of the local class in the derived hierarchy are not allowed to be repeated with the attributes and function definitions of the local class.

[0093] (5) If the child node is a message node, only attribute nodes and function nodes are allowed under the message node. Only one parent class of a message node is allowed, and the attributes and functions of all parent classes in the derived hierarchy of the message are not allowed to be repeated with the attribute and function definitions of the message.

[0094] (6) If the child node is an enumeration node, no child nodes are allowed under the enumeration node. Enumeration definition variables are not allowed to conflict with the names of sibling nodes.

[0095] (7) If the child node is an abnormal node, only attribute nodes are allowed to exist under the abnormal node.

[0096] (8) If the child node is an interface node, only function nodes are allowed under the interface node and the number of child nodes cannot be empty. The parent class interface of the interface node can have multiple interfaces, and the functions of all parent classes in the derived hierarchy of the interface cannot be repeated with the function definition of the interface.

[0097] (9) If the child node is an attribute node. No child nodes are allowed under an attribute node. If an attribute node has a modifier, its parent node is judged. The "IN", "OUT", and "INOUT" modifiers correspond to function nodes, and the "private" and "readonly" modifiers correspond to local class nodes and message nodes. The type of the attribute is judged, and its type must be found in the symbol table.

[0098] (10) If the child node is a function node, only attribute nodes are allowed under the function node.

[0099] Table 5 List of semantic errors

[0100]

[0101]

[0102] 2. Target file generation:

[0103] In order to realize the automatic generation of target files, first of all, it is necessary to study the mapping rules from TDL to target language, and then design the generation method of target files. That is, convert part of TDL into IDL, and use Open_DDS and TAO's IDL compiler to generate part of PSM files; convert other TDL into C++ code.

[0104] 1. Mapping rules between TDL and IDL

[0105] The mapping rules from TDL expression of object metamodel to IDL expression are designed as follows.

[0106] (1) Package

[0107] "Package" represents a namespace in TDL language, and its meaning is the same as "module" in IDL language, so in IDL files, "package" is replaced by "module".

[0108] TDL definition: package<package name>;

[0109] IDL definition: module <package name>;

[0110] (2) State distribution object class

[0111] There is no definition similar to the state distribution object class in the IDL language, so the state distribution object class is split, and the state attributes in the state distribution object class are merged into a "structure" and the operations are merged into an "interface".

[0112] TDL Definition:

[0113] class<state distribution object class name>{

[0114] / / Status attribute definition;

[0115] / / Operation definition;

[0116] };

[0117] IDL definition:

[0118] struct<state distribution object class name>Attributes{

[0119] / / Status attribute definition;

[0120] };

[0121] interface<state distribution object name>Methods{

[0122] / / Operation definition;

[0123] };

[0124] (3) Local class

[0125] The operations in the local class exist locally and do not participate in remote calls. Its methods do not need to be considered during the splitting process, so the local class is converted to a "structure".

[0126] TDL Definition:

[0127] local class<local class name>{

[0128] / / Status attribute definition;

[0129] / / Operation definition;

[0130] };

[0131] IDL definition:

[0132] struct<local class name>Attributes{

[0133] / / Status attribute definition;

[0134] };

[0135] (4) Message

[0136] The structure of a message is similar to that of a local class, so a message is also converted to a "structure".

[0137] TDL Definition:

[0138] message<message name>{

[0139] / / Status attribute definition;

[0140] / / Operation definition;

[0141] };

[0142] IDL definition:

[0143] struct<message name>

[0144] Attributes{

[0145] / / Status attribute definition;

[0146] };

[0147] (5) Vector

[0148] "Vector" is a dynamically changing array definition, similar to "sequence" in IDL language, so convert "vector" to "sequence".

[0149] TDL Definition:

[0150] vector<type><vector name>;

[0151] IDL definition:

[0152] typedefsequence <type><alias name>;

[0153] <alias name><vector name>;

[0154] (6) Interface

[0155] The "interface" in TDL is similar to the "interface" in IDL language. The difference between them lies in the description of the base interface.

[0156] TDL Definition:

[0157] interface<interface name>:extends<base interface name>{

[0158] / / Operation definition;

[0159] };

[0160] IDL definition:

[0161] interface<interface name>:<base interface name>{

[0162] / / Operation definition;

[0163] };

[0164] (7) Enumeration

[0165] An "enum" in TDL is defined the same way as an "enum" in IDL.

[0166] TDL Definition:

[0167] enum<enumeration name>{

[0168] / / Enumeration variables,

[0169] };

[0170] IDL definition:

[0171] enum<enumeration name>{

[0172] / / Enumeration variables,

[0173] };

[0174] (8) Fundamental Types

[0175] The basic types in TDL can be used in IDL, and the basic types are not changed during the conversion.

[0176] (9) Operation

[0177] Since IDL also requires that the parameters in the operation must specify the direction, the operation in TDL is not changed in the conversion.

[0178] (10) Inheritance

[0179] Since the state distribution object class is split into a "structure" and an "interface" in IDL, and the IDL files of each state distribution object class are generated independently and cannot access each other, when the state distribution object class has an inheritance relationship, the state attribute definition of the parent class is inserted into the "structure" of the state distribution object class, and the operation definition of the parent class is inserted into the "interface" of the state distribution object class.

[0180] Local classes and messages are mapped to "structure" in IDL, so the treatment of their inheritance relationships is the same as that of state distribution object classes.

[0181] (11) Implement

[0182] After the state distributed object class implements an interface, it inherits the operations in the interface. When the state distributed object class is mapped to IDL, all operations are defined as an interface. Therefore, when the state distributed object class has an implementation relationship, the following mapping is performed.

[0183] TDL Definition:

[0184] class<state distribution object class name>:implements<interface name>{

[0185] / / Operation definition;

[0186] };

[0187] IDL definition:

[0188] interface<state distribution object class name>Methods:<interface name>{

[0189] / / Operation definition;

[0190] };

[0191] Since there is no definition corresponding to the state distribution object class and exception in IDL, the IDL expression of the state distribution object class pointer and exception is not considered.

[0192] 2. Mapping rules between TDL and C++

[0193] The mapping rules between the TDL expression and the C++ expression of the object metamodel are designed as follows.

[0194] (1) Package

[0195] The meaning of "package" in TDL language is the same as "namespace" in C++ language, so in C++ files, "package" is replaced by "namespace".

[0196] TDL definition: package<package name>;

[0197] C++ definition: namespace <package name>;

[0198] (2) State distribution object class

[0199] The concept of a state distribution object class is similar to a "class" in C++, so in a C++ file, the state distribution object class is defined as a "class".

[0200] TDL Definition:

[0201] class<state distribution object class name>{

[0202] / / Status attribute definition;

[0203] / / Operation definition;

[0204] };

[0205] C++ definition:

[0206] class<state distribution object class name>{

[0207] / / Status attribute definition;

[0208] / / Operation definition;

[0209] };

[0210] (3) Fundamental Types

[0211] The mapping relationship between basic data types in TDL and C++ is shown in Table 6.

[0212] Table 6 Mapping of basic data types

[0213]

[0214]

[0215] (4) State distribution object class pointer

[0216] The state distribution object class pointer is described with "*" in both TDL and C++.

[0217] TDL Definition:

[0218] <state distribution object class name>*<attribute name>;

[0219] C++ definition:

[0220] <state distribution object class name>*<attribute name>;

[0221] The C++ definitions of local classes, messages, vectors, interfaces, and enumerations are obtained by compiling IDL files with the IDL compiler, and their mapping relationships will not be designed here.

[0222] 3. Target file generation

[0223] The target file is generated, that is, the IDL file (application) is converted into a PSM file (application). In the joint test platform, the applications that make up the test system do not communicate directly, but interact through the agent and server of a specific state distribution object. The network communication function of the application is implemented by TAO (The ACE ORB, TAO) and OpenDDS (Data Distribution Service, DDS). Therefore, the present invention instantiates the state distribution object as an agent and a server in two files, and uses TAO and DDS to complete data transmission to achieve target file generation.

[0224] 3.1 Instantiated as a broker and a server:

[0225] The state distribution object consists of an object interface and a published state. The object interface is location transparent, and the published state is a collection of all the properties of the object. The server is the owner of the state distribution object, can modify the properties of the state distribution object, and provide the implementation of the state distribution object's operations; the agent is the reference of the state distribution object, receives the latest data of the state distribution object's properties, and can access the object interface on the server to access the state distribution object's operations, such as Fig. 9 shown.

[0226] 3.2 Data Transmission:

[0227] The data transmission methods in the experimental system are divided into two mechanisms: "push" and "pull". The application updates the properties of the state distribution object through the server, and the agent passively receives the new data and notifies the application where it is located, which is "push"; the application actively calls the object interface of the state distribution object through the agent to access the implementation of the operation on the server, which is "pull". The server and agent of each state distribution object can exist in different applications on different nodes. The same application can have multiple servers and agents of the state distribution object, such as Fig.10 As shown in the code, the instantiation of servers and agents is the same as the creation of class objects in C++ syntax. State distribution objects may contain local class members or message members. Therefore, the running state of state distribution objects can be divided into three situations: remote method calls, state attribute publishing, and local method calls.

[0228] (1) TAO implements remote method call

[0229] TAO requires users to use IDL files to describe their remote methods, and then use the IDL compiler provided by TAO to compile the IDL files. Finally, use the client files and server files output by the IDL compiler to develop programs. TAO ensures the standardization of the remote method call process through the IDL compiler. The IDL compiler can generate client files and server files in multiple languages ​​such as C++ and Java. TAO hides the TAO interface through client files and server files, separating user code from the underlying communication layer. The process of using TAO to develop applications to implement remote method calls is as follows: Fig.11 shown.

[0230] First, the user needs to design the remote methods, define them in an interface (assuming the interface name is Calculate) and write them into an IDL file, assuming the Test.idl file, and then call the TAO_IDL compiler to compile the IDL file. The compiler will output files such as TestC.h, TestC.cpp, TestC.inl, TestS.h, TestS.cpp, and TestS.inl. As the party calling the remote method, that is, the Client application, it only needs to include files such as TestC.h, TestC.cpp, and TestC.inl; as the party being called, that is, the Servant application, it needs to include all files. At the same time, when writing the code, a class must be derived from the abstract class POA_Test::Calculate defined in the TestS.H file, overload the method that needs to be called remotely in the abstract class, and fill in the implementation of the method, so as to ensure that the Client can access the implementation of the method.

[0231] (2) Open_DDS implements data distribution

[0232] OpenDDS is an open source real-time communication middleware developed on the basis of TAO, which supports data subscription and publication in the form of topics. It follows the idea of ​​IDL compilation of TAO, requiring users to use IDL files to describe the data to be published, and then use OpendDDS_IDL compiler and TAO_IDL compiler to compile the IDL files in turn, and finally use the files output by the IDL compiler for program development. Assuming that the IDL file written by the user is named Attribute.idl, after being compiled by the IDL compiler, the user will get the following five sets of files.

[0233] 1)AttributeC.h, AttributeC.cpp, AttributeC.inl;

[0234] 2)AttributeS.h, AttributesS.cpp, AttributesS.inl;

[0235] 3)AttributeTypeSupportC.h, AttributeTypeSupportC.cpp,

[0236] AttributeTypeSupportC.inl;

[0237] 4)AttributeTypeSupportS.h, AttributeTypeSupportS.cpp,

[0238] AttributeTypeSupportS.inl;

[0239] 5)AttributeTypeSupportImpl.h, AttributeTypeSupportImpl.cpp;

[0240] As the party receiving the data, that is, the client application, it is necessary to include 1), 3), and 5) files. At the same time, when writing the code, it is necessary to start from LocalObject <dds::datareaderlistener>This abstract class derives a class that overrides the on_data_available function in the abstract class to ensure that the Client can receive data. As the party that publishes data, the Servant application, it needs to include all files.

[0241] (3) Local call

[0242] During the local method call process, the local method implementation exists in the proxy and server of the state distribution object. When the user writes code to call the local method interface of the proxy or server, the local method implementation is directly accessed without network consumption.

[0243] 3.3 Target file generation process:

[0244] Table 7 is the flow chart of design code file generation.

[0245] Table 7 Target file generation process

[0246]

[0247]

[0248] The generation process of IDL files, client class files, and server class files must strictly comply with the mapping rules from TDL to IDL and C++.

[0249] 3. Interface design:

[0250] like Fig.12 The figure shows the interface diagram between this software and the TENA system.

[0251] The object model compilation tool provides resource modeling results (object model) to the outside in TDL file format. The TDL file is used as the input file of the object model compilation tool, and the object model compilation tool compiles the TDL file. The object model compilation tool compiles the TDL file to generate the object model implementation file, which is provided to the resources of the joint test platform as the basic support during the operation stage.

[0252] 4. Implementation plan:

[0253] Fig.13 This is the interface of the object model compilation tool. The user clicks the button to select the path of the TDL file and the output path of the object model definition file and the object model implementation file. Click the Compile button to start the compilation. The object model compilation tool compiles the TDL file and displays the compilation result in the edit box in the lower right corner.

[0254] The compilation results and their meanings are shown in Table 8.

[0255] Table 8 Compilation results and significance

[0256] Compilation results The information represented by the results 0 TDL file compiled successfully -1 TDL file parsing failed -2 The generation of the IDL file describing the state attributes failed -3 Generation of the IDL file describing the remote method failed -4 IDL file compilation failed -5 Client class file generation failed -6 Server class file generation failed

[0257] Table 9 is the final implementation result. The relevant use cases generated by compilation are the target files - PSM files.

[0258] Table 9 Parsing and compiling files

[0259]

[0260]

[0261] The object model PIM to PSM automatic generation method provided by the present invention can complete the parsing of TDL files through designing programs, specifically including lexical analysis, syntax analysis, and semantic analysis, and convert the source file into a data structure recognizable by a computer. For the parsed file, one part uses TAO to implement remote method calls and Open_DDS to implement data distribution, and the IDL compiler of Open_DDS and TAO generates a PSM file; the other part is directly converted into C++ code to complete the automatic generation of the target file. Finally, the object model compilation tool was tested to verify the reliability and efficiency of the tool.

[0262] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0263] The above description of the disclosed embodiments enables one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.< / dds::datareaderlistener>

Claims

1. A method for automatically generating an object model PIM to PSM, characterized in that: The following steps are involved: S10, parsing the TDL file of the PIM model through the object model compilation tool to complete lexical, grammatical and semantic analysis; S20, converting the PIM model into an IDL file and C++ code according to the parsing result of the TDL file; S30, using the IDL compiler provided by OpenDDS and TAO to compile the IDL file, and combining the C++ code to generate the platform-related model PSM file; S40, deploying the generated PSM file to the test platform to realize the service-oriented application of the test resources.

2. The method for automatically generating an object model PIM to PSM according to claim 1, characterized in that: The step S10 further includes: after the lexical, grammatical and semantic analyses are completed, respectively checking the corresponding error tables; when the error table is not empty, terminating the compilation.

3. The method for automatically generating a PSM from an object model PIM according to claim 1, characterized in that: In step S10, lexical analysis includes: Read the contents from the TDL file character by character, identify the keywords, symbols and identifiers in the file, and generate a word list and a lexical error table.

4. The method for automatically generating an object model PIM to PSM according to claim 3, characterized in that: In step S10, the syntax analysis includes: Based on lexical analysis, the word list is converted into an abstract syntax tree; According to the predefined TDL grammar rules, keywords and symbols are combined into grammatical structures to form a hierarchical grammar tree; Duplicate declarations, missing semicolons, base class or interface definition errors are identified and recorded in the syntax error table.

5. The method for automatically generating an object model PIM to PSM according to claim 4, characterized in that: In step S10, the semantic analysis includes: Check whether each node in the abstract syntax tree complies with the defined semantic rules, ensure that the definition in the PIM model complies with the semantic logic, and generate a semantic error table; the defined semantic rules include: Check for conflicts in class, package, attribute, and method names; Verify the legitimacy of inheritance relationship; Checks that data type definitions can be found in the symbol table, ensuring that each identifier has a defined type.

6. The method for automatically generating an object model PIM to PSM according to claim 1, characterized in that: The step S20 comprises: According to the parsing results of the TDL file, the classes, attributes and methods in the PIM model are converted into structures and interfaces in the IDL file according to the predefined TDL and IDL mapping rules; The state distribution object class, basic data types and state distribution object class pointers in the PIM model are converted into C++ codes according to the predefined TDL and C++ mapping rules.

7. The method for automatically generating an object model PIM to PSM according to claim 1, characterized in that: The step S30 comprises: Use TAO's IDL compiler to compile the IDL file, combine it with the C++ code, generate client class files and server class files; define the server interface and implement the logic of remote call; Use OpenDDS_IDL compiler to compile IDL files and generate C++ class files for data distribution, including: generating status attribute definition client class files, generating remote method interface class files, generating status attribute definition server class files, and generating remote method implementation abstract class files; define data distribution type support classes and data monitoring classes to implement data subscription and publishing.

8. The method for automatically generating an object model PIM to PSM according to claim 1, characterized in that: The step S40 comprises: Deploy the generated PSM file to the test platform, and realize the management and operation of resources in a distributed environment through the interaction between the agent and the server; During deployment, the servers will be distributed on different test platform nodes to provide control and modification of test resources; The agent receives the latest state of the object and accesses the operations provided by the server through remote calls, synchronizing the data and state between different nodes in the test platform; Through the collaborative work of agents and servers, experimental resources are transmitted between different platform nodes, remote method calls and data synchronization are achieved, and ultimately a service-oriented application is formed.

Images