Module plug-in communication method and system based on QT

Abstract

The invention provides a QT-based module plug-in communication system and a QT-based module plug-in communication method. The QT-based module plug-in communication system comprises a UDP (User Datagram Protocol) communication module for providing a message communication function based on a network card for software; the model data processing module is used for providing full-life-cycle model data for the software; the plug-in management module can load different types of plug-ins; and the plug-in module is used for coding implementation by a user according to the service and generating a plug-in. The invention provides a QT-based module plug-in communication method, which is used for solving the problems of complicated coding, difficulty in collaborative development and low code reusability.

Description

Technical Field

[0001] The present invention relates to the technical field of system software integration, and in particular to a QT-based modular plug-in communication method and system. Background Art

[0002] In the military industry, demand is uncertain, so projects need to frequently add or modify UI and functions. In addition, the project cycle is short and the iteration is fast, so project development requires an efficient framework that can be tailored, reused, loosely coupled, and developed synchronously. Due to the localization requirements, QT has become the preferred development tool.

[0003] QT itself provides an API for creating plug-ins, which need to be integrated into the main program to run. Modules with relatively independent functions can be generated as plug-ins, and the main program can load, call, and unload plug-ins as needed.

[0004] Normally, plugins are decoupled and should not call each other. Instead, the main program calls plugins to process data. However, in reality, there are scenarios where data sharing between plugins is required. In this case, it is necessary to consider efficient, convenient, and unified communication methods between plugins.

[0005] The commonly used method of communication between plug-ins is to transfer data from plug-in A to plug-in B through the main program. This method requires developers to implement abstract interfaces and abstract classes, as well as plug-in management and data forwarding of the main program. This method has a large coding workload, is difficult to develop collaboratively, and has low code reusability. Summary of the invention

[0006] In view of the defects in the prior art, the object of the present invention is to provide a QT-based modular plug-in communication method and system.

[0007] A QT-based modular plug-in communication system provided by the present invention includes:

[0008] UDP communication module: provides network card-based message communication function for the software;

[0009] Model data processing module: provides model data throughout the entire life cycle for the software;

[0010] Plugin management module: capable of loading different types of plugins;

[0011] Plug-in module: Users implement coding based on business needs and generate plug-ins.

[0012] Preferably, in the UDP communication module:

[0013] The UDP communication module uses the UDP protocol to transmit data at the bottom layer, and users can perform visual configuration through XML files;

[0014] The network module configures the IP and receiving port of the current plug-in UDP communication and the message type it monitors;

[0015] The mapping module configures the transmitter and receiver of the current plug-in. The transmitter includes the transmitted data format, destination IP and port, and the receiver includes the parsing rules after receiving the data. The mapping module maps the data of the model module and the packet module.

[0016] The packet module is the format of the message transmitted between plugins, including the message header and data segment;

[0017] The UDP communication module meets the following requirements:

[0018] Support XML file to describe general message definition, data types include uint, int, double, bool;

[0019] The general message definition meets the following requirements: the field supports default value settings; supports byte alignment; supports the definition of fixed-length or variable-length messages; supports XML file description of string message definitions, including variable-length strings QString; supports network monitoring configuration based on XML files;

[0020] Among them, the network monitoring configuration meets the following requirements: supports the configuration of local sending IP address and port number; supports two-way binding of message models, allowing the received data to be directly updated to the model, allowing the data in the model to be directly converted into binary streams and sent out, meeting the following requirements:

[0021] Data binding from message to model: supports mapping received data to the model through XML file description;

[0022] Data binding from model to message: supports directly mapping the data in the model to the message model description through XML files and sending it through network configuration;

[0023] Support sending model filled default values;

[0024] Data sending and receiving supports packet processing.

[0025] Preferably, in the model data processing module:

[0026] Replace the data structure in the C programming language, support XML files for modeling, and support data storage;

[0027] The model data processing module meets the following requirements:

[0028] Supports modeling of basic data types, including char, int, uint, double, and bool;

[0029] Supports proprietary data types including quint8, qint8, bool, double; supports indefinite length string QString;

[0030] Supports data type modeling, including date, time, datetime, rect; supports data types including QDateTime, QDate, QTime;

[0031] Supports modeling of basic container data types: Supports complex container types including: std::list, std::vector, std::map;

[0032] Supports the combination and nesting of data types, and supports more complex business models through combination and nesting;

[0033] Supports model data storage and provides model data throughout the entire life cycle.

[0034] Preferably, in the plug-in management module:

[0035] Perform integrity check and forwarding on data, where the data refers to the definition and business-related content, which is data that needs to be transferred between two or more plug-ins;

[0036] The plug-in management module meets the following requirements:

[0037] Supports this plug-in to be referenced and called by other plug-ins; supports management of background service plug-ins; supports management of plug-ins with interfaces; supports data interaction between plug-ins; supports arbitrary layout of plug-ins; supports plug-in snapshot configuration, and the program can be restored to the state when the user last exited the next time it is started;

[0038] The plug-in module customizes the data model XML file; the loading and layout of the plug-in are based on the existing low-level API of QT5 and are loaded in a dynamic loading manner;

[0039] Use UDP communication to allow plugins on different machines to interact and separate the front-end and back-end.

[0040] The data interaction of the plug-in is UDP communication, business data parsing based on XML format, and format conversion between business data and messages.

[0041] Preferably, in the plug-in module:

[0042] Custom data model files are created and generated by developers according to the agreed model format. The requirements for the content of the XML format configuration file are as follows:

[0043] The XML file model module is supported to model the services in the system. Correct configuration of this file will ensure the flexibility of the system. The node requirements in XML are as follows:

[0044] The XML root node contains a name attribute, which indicates the model name;

[0045] The root node contains at least one attribute node, which consists of multiple attribute and model nodes, and the data model is described by the attribute and model nodes;

[0046] The attribute node describes each child of the data model and contains the following attributes: node name, data type, default value or model reference;

[0047] Model nodes abstract data model structures. There are at least 0 model nodes and at most unlimited model nodes. Model nodes contain multiple attribute nodes, or contain multiple model nodes to form a recursive nested relationship. Model nodes contain the following attributes: node name and key.

[0048] Support XML file packet module to model data packet messages; the node requirements in XML are as follows:

[0049] Message attributes include: ID, name, byte alignment and message header ID;

[0050] The message sub-node is a field, which is a specific data structure of the data packet and is defined according to the field order of the data packet; the field contains attributes: attribute name, type, and default value;

[0051] Support XML file network module to bind received data packets with packet module; the node requirements in XML are as follows:

[0052] UDP node attributes include: IP address, port;

[0053] The message ID is a child node of the UDP node. The message ID is one or more. The value of the message ID is the message ID in the packet module.

[0054] Support XML file mapping module to bind the message in the packet module and the node in the model module; the node requirements in XML are as follows:

[0055] Mapping attributes include name;

[0056] Configure the sender or receiver under the mapping; under the same mapping, the sender and receiver can be freely combined;

[0057] The sender and receiver attributes include the message ID;

[0058] Configure UDP and mapping nodes on the sender and receiver;

[0059] UDP attributes include ip and port;

[0060] Configure one or more mapping subnodes under the mapping node;

[0061] The mapping subnode attributes include the message attribute name and the model node name.

[0062] According to a QT-based modular plug-in communication method provided by the present invention, the QT-based modular plug-in communication system is used to perform the following steps:

[0063] Step S1: configure the plug-in module business model and implement business coding;

[0064] Step S2: Configure plugin loading, data integrity verification and data forwarding in the plugin management module;

[0065] Step S3: Analyze, store and forward the business model by configuring the model data processing module;

[0066] Step S4: configure the UDP communication module to send the business model data in a message format, and parse the received message.

[0067] Preferably, in step S1:

[0068] The business model is defined by the developer in XML format for data structure generation; XML format message configuration and the mapping relationship between the message and the data model are defined for data sharing between different plug-ins in the same program or between different plug-ins in different programs; XML format network configuration is defined to determine the address information of the sender and the receiver;

[0069] It is necessary to configure the business model and implement business coding. The business coding is encoded according to the actual business needs. The developer configures the business model according to the rules. The specific configuration is as follows:

[0070] Developers define model modules based on business models. The model modules contain data structures that need to exist throughout the software life cycle. They are used to share and access data between different plug-ins during the software life cycle. The software life cycle refers to the running time of the main program.

[0071] The developer defines the packet module according to the actual application scenario. Its content is the data message protocol format, which is used to determine the filling of the UDP message when sending and the parsing of the UDP message when receiving.

[0072] The developer defines the network module according to the actual application scenario. Its content is the local IP address and port number of the receiving end, as well as the message ID corresponding to the required message format for parsing the received message.

[0073] Developers define mapping modules based on business models and actual application scenarios. The content of the mapping module is divided into two parts:

[0074] Sender mapping: defines the destination IP address and port number of the receiving end of the message sent by the local machine; defines the binding relationship between the model node name and the message attribute name. After the two are bound, when sending the message, the value of the model node name is assigned to the message attribute name, and sent to the receiving end of the specified destination IP address and port through the UDP communication module; the model node name comes from the model module, and the message attribute name comes from the packet module;

[0075] Receiving end mapping: The receiving end refers to the local machine, which defines the IP and port of the local UDP listening, as well as the message ID; defines the binding relationship between the message attribute name and the model node name. After the two are bound, when the message with the specified message ID is received, the value of the message attribute name is assigned to the model node name, which is used to update the full life cycle data structure stored in the aforementioned model data processing module for synchronous update and access by all plug-ins; the message attribute name comes from the packet module, and the model node name comes from the model module.

[0076] Preferably, in step S2:

[0077] The plug-in loading includes loading, calling and unloading the plug-in; the data integrity check is to check the integrity of the plug-in including the interface, data and configuration file; the data forwarding is to forward the processed model data to the plug-in module, or to forward the data to be processed of the plug-in module to the model data processing module;

[0078] The plug-in management module needs to be configured to load different types of plug-ins. The startup process of this module requires an integrity check of the plug-in interface, data, and configuration files. Incorrect plug-ins will not be loaded.

[0079] It can realize arbitrary dynamic separation layout of plug-ins in the same screen without restarting the application; it can make plug-ins referenced and called by other plug-ins; it can manage background service plug-ins; it can interact with plug-ins; it can make plug-ins have arbitrary layout; it can configure snapshots of plug-ins so that the next time the program is started, it can be restored to the state when the user last exited;

[0080] The loading and layout of plugins are based on the existing low-level API of QT5, and are loaded dynamically. UDP communication is used to enable plugins on different machines to interact and separate the front-end and back-end.

[0081] The data interaction of the plug-in is UDP communication, which is based on the business data parsing in XML format and the format conversion between business data and messages;

[0082] Snapshot configuration means pausing the plug-in process, keeping the data cache in the plug-in, and suspending the data interaction between the plug-in and other plug-ins;

[0083] Any layout of the window can be split or zoomed up and down, left and right; the processed model data is forwarded to the plug-in module, or the data to be processed of the plug-in module is forwarded to the model data processing module.

[0084] Preferably, in step S3:

[0085] The business model is a data structure in XML format defined by the developer; the purpose of the storage is to provide model data for the software throughout its life cycle; the forwarding is to forward the processed model data to the UDP communication module or the plug-in management module;

[0086] It is necessary to configure the model data processing module to realize the parsing, storage and forwarding of the business model; the business model is the data structure of the business model; the purpose of the storage is to store the model data and provide the model data of the whole life cycle for all plug-ins; the forwarding is to forward the processed model data processed according to the mapping relationship of the mapping module to the UDP communication module in the form of a message, or to the plug-in management module in the form of model data;

[0087] After the business data is converted into the data structure in the model module, it is mapped to the message in the packet module through the mapping module, and then sent to the specified target plug-in through the UDP communication module;

[0088] First, the data is stored in the plug-in that generates the business data. After the data is sent to the target plug-in, the target plug-in stores it as needed, and the source plug-in can continue to store or delete it as needed.

[0089] The storage format is the data structure defined in the model module;

[0090] The model data of the life cycle will continue to store the business data in the format defined in the model module until the plug-in ends.

[0091] Preferably, in step S4:

[0092] The message format is a message configuration in XML format defined by the developer; the sending of the business model data in the message format refers to sending the message according to the defined receiving end address; the parsing of the received message refers to parsing the received message according to the message format according to the binding relationship between the local port and the message ID, and forwarding it to the model data processing module for processing and storage, and then forwarding it to the plug-in management module by the model data processing module, which notifies all plug-ins subscribed to the data message to update the data;

[0093] Configure the UDP communication module, send the model data in the message format, and parse the received message. The message format is the packet module content;

[0094] Send the model data in the message format, specifically:

[0095] Send the message data according to the destination IP address and port set in the mapping module;

[0096] The parsing of the received message is specifically as follows:

[0097] According to the message ID bound to the local port number in the network module, find the corresponding message format in the packet module and parse the received message;

[0098] Forward the parsed message to the model data processing module

[0099] Based on the parsing operation of the received message, the subsequent processing is as follows:

[0100] The model data processing module parses the received message according to the format in the mapping module based on the mapping relationship between the message and the data model, processes it into model data, and stores the model data;

[0101] The model data processing module forwards the processed data to the plug-in management module; after receiving the data, the plug-in management module notifies all plug-ins subscribed to the data message to update the data.

[0102] Compared with the prior art, the present invention has the following beneficial effects:

[0103] 1. The present invention provides a QT-based modular plug-in communication method to solve the problems of cumbersome coding, difficult collaborative development and low code reusability.

[0104] 2. The present invention provides a new QT project development structure and integrates three modules therein. After the first implementation, other subsequent projects can reuse it.

[0105] 3. The present invention provides user-friendly and strict API development specifications and standards, namely model.xml, packet.xml, network.xml and mapping.xml. Developers only need to develop according to the specifications and standards provided by the present invention in subsequent project development, which can reduce the difficulty of project development, improve project development efficiency, shorten the project development cycle, and reduce project development costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0106] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0107] Figure 1 It is a structural diagram of the software composition scheme of the present invention;

[0108] Figure 2 It is a flow chart of the modular plug-in communication method of the present invention;

[0109] Figure 3 It is an example of the business model model.xml file;

[0110] Figure 4 It is a packet.xml file instance of the message format;

[0111] Figure 5 An example of a network.xml file in the local receiving end network configuration format;

[0112] Figure 6 This is an example of the gmapping.xml file that shows the mapping relationship between the model and the message. DETAILED DESCRIPTION

[0113] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0114] Embodiment 1:

[0115] The main innovation of this patent is to provide humanized and strict API development specifications and standards, that is, to configure business data through XML files to achieve front-end and back-end separation. The parsing of XML files is processed using the existing standard "XML Schema".

[0116] According to a QT-based modular plug-in communication method provided by the present invention, the QT-based modular plug-in communication system is used to perform the following steps:

[0117] Step S1: configure the plug-in module business model and implement business coding;

[0118] Specifically, in step S1:

[0119] The business model is defined by the developer in XML format for data structure generation; XML format message configuration and the mapping relationship between the message and the data model are defined for data sharing between different plug-ins in the same program or between different plug-ins in different programs; XML format network configuration is defined to determine the address information of the sender and the receiver;

[0120] It is necessary to configure the business model and implement business coding. The business coding is encoded according to the actual business needs. The developer configures the business model according to the rules. The specific configuration is as follows:

[0121] Developers define model modules based on business models. The model modules contain data structures that need to exist throughout the software life cycle. They are used to share and access data between different plug-ins during the software life cycle. The software life cycle refers to the running time of the main program.

[0122] The developer defines the packet module according to the actual application scenario. Its content is the data message protocol format, which is used to determine the filling of the UDP message when sending and the parsing of the UDP message when receiving.

[0123] The developer defines the network module according to the actual application scenario. Its content is the local IP address and port number of the receiving end, as well as the message ID corresponding to the required message format for parsing the received message.

[0124] Developers define mapping modules based on business models and actual application scenarios. The content of the mapping module is divided into two parts:

[0125] Sender mapping: defines the destination IP address and port number of the receiving end of the message sent by the local machine; defines the binding relationship between the model node name and the message attribute name. After the two are bound, when sending the message, the value of the model node name is assigned to the message attribute name, and sent to the receiving end of the specified destination IP address and port through the UDP communication module; the model node name comes from the model module, and the message attribute name comes from the packet module;

[0126] Receiving end mapping: The receiving end refers to the local machine, which defines the IP and port of the local UDP listening, as well as the message ID; defines the binding relationship between the message attribute name and the model node name. After the two are bound, when the message with the specified message ID is received, the value of the message attribute name is assigned to the model node name, which is used to update the full life cycle data structure stored in the aforementioned model data processing module for synchronous update and access by all plug-ins; the message attribute name comes from the packet module, and the model node name comes from the model module.

[0127] Step S2: Configure plugin loading, data integrity verification and data forwarding in the plugin management module;

[0128] Specifically, in step S2:

[0129] The plug-in loading includes loading, calling and unloading the plug-in; the data integrity check is to check the integrity of the plug-in including the interface, data and configuration file; the data forwarding is to forward the processed model data to the plug-in module, or to forward the data to be processed of the plug-in module to the model data processing module;

[0130] The plug-in management module needs to be configured to load different types of plug-ins. The startup process of this module requires an integrity check of the plug-in interface, data, and configuration files. Incorrect plug-ins will not be loaded.

[0131] It can realize arbitrary dynamic separation layout of plug-ins in the same screen without restarting the application; it can make plug-ins referenced and called by other plug-ins; it can manage background service plug-ins; it can interact with plug-ins; it can make plug-ins have arbitrary layout; it can configure snapshots of plug-ins so that the next time the program is started, it can be restored to the state when the user last exited;

[0132] The loading and layout of plugins are based on the existing low-level API of QT5, and are loaded dynamically. UDP communication is used to enable plugins on different machines to interact and separate the front-end and back-end.

[0133] The data interaction of the plug-in is UDP communication, which is based on the business data parsing in XML format and the format conversion between business data and messages;

[0134] Snapshot configuration means pausing the plug-in process, keeping the data cache in the plug-in, and suspending the data interaction between the plug-in and other plug-ins;

[0135] Any layout of the window can be split or zoomed up and down, left and right; the processed model data is forwarded to the plug-in module, or the data to be processed of the plug-in module is forwarded to the model data processing module.

[0136] Step S3: Analyze, store and forward the business model by configuring the model data processing module;

[0137] Specifically, in step S3:

[0138] The business model is a data structure in XML format defined by the developer; the purpose of the storage is to provide model data for the software throughout its life cycle; the forwarding is to forward the processed model data to the UDP communication module or the plug-in management module;

[0139] It is necessary to configure the model data processing module to realize the parsing, storage and forwarding of the business model; the business model is the data structure of the business model; the purpose of the storage is to store the model data and provide the model data of the whole life cycle for all plug-ins; the forwarding is to forward the processed model data processed according to the mapping relationship of the mapping module to the UDP communication module in the form of a message, or to the plug-in management module in the form of model data;

[0140] After the business data is converted into the data structure in the model module, it is mapped to the message in the packet module through the mapping module, and then sent to the specified target plug-in through the UDP communication module;

[0141] First, the data is stored in the plug-in that generates the business data. After the data is sent to the target plug-in, the target plug-in stores it as needed, and the source plug-in can continue to store or delete it as needed.

[0142] The storage format is the data structure defined in the model module;

[0143] The model data of the life cycle will continue to store the business data in the format defined in the model module until the plug-in ends.

[0144] Step S4: configure the UDP communication module to send the business model data in a message format, and parse the received message.

[0145] Specifically, in step S4:

[0146] The message format is a message configuration in XML format defined by the developer; the sending of the business model data in the message format refers to sending the message according to the defined receiving end address; the parsing of the received message refers to parsing the received message according to the message format according to the binding relationship between the local port and the message ID, and forwarding it to the model data processing module for processing and storage, and then forwarding it to the plug-in management module by the model data processing module, which notifies all plug-ins subscribed to the data message to update the data;

[0147] Configure the UDP communication module, send the model data in the message format, and parse the received message. The message format is the packet module content;

[0148] Send the model data in the message format, specifically:

[0149] Send the message data according to the destination IP address and port set in the mapping module;

[0150] The parsing of the received message is specifically as follows:

[0151] According to the message ID bound to the local port number in the network module, find the corresponding message format in the packet module and parse the received message;

[0152] Forward the parsed message to the model data processing module

[0153] Based on the parsing operation of the received message, the subsequent processing is as follows:

[0154] The model data processing module parses the received message according to the format in the mapping module based on the mapping relationship between the message and the data model, processes it into model data, and stores the model data;

[0155] The model data processing module forwards the processed data to the plug-in management module; after receiving the data, the plug-in management module notifies all plug-ins subscribed to the data message to update the data.

[0156] Embodiment 2:

[0157] Embodiment 2 is a preferred example of Embodiment 1, and is used to illustrate the present invention in more detail.

[0158] The present invention also provides a QT-based modular plug-in communication system, which can be implemented by executing the process steps of the QT-based modular plug-in communication method, that is, those skilled in the art can understand the QT-based modular plug-in communication method as a preferred implementation of the QT-based modular plug-in communication system.

[0159] A QT-based modular plug-in communication system provided by the present invention includes:

[0160] UDP communication module: provides network card-based message communication function for the software;

[0161] Specifically, in the UDP communication module:

[0162] The UDP communication module uses the UDP protocol to transmit data at the bottom layer, and users can perform visual configuration through XML files;

[0163] The network module configures the IP and receiving port of the current plug-in UDP communication and the message type it monitors;

[0164] The mapping module configures the transmitter and receiver of the current plug-in. The transmitter includes the transmitted data format, destination IP and port, and the receiver includes the parsing rules after receiving the data. The mapping module maps the data of the model module and the packet module.

[0165] The packet module is the format of the message transmitted between plugins, including the message header and data segment;

[0166] The UDP communication module meets the following requirements:

[0167] Support XML file to describe general message definition, data types include uint, int, double, bool;

[0168] The general message definition meets the following requirements: the field supports default value settings; supports byte alignment; supports the definition of fixed-length or variable-length messages; supports XML file description of string message definitions, including variable-length strings QString; supports network monitoring configuration based on XML files;

[0169] Among them, the network monitoring configuration meets the following requirements: supports the configuration of local sending IP address and port number; supports two-way binding of message models, allowing the received data to be directly updated to the model, allowing the data in the model to be directly converted into binary streams and sent out, meeting the following requirements:

[0170] Data binding from message to model: supports mapping received data to the model through XML file description;

[0171] Data binding from model to message: supports directly mapping the data in the model to the message model description through XML files and sending it through network configuration;

[0172] Support sending model filled default values;

[0173] Data sending and receiving supports packet processing.

[0174] Model data processing module: provides model data throughout the entire life cycle for the software;

[0175] Specifically, in the model data processing module:

[0176] Replace the data structure in the C programming language, support XML files for modeling, and support data storage;

[0177] The model data processing module meets the following requirements:

[0178] Supports modeling of basic data types, including char, int, uint, double, and bool;

[0179] Supports proprietary data types including quint8, qint8, bool, double; supports indefinite length string QString;

[0180] Supports data type modeling, including date, time, datetime, rect; supports data types including QDateTime, QDate, QTime;

[0181] Supports modeling of basic container data types: Supports complex container types including: std::list, std::vector, std::map;

[0182] Supports the combination and nesting of data types, and supports more complex business models through combination and nesting;

[0183] Supports model data storage and provides model data throughout the entire life cycle.

[0184] Plugin management module: capable of loading different types of plugins;

[0185] Specifically, in the plug-in management module:

[0186] Perform integrity check and forwarding on data, where the data refers to the definition and business-related content, which is data that needs to be transferred between two or more plug-ins;

[0187] The plug-in management module meets the following requirements:

[0188] Supports this plug-in to be referenced and called by other plug-ins; supports management of background service plug-ins; supports management of plug-ins with interfaces; supports data interaction between plug-ins; supports arbitrary layout of plug-ins; supports plug-in snapshot configuration, and the program can be restored to the state when the user last exited the next time it is started;

[0189] The plug-in module customizes the data model XML file; the loading and layout of the plug-in are based on the existing low-level API of QT5 and are loaded in a dynamic loading manner;

[0190] Use UDP communication to allow plugins on different machines to interact and separate the front-end and back-end.

[0191] The data interaction of the plug-in is UDP communication, business data parsing based on XML format, and format conversion between business data and messages.

[0192] Plug-in module: Users implement coding based on business needs and generate plug-ins.

[0193] Specifically, in the plug-in module:

[0194] Custom data model files are created and generated by developers according to the agreed model format. The requirements for the content of the XML format configuration file are as follows:

[0195] The XML file model module is supported to model the services in the system. Correct configuration of this file will ensure the flexibility of the system. The node requirements in XML are as follows:

[0196] The XML root node contains a name attribute, which indicates the model name;

[0197] The root node contains at least one attribute node, which consists of multiple attribute and model nodes, and the data model is described by the attribute and model nodes;

[0198] The attribute node describes each child of the data model and contains the following attributes: node name, data type, default value or model reference;

[0199] Model nodes abstract data model structures. There are at least 0 model nodes and at most unlimited model nodes. Model nodes contain multiple attribute nodes, or contain multiple model nodes to form a recursive nested relationship. Model nodes contain the following attributes: node name and key.

[0200] Support XML file packet module to model data packet messages; the node requirements in XML are as follows:

[0201] Message attributes include: ID, name, byte alignment and message header ID;

[0202] The message sub-node is a field, which is a specific data structure of the data packet and is defined according to the field order of the data packet; the field contains attributes: attribute name, type, and default value;

[0203] Support XML file network module to bind received data packets with packet module; the node requirements in XML are as follows:

[0204] UDP node attributes include: IP address, port;

[0205] The message ID is a child node of the UDP node. The message ID is one or more. The value of the message ID is the message ID in the packet module.

[0206] Support XML file mapping module to bind the message in the packet module and the node in the model module; the node requirements in XML are as follows:

[0207] Mapping attributes include name;

[0208] Configure the sender or receiver under the mapping; under the same mapping, the sender and receiver can be freely combined;

[0209] The sender and receiver attributes include the message ID;

[0210] Configure UDP and mapping nodes on the sender and receiver;

[0211] UDP attributes include ip and port;

[0212] Configure one or more mapping subnodes under the mapping node;

[0213] The mapping subnode attributes include the message attribute name and the model node name.

[0214] Embodiment 3:

[0215] Embodiment 3 is a preferred example of Embodiment 1, and is used to illustrate the present invention in more detail.

[0216] The present invention is based on a self-developed software composition scheme and provides a QT-based modular plug-in communication method.

[0217] In one embodiment, Figure 1 As shown, the present invention provides a self-developed software composition solution, including:

[0218] UDP communication module: provides network card-based message communication function for the software;

[0219] Model data processing module: provides model data throughout the entire life cycle for the software;

[0220] Plugin management module: capable of loading different types of plugins;

[0221] Plug-in module: Users implement coding based on business needs and generate plug-ins.

[0222] UDP communication module: When transferring data between different "plug-in management modules" (i.e. between different programs), the udp communication module is used

[0223] Model data processing module:

[0224] 1. Analyze, store and forward the business model

[0225] 2. When transferring data between different "plug-in management modules" (i.e. between different programs), the processed model data (i.e. message data) is forwarded to the "UDP communication module"

[0226] 3. When data is transferred between different plug-ins in the same "plug-in management module" (i.e. in the same program), the processed model data is forwarded to the "plug-in management module"

[0227] Plugin modules:

[0228] 1. Users implement coding according to business needs and generate plug-ins

[0229] 2. User fills in the data model file

[0230] Plugin management module:

[0231] 1. Load the plugin

[0232] 2. Check the integrity of the configuration file

[0233] 3. Forward the model data processed by the "model data processing module" to the "plug-in module"

[0234] 4. Forward the data to be processed by the "plug-in module" to the "model data processing module"

[0235] The UDP communication module, model data processing module and plug-in management module are provided with services by the self-developed framework, and the plug-in module is created and generated by the developer according to the agreed model format.

[0236] The UDP communication module supports XML-based general message definition, XML-based network monitoring configuration, and XML-based message model two-way binding.

[0237] The model module includes:

[0238] Fill in model.xml including: User fill in

[0239] 1. Determine the plug-in name

[0240] 2. According to the business, the data structure that needs to be shared between plug-ins (not necessarily exchanged, just caching of this plug-in is also OK), regardless of sending and receiving

[0241] Reading model.xml includes: This patent implements

[0242] 1. Read the plug-in name and determine whether it matches the current plug-in

[0243] 2. Traverse all attribute nodes, model nodes and their child nodes, store them in the map cache, and establish the association relationship between nodes

[0244] 3. Generate node reading and writing methods for user convenience

[0245] The packet module includes:

[0246] Fill in packet.xml including: User fill in

[0247] 1. Determine the "common message header". In the same system, the message header format should be consistent between plug-ins (different message headers can be configured and distinguished by message ID)

[0248] 2. Define the data structure that needs to be transferred between plug-ins

[0249] 3. Different IDs can be defined as needed to quickly distinguish different data structures. The message IDs in the same file cannot be repeated.

[0250] Reading packet.xml includes: This patent implements

[0251] 1. Get the message ID and message data structure, and store the ID as the key in the map cache

[0252] The network module includes:

[0253] Fill in network.xml including: User fill in

[0254] 1. Determine the UDP listening IP and port of this plug-in. If it is a multi-network card machine, you can configure different ports under different IPs.

[0255] 2. Fill the message ID (except the message header) in packet.xml into the UDP node

[0256] Reading network.xml includes: This patent implements

[0257] 1. Traverse the UDP nodes, obtain the message ID list under the node, and store it in the map cache

[0258] 2. Start the UDP listening service according to the IP and port

[0259] The mapping module includes:

[0260] Fill in mapping.xml including: User fill in

[0261] 1. Define as needed

[0262] 2. Fill in an easily recognizable name for the message being sent

[0263] 3. Determine the data that this plug-in needs to send, fill in the "Message ID" (obtained from packet.xml), "Message attribute name" (obtained from packet.xml) and "Model node name" (model.xml)

[0264] 4. Fill in the UDP listening IP and port of the peer plug-in

[0265] 1. Define the "receiving end" as needed

[0266] 2. Similar to defining the "sender", fill in an easily recognizable name for the message being sent

[0267] 3. Determine the data that this plug-in needs to receive, fill in the "Message ID" (obtained from packet.xml), "Message attribute name" (obtained from packet.xml) and "Model node name" (model.xml)

[0268] 4. Fill in the UDP listening IP and port of this plug-in

[0269] Reading mapping.xml includes: This patent implements

[0270] 1. Traverse the mapping relationship between the sender and the receiver

[0271] 2. Classify the mapping relationship according to the IP and port of the peer plug-in and this plug-in

[0272] 3. Generate the conversion relationship from the sender's "model node name" to the "message attribute name"

[0273] 4. Generate the conversion relationship from "message attribute name" to "model node name" at the receiving end

[0274] 5. When this plug-in sends a message, it obtains the sender message relationship, converts the data defined in model.xml into the message defined in packet.xml, combines the message header and the IP and port of the peer plug-in UDP, and sends the message to the peer plug-in

[0275] 6. When this plug-in receives a message, it obtains the receiving end message relationship, converts the data defined in packet.xml into the message defined in model.xml, and uses QT's signal and slot mechanism to publish the received data to this plug-in for use

[0276] Specifically, the UDP communication module meets the following requirements:

[0277] Support XML files to describe general message definitions, including but not limited to basic data types such as uint, int, double, bool, etc. General message definitions must at least meet the following requirements:

[0278] Fields support default value settings;

[0279] Support byte alignment;

[0280] Supports the definition of fixed-length / variable-length messages.

[0281] Supports XML files to describe string message definitions, including but not limited to variable-length strings QString.

[0282] Supports network monitoring configuration based on XML files. The network monitoring configuration must at least meet the following requirements:

[0283] Supports configuration of local sending IP address and port number.

[0284] Supports two-way binding of message models, allowing the received data to be directly updated to the model, and the data in the model to be directly converted into a binary stream and sent out, at least meeting the following requirements:

[0285] Data binding from message to model: supports mapping received data to the model through XML file description;

[0286] Data binding from model to message: supports directly mapping the data in the model to the message model description through XML files and sending it through network configuration;

[0287] Support sending model filled default values;

[0288] Data sending and receiving supports packet processing.

[0289] The model data processing module can replace the commonly used data structure in the traditional C / C++ programming language, support XML files for modeling, and support data storage, and can solve the problem of high coupling between the human-computer interaction interface and the logic code in the software development process.

[0290] Specifically, the model data processing module meets the following requirements:

[0291] Supports basic data type modeling and can replace the basic types of traditional C / C++ class structure member variables, including but not limited to char, int, uint, double, bool, etc.

[0292] Supports QT-specific basic data types such as quint8, qint8, bool, double, etc.; supports indefinite-length string QString.

[0293] Supports complex data type modeling, and can replace traditional C / C++ class structure member variable complex types, including but not limited to date, time, datetime, rect, etc.; supports QT proprietary QDateTime, QDate, QTime and other complex data types.

[0294] Supports modeling of basic container data types: supports replacing traditional C++ template class container complex types, such as std::list, std::vector, std::map, etc.

[0295] It supports the combination and nesting of basic data types, complex data types and basic container data types, and supports more complex business models through combination and nesting.

[0296] Support model data storage, that is, provide model data throughout the entire life cycle.

[0297] The plug-in management module performs integrity checks on the plug-ins including interface, data, configuration files, etc., and erroneous plug-ins will not be loaded, thereby avoiding adverse effects on system stability. It supports arbitrary dynamic separation and layout of plug-ins on the same screen without restarting the application.

[0298] Specifically, the plug-in management module meets the following requirements:

[0299] Support this plug-in to be referenced and called by other plug-ins;

[0300] Support management of background service plug-ins;

[0301] Support management of plugins with interfaces;

[0302] Support data interaction with plug-ins;

[0303] Supports arbitrary layout of plugins;

[0304] Supports plugin snapshot configuration, and the program can be restored to the state when the user last exited the next time it is started.

[0305] The plugin module requires a custom data model XML file.

[0306] The loading and layout of plug-ins are based on QT5's existing low-level API and are loaded dynamically.

[0307] The existing QT plug-ins use shared memory for data exchange, that is, only plug-ins on the same machine can exchange data. The innovation of this patent is that UDP communication is used to allow plug-ins on different machines to interact, thus achieving true separation of the front and back ends.

[0308] The data interaction of the plug-in is UDP communication implemented by this patent, business data parsing based on XML format, and format conversion between business data and messages.

[0309] Specifically, since the plug-in module is created and generated by the developer according to the agreed model format, the requirements for the content of the XML format configuration file are as follows:

[0310] The XML file model.xml is supported to model the services in the system. Correct configuration of this file will ensure the flexibility of the system. The node requirements in XML are as follows:

[0311] The XML root node contains a name attribute, which is used to indicate the model name;

[0312] The root node contains at least one attribute node, which can be composed of multiple attribute and model nodes. Almost all data models can be described through attribute and model nodes.

[0313] Attribute nodes are used to describe each sub-item of the data model and contain the following attributes: node name, data type, default value / model reference;

[0314] Model nodes are used to abstract the data model structure, making the attribute nodes more concise and the model easier to understand. There are at least 0 model nodes and at most unlimited model nodes. Model nodes can contain multiple attribute nodes, and can also contain multiple model nodes to form a recursive nested relationship. Model nodes contain the following attributes: node name and key (enumeration type has no key).

[0315] Support XML file packet.xml to model data packets. The node requirements in XML are as follows:

[0316] Message attributes include: ID, name, byte alignment and message header ID (the message header itself does not need this ID);

[0317] The message subnode is a field, which is a specific data structure of the data packet and is defined according to the field order of the data packet. The field contains attributes: attribute name, type, and default value.

[0318] Support XML file network.xml to bind received data packets with packet.xml. The node requirements in XML are as follows:

[0319] UDP node attributes include: IP address, port;

[0320] The message ID is a child node of the UDP node. The message ID can be one or more. The value of the message ID is the message ID in packet.xml.

[0321] Support XML file mapping.xml to bind the message in packet.xml and the node in model.xml. The node requirements in XML are as follows:

[0322] Mapping attributes include: name;

[0323] The sender or receiver must be configured under the mapping. The sender and receiver can be freely combined under the same mapping.

[0324] The sender and receiver attributes include: message ID.

[0325] UDP and mapping nodes need to be configured on both the sender and receiver.

[0326] UDP attributes include: ip and port.

[0327] One or more mapping subnodes can be configured under a mapping node.

[0328] The mapping sub-node attributes include: message attribute name and model node name.

[0329] The example configuration of model.xml, packet.xml, network.xml and mapping.xml described in the present invention is shown in Figure 3 , Figure 4 , Figure 5 and Figure 6 ,The comments in the figure provide detailed description of how to use the nodes.

[0330] In one embodiment, Figure 2 As shown, based on the software composition scheme, the present invention provides a QT-based modular plug-in communication method.

[0331] In this embodiment, the first implementation of the communication method is described, and the implementation steps are divided into four steps:

[0332] Step S1 of configuring the plug-in module business model and implementing business coding;

[0333] Step S2 of configuring plugin loading, data integrity verification and data forwarding in the plugin management module;

[0334] Step S3 of configuring the model data processing module to parse, store and forward the business model;

[0335] Step S4 of configuring the UDP communication module to send data as a message and to parse the received message.

[0336] Since this is the first implementation example, developers are required to complete steps S1 to S4.

[0337] However, after completing and perfecting the first instance, steps S2 to S4 will be integrated into the self-developed framework for reuse in subsequent project development.

[0338] Therefore, in the subsequent implementation, the developer only needs to complete step S1, which solves the problems of cumbersome coding, difficult collaborative development and low code reusability.

[0339] Next, Figure 2 The steps S1 to S4 are combined Figure 1 The self-developed software composition scheme is described in detail.

[0340] Specifically, step S1 needs to configure the business model and implement business coding. The business coding can be encoded according to actual business needs. Before this, the developer needs to configure the business model according to the rules of the present invention. The specific configuration is as follows:

[0341] Developers define model.xml according to the business model. Its content is a data structure that needs to exist during the entire software life cycle (referring to the main program running time, that is, the time from the opening to the closing of the program). It is used for data sharing and access between different plug-ins during the entire software life cycle.

[0342] The developer defines packet.xml according to the actual application scenario. Its content is the data message protocol format, which is used to determine the filling of the UDP message when sending and the parsing of the UDP message when receiving;

[0343] Developers define network.xml according to the actual application scenario. Its content includes the local "IP address" and "port" number of the receiving end, as well as the "message ID" corresponding to the message format required for parsing the received message.

[0344] Developers define mapping.xml based on business models and actual application scenarios. Its content is divided into two parts:

[0345] Sender mapping: defines the "destination IP" address and "port" number of the receiving end of the message sent by this machine; defines the binding relationship between the "model node name" (derived from model.xml) and the "message attribute name" (derived from packet.xml). After the two are bound, when sending the message, the value of the "model node name" will be assigned to the "message attribute name", and then sent to the receiving end of the specified "destination IP" address and "port" through the UDP communication module.

[0346] Receiving end mapping: The receiving end here refers to the local machine. It is necessary to define the IP and port of the local UDP listening, as well as the "message ID"; define the binding relationship between the "message attribute name" (derived from packet.xml) and the "model node name" (derived from model.xml). After the two are bound, when the message with the specified "message ID" is received, the value of the "message attribute name" will be assigned to the "model node name" to update the full life cycle data structure stored in the aforementioned model data processing module for synchronous update and access by all plug-ins.

[0347] Specifically, step S2 needs to configure the plug-in management module to realize the loading of different types of plug-ins. The startup process of this module needs to check the integrity of the plug-in including the interface, data, configuration files, etc., and the wrong plug-in will not be loaded, thereby avoiding adverse effects on system stability.

[0348] Taking the plug-in name modelTestPlugin as an example, the name of the plug-in is defined in the first line of model.xml.

[0349] Create a new directory named modelTestPlugin, in which four XML files are stored, as well as source code modifications based on demo. Modifications not related to business are shown in Table 1.

[0350] Business-related modifications are made in the Controller class, which is implemented by the user.

[0351] The corresponding files of the Controler class are controler.h and controler.cpp, which are the logic control classes of the plug-in. The main backend logic interfaces of the plug-in are all completed in this class. The Controler class inherits from IPacketObserver and needs to implement the pure virtual function packetReceived to receive messages and parse the message content.

[0352] Furthermore, the aforementioned step S2 can realize arbitrary dynamic separation layout of plug-ins on the same screen without restarting the application; can make plug-ins referenced and called by other plug-ins; can manage background service plug-ins; can interact with plug-ins (i.e., the XML model data in the aforementioned step S1); can make plug-ins arbitrarily laid out; can snapshot configure plug-ins so that the next time the program is started, it can be restored to the state when the user last exited.

[0353] The loading and layout of plug-ins are based on QT5's existing low-level API and are loaded dynamically.

[0354] The existing QT plug-ins use shared memory for data exchange, that is, only plug-ins on the same machine can exchange data. The innovation of this patent is that UDP communication is used to allow plug-ins on different machines to interact, thus achieving true separation of the front and back ends.

[0355] The data interaction of the plug-in is UDP communication implemented by this patent, business data parsing based on XML format, and format conversion between business data and messages.

[0356] Snapshot configuration means pausing the plug-in process, keeping the data cache in the plug-in, and suspending the data interaction between the plug-in and other plug-ins.

[0357] Any layout means that the window can be split or scaled up, down, left, or right. This is a layout adjustment function supported by QT itself.

[0358] Based on the foregoing, the aforementioned step S2 can forward the processed model data in the aforementioned step S3 to the plug-in module in the aforementioned step S1, or forward the data to be processed of the plug-in module in the aforementioned step S1 to the model data processing module in the aforementioned step S3.

[0359] Specifically, step S3 needs to configure the model data processing module to implement the parsing, storage and forwarding of the business model. The business model is the data structure of the business model in the aforementioned step S1; the purpose of the storage is to store the model data and provide model data for all plug-ins throughout their life cycle; the forwarding is to forward the processed model data processed according to the mapping relationship of mapping.xml in the aforementioned step S1 in the form of a message to the UDP communication module in the aforementioned step S4, or to the plug-in management module in the aforementioned step S2 in the form of model data.

[0360] Taking the sending end as an example, after the business data is converted into the data structure in model.xml, it is mapped to the message in packet.xml through mapping.xml, and then sent to the specified target plug-in through the UDP communication module.

[0361] First, the data is stored in the plug-in that generates the business data (which can be understood as the source plug-in). After the data is sent to the target plug-in, the target plug-in can also store it as needed, and the source plug-in can continue to store or delete it as needed.

[0362] The storage format is the data structure defined in model.xml.

[0363] Lifecycle model data means that the business data can be continuously stored in the format defined in model.xml until the plug-in ends.

[0364] Specifically, step S4 needs to configure a UDP communication module for sending the model data in a message format and parsing the received message. The message format is the packet.xml content in the aforementioned step S1.

[0365] Furthermore, the sending of the model data in the message format in the aforementioned step S4 specifically refers to:

[0366] The message data in the above step S3 is sent according to the destination IP address and port set in mapping.xml.

[0367] Furthermore, the parsing of the received message in the aforementioned step S4 specifically refers to:

[0368] According to the message ID bound to the local port number in network.xml, find the corresponding message format in packet.xml and parse the received message;

[0369] Forward the parsed message to the model data processing module in the above step S3

[0370] Furthermore, based on the above-mentioned parsing operation of the received message, the subsequent processing is as follows:

[0371] The model data processing module parses the received message according to the format in mapping.xml according to the mapping relationship between the message and the data model in the aforementioned step S1, processes it into model data, and stores the model data;

[0372] The model data processing module forwards the processed data to the plug-in management module in the aforementioned step S2;

[0373] After receiving the data, the plug-in management module notifies all plug-ins that subscribe to the data message to update the data.

[0374] Table 1 Code modification based on demo

[0375]

[0376] Those skilled in the art know that, in addition to realizing the system and its various devices, modules, and units provided by the present invention in a purely computer-readable program code, it is entirely possible to realize the same functions in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered as a hardware component, and the devices, modules, and units included therein for realizing various functions can also be regarded as structures within the hardware component; the devices, modules, and units for realizing various functions can also be regarded as both software modules for realizing the method and structures within the hardware component.

[0377] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A QT-based modular plug-in communication system, characterized in that: include: UDP communication module: provides the software with network card-based message communication functions, sends business model data in messages, and parses received messages; Model data processing module: provides the software with model data throughout its life cycle, and parses, stores, and forwards business models; Plugin management module: capable of loading different types of plugins; Plug-in module: Users encode and generate plug-ins based on business model data.

2. The QT-based modular plug-in communication system according to claim 1, characterized in that: In the UDP communication module: The UDP communication module uses the UDP protocol to transmit data at the bottom layer, and users can perform visual configuration through XML files; The network module configures the IP and receiving port of the current plug-in UDP communication and the message type it monitors; The mapping module configures the transmitter and receiver of the current plug-in. The transmitter includes the transmitted data format, destination IP and port, and the receiver includes the parsing rules after receiving the data. The mapping module maps the data of the model module and the packet module. The packet module is the format of the message transmitted between plugins, including the message header and data segment; The UDP communication module meets the following requirements: Support XML file to describe general message definition, data types include uint, int, double, bool; The general message definition meets the following requirements: the fields support default value settings; Support byte alignment; Supports the definition of fixed-length or variable-length messages; supports XML file description of string message definition, including variable-length string QString; Support network monitoring configuration based on XML files; Among them, the network monitoring configuration meets the following requirements: supports the configuration of local sending IP address and port number; supports two-way binding of message models, allowing the received data to be directly updated to the model, allowing the data in the model to be directly converted into binary streams and sent out, meeting the following requirements: Data binding from message to model: supports mapping received data to the model through XML file description; Data binding from model to message: supports directly mapping the data in the model to the message model description through XML files and sending it through network configuration; Support sending model filled default values; Data sending and receiving supports packet processing.

3. The QT-based modular plug-in communication system according to claim 1, characterized in that: In the model data processing module: Replace the data structure in the C programming language, support XML files for modeling, and support data storage; The model data processing module meets the following requirements: Supports modeling of basic data types, including char, int, uint, double, and bool; Supports proprietary data types including quint8, qint8, bool, double; supports indefinite length string QString; Supports data type modeling, including date, time, datetime, rect; supports data types including QDateTime, QDate, QTime; Supports modeling of basic container data types: Supports complex container types including: std::list, std::vector, std::map; Supports the combination and nesting of data types, and supports more complex business models through combination and nesting; Supports model data storage and provides model data throughout the entire life cycle.

4. The QT-based modular plug-in communication system according to claim 1, characterized in that: In the plug-in management module: Perform integrity check and forwarding on data, where the data refers to the definition and business-related content, which is data that needs to be transferred between two or more plug-ins; The plug-in management module meets the following requirements: Supports this plug-in to be referenced and called by other plug-ins; supports the management of background service plug-ins; supports the management of plug-ins with interfaces; supports data interaction between plug-ins; supports arbitrary layout of plug-ins; Supports plugin snapshot configuration, so the program can be restored to the state when the user last exited the next time it is started; The plug-in module customizes the data model XML file; the loading and layout of the plug-in are based on the existing low-level API of QT5 and are loaded in a dynamic loading manner; Use UDP communication to allow plugins on different machines to interact and separate the front-end and back-end. The data interaction of the plug-in is UDP communication, business data parsing based on XML format, and format conversion between business data and messages.

5. The QT-based modular plug-in communication system according to claim 1, characterized in that: In the plugin module: Custom data model files are created and generated by developers according to the agreed model format. The requirements for the content of the XML format configuration file are as follows: The XML file model module is supported to model the services in the system. Correct configuration of this file will ensure the flexibility of the system. The node requirements in XML are as follows: The XML root node contains a name attribute, which indicates the model name; The root node contains at least one attribute node, which consists of multiple attribute and model nodes, and the data model is described by the attribute and model nodes; The attribute node describes each child of the data model and contains the following attributes: node name, data type, default value or model reference; Model nodes abstract data model structures. There are at least 0 model nodes and at most unlimited model nodes. Model nodes contain multiple attribute nodes, or contain multiple model nodes to form a recursive nested relationship. Model nodes contain the following attributes: node name and key. Support XML file packet module to model data packet messages; the node requirements in XML are as follows: Message attributes include: ID, name, byte alignment and message header ID; The message sub-node is a field, which is a specific data structure of the data packet and is defined according to the field order of the data packet; the field contains attributes: attribute name, type, and default value; Support XML file network module to bind received data packets with packet module; the node requirements in XML are as follows: UDP node attributes include: IP address, port; The message ID is a child node of the UDP node. The message ID is one or more. The value of the message ID is the message ID in the packet module. Support XML file mapping module to bind the message in the packet module and the node in the model module; the node requirements in XML are as follows: Mapping attributes include name; Configure the sender or receiver under the mapping; under the same mapping, the sender and receiver can be freely combined; The sender and receiver attributes include the message ID; Configure UDP and mapping nodes on the sender and receiver; UDP attributes include ip and port; Configure one or more mapping subnodes under the mapping node; The mapping subnode attributes include the message attribute name and the model node name.

6. A QT-based modular plug-in communication method, characterized in that: The QT-based modular plug-in communication system according to any one of claims 1 to 5 is used to perform the following steps: Step S1: configure the plug-in module business model and implement business coding; Step S2: Configure plugin loading, data integrity verification, and data forwarding in the plugin management module; Step S3: Analyze, store and forward the business model by configuring the model data processing module; Step S4: configure the UDP communication module to send the business model data in a message format, and parse the received message.

7. The QT-based modular plug-in communication method according to claim 6, characterized in that: In step S1: The business model is defined by the developer in XML format for data structure generation; XML format message configuration and the mapping relationship between the message and the data model are defined for data sharing between different plug-ins in the same program or between different plug-ins in different programs; XML format network configuration is defined to determine the address information of the sender and the receiver; It is necessary to configure the business model and implement business coding. The business coding is encoded according to the actual business needs. The developer configures the business model according to the rules. The specific configuration is as follows: Developers define model modules based on business models. The model modules contain data structures that need to exist throughout the software life cycle. They are used to share and access data between different plug-ins during the software life cycle. The software life cycle refers to the running time of the main program. The developer defines the packet module according to the actual application scenario. Its content is the data message protocol format, which is used to determine the filling of the UDP message when sending and the parsing of the UDP message when receiving. The developer defines the network module according to the actual application scenario. Its content is the local IP address and port number of the receiving end, as well as the message ID corresponding to the required message format for parsing the received message. Developers define mapping modules based on business models and actual application scenarios. The content of the mapping module is divided into two parts: Sender mapping: defines the destination IP address and port number of the receiving end of the message sent by the local machine; defines the binding relationship between the model node name and the message attribute name. After the two are bound, when sending the message, the value of the model node name is assigned to the message attribute name, and sent to the receiving end of the specified destination IP address and port through the UDP communication module; the model node name comes from the model module, and the message attribute name comes from the packet module; Receiver mapping: The receiver refers to the local machine, which defines the IP and port of the local UDP listening, as well as the message ID; Define the binding relationship between the message attribute name and the model node name. After the two are bound, when a message with a specified message ID is received, the value of the message attribute name is assigned to the model node name to update the full life cycle data structure stored in the aforementioned model data processing module for synchronous update and access by all plug-ins; the message attribute name comes from the packet module, and the model node name comes from the model module.

8. The QT-based modular plug-in communication method according to claim 6, characterized in that: In step S2: The plug-in loading includes loading, calling and unloading the plug-in; the data integrity check is to check the integrity of the plug-in including the interface, data and configuration file; the data forwarding is to forward the processed model data to the plug-in module, or to forward the data to be processed of the plug-in module to the model data processing module; The plug-in management module needs to be configured to load different types of plug-ins. The startup process of this module requires an integrity check of the plug-in interface, data, and configuration files. Incorrect plug-ins will not be loaded. It can realize arbitrary dynamic separation layout of plug-ins in the same screen without restarting the application; it can make plug-ins referenced and called by other plug-ins; it can manage background service plug-ins; it can interact with plug-ins; it can make plug-ins have arbitrary layout; it can configure snapshots of plug-ins so that the next time the program is started, it can be restored to the state when the user last exited; The loading and layout of plugins are based on the existing low-level API of QT5, and are loaded dynamically. UDP communication is used to enable plugins on different machines to interact and separate the front-end and back-end. The data interaction of the plug-in is UDP communication, which is based on the business data parsing in XML format and the format conversion between business data and messages; Snapshot configuration means pausing the plug-in process, keeping the data cache in the plug-in, and suspending the data interaction between the plug-in and other plug-ins; Any layout of the window can be split or zoomed up and down, left and right; the processed model data is forwarded to the plug-in module, or the data to be processed of the plug-in module is forwarded to the model data processing module.

9. The QT-based modular plug-in communication method according to claim 6, characterized in that: In step S3: The business model is a data structure in XML format defined by the developer; the purpose of the storage is to provide model data for the entire life cycle of the software; the forwarding is to forward the processed model data to the UDP communication module or the plug-in management module; It is necessary to configure the model data processing module to realize the parsing, storage and forwarding of the business model; the business model is the data structure of the business model; the purpose of the storage is to store the model data and provide the model data of the whole life cycle for all plug-ins; the forwarding is to forward the processed model data processed according to the mapping relationship of the mapping module to the UDP communication module in the form of a message, or to the plug-in management module in the form of model data; After the business data is converted into the data structure in the model module, it is mapped to the message in the packet module through the mapping module, and then sent to the specified target plug-in through the UDP communication module; First, the data is stored in the plug-in that generates the business data. After the data is sent to the target plug-in, the target plug-in stores it as needed, and the source plug-in can continue to store or delete it as needed. The storage format is the data structure defined in the model module; The model data of the life cycle will continue to store the business data in the format defined in the model module until the plug-in ends.

10. The QT-based modular plug-in communication method according to claim 6, characterized in that: In step S4: The message format is a message configuration in XML format defined by the developer; the sending of the business model data in the message format refers to sending the message according to the defined receiving end address; the parsing of the received message refers to parsing the received message according to the message format according to the binding relationship between the local port and the message ID, and forwarding it to the model data processing module for processing and storage, and then forwarding it to the plug-in management module by the model data processing module, which notifies all plug-ins subscribed to the data message to update the data; Configure the UDP communication module, send the model data in the message format, and parse the received message. The message format is the packet module content; Send the model data in the message format, specifically: Send the message data according to the destination IP address and port set in the mapping module; The parsing of the received message is specifically as follows: According to the message ID bound to the local port number in the network module, find the corresponding message format in the packet module and parse the received message; Forward the parsed message to the model data processing module Based on the parsing operation of the received message, the subsequent processing is as follows: The model data processing module parses the received message according to the format in the mapping module based on the mapping relationship between the message and the data model, processes it into model data, and stores the model data; The model data processing module forwards the processed data to the plug-in management module; After receiving the data, the plug-in management module notifies all plug-ins that subscribe to the data message to update the data.

Images