Object-oriented software module generation method, storage medium, system, and device

Abstract

The application discloses an object-oriented software module generation method, a storage medium, a system and equipment, and belongs to the technical field of computers. A development machine generates a binary device tree file after compiling a device tree source file, each node in the device tree source file corresponding to a software module; a target machine loads the binary device tree file; each node is traversed through a factory class, a corresponding software module is instantiated for a node with a compatibility attribute, and the obtained software module is associated with a reference number of the corresponding node and recorded in a meta base class container; for a node with a topology reference attribute, the reference number of a referenced node referenced by the node is determined according to the topology reference attribute of the node, a corresponding software module is found from the meta base class container by taking the reference number as an index, and a connection relationship between the found software module and the software module of the node is established; and the software module is configured according to a configuration attribute. The application can improve configuration flexibility and deployment efficiency and reduce maintenance costs.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an object-oriented software module generation method, storage medium, system, and device. Background Technology

[0002] In object-oriented modular software development, software functions are broken down into multiple independent software modules. The corresponding software modules are generated through top-level inputs, and each software module is assembled and configured to achieve flexible software construction.

[0003] In related technologies, there are two main methods for generating object-oriented software modules: The first method uses a configuration array compiled along with the software code. This method embeds the configuration information of the software module into the source code as an array. Changing the configuration requires modifying the array and recompiling, resulting in poor flexibility and lack of support for default parameters; all parameters must be filled in completely. The second method uses standard configuration files, such as XML, JSON, and YAML. This method stores the configuration information in an independent configuration file, achieving separation between configuration and software code. It also supports default parameters, but it lacks an automatic topology generation method for mutual references between software modules. The reference relationships between software modules need to be manually maintained and numbered by the developer, which is inefficient and prone to errors. Summary of the Invention

[0004] This application provides an object-oriented software module generation method, storage medium, system, and device to solve the problems of poor flexibility caused by recompiling for configuration changes and low efficiency and error-proneness due to manual maintenance of module topology relationships during software module generation. The technical solution is as follows: According to a first aspect of this application, an object-oriented software module generation method is provided for use in a software module generation system including a development machine and a target machine, the method comprising: The development machine compiles the device tree source file to generate a binary device tree file, and each node in the device tree source file corresponds to a software module to be created; The target machine loads the binary device tree file; The target machine traverses each node in the binary device tree file through the factory class, instantiates the corresponding software module for the node with compatibility attribute, and associates each instantiated software module with the reference number of the corresponding node in the metabase class container. The reference number is created for the referenced node when compiling the binary device tree file. For a node with a topological reference attribute, the target machine determines the reference number of the referenced node referenced by the node based on the topological reference attribute, and uses the reference number as the index to search for the corresponding software module in the metabase class container, and establishes a connection relationship between the searched software module and the software module corresponding to the node. The target machine configures the parameters of the corresponding software modules according to the configuration attributes of each node.

[0005] In one possible implementation, the step of associating and recording the reference numbers of the instantiated software modules with the corresponding nodes in a metabase class container includes: the target machine creating a metabase class container, wherein the index of the metabase class container corresponds one-to-one with the reference number of each node; and storing the pointers of each software module in the metabase class container at the index positions corresponding to the reference numbers of the corresponding nodes. The step of finding the corresponding software module from the metabase class container using the reference number as the index includes: the target machine reading the pointer at the corresponding index position from the metabase class container using the reference number of the referenced node as the index, and determining the corresponding software module based on the pointer.

[0006] In one possible implementation, the method further includes: The target machine creates special software modules through a factory class; The target machine sends a refactoring instruction to all factory classes through the special software module; The target machine, in response to the refactoring instruction through each factory class, destroys the software modules it has created and recreates the software modules according to the new binary device tree file.

[0007] In one possible implementation, the target machine traverses each node in the binary device tree file through a factory class, instantiating corresponding software modules for nodes with compatibility attributes, including: For each factory class, the target machine traverses the nodes under the corresponding subclass path in the binary device tree file through the factory class. The subclass path is the path divided according to the software module category under the root node of the binary device tree file. The target machine reads the compatibility attributes of the traversed nodes through the factory class; For nodes with compatibility attributes, the target machine determines a software module class that matches the compatibility attribute through the factory class, and instantiates the software module class into a software module.

[0008] In one possible implementation, the development machine compiles the device tree source file to generate a binary device tree file, including: The development machine divides multiple sub-paths under the root node of the device tree source file according to the software module category; The development machine creates a node for each software module to be created under each subclass path; The development machine sets corresponding attributes for each node; The development machine uses a device tree compiler to compile the device tree source file into a binary device tree file.

[0009] In one possible implementation, the method further includes: The development machine obtains a subset device tree file, which contains defined nodes; The development machine imports the subset device tree file into the device tree source file; The development machine redefines the attributes of some nodes in the subset device tree file in the device tree source file to override the corresponding attributes in the subset device tree file.

[0010] In one possible implementation, the method further includes: The development machine sets aliases for referenced nodes that need to be referenced by other nodes; The development machine writes the alias into the topology reference attribute of the other nodes.

[0011] According to a second aspect of this application, a software module generation system is provided, the software module generation system comprising a development machine and a target machine; The development machine is used to compile the device tree source file to generate a binary device tree file, where each node in the device tree source file corresponds to a software module to be created. The target machine is used to load the binary device tree file; The factory class traverses each node in the binary device tree file, instantiates the corresponding software module for the node with compatibility attribute, and associates each instantiated software module with the reference number of the corresponding node in the metabase class container. The reference number is created for the referenced node when the binary device tree file is compiled. For a node with a topological reference attribute, the reference number of the referenced node is determined according to the topological reference attribute. The corresponding software module is searched from the metabase class container using the reference number as the index, and a connection relationship is established between the searched software module and the software module corresponding to the node. Configure the parameters of the corresponding software modules according to the configuration attributes of each node.

[0012] According to a third aspect of this application, a computer-readable storage medium is provided, wherein at least one instruction is stored therein, the at least one instruction being loaded and executed by a processor to implement the object-oriented software module generation method described above.

[0013] According to a fourth aspect of this application, an electronic device is provided, the electronic device including the software module generation system described above.

[0014] The beneficial effects of the technical solution provided in this application include at least the following: By storing the configuration information of software modules as independent device tree files, completely separating them from executable files, the target machine can dynamically create and assemble software modules after loading the device tree file. In this way, changing the configuration information only requires replacing or modifying the device tree file, without modifying the source code and recompiling. Compared with the generation method of fixing the configuration array in the source code, this can significantly improve configuration flexibility and deployment efficiency.

[0015] The topology reference attributes in the device tree source file describe the reference relationships between modules, and reference numbers are automatically generated for referenced nodes during compilation. This allows the target machine to use the reference number as an index to locate the corresponding software module in the metabase class container, directly identifying and establishing connections between modules. Compared to the method requiring developers to manually maintain module numbers, this automatic topology connection between modules avoids the inefficiency and error-proneness of manual number maintenance.

[0016] By extracting configuration information shared by multiple software modules into independent subset device tree files, which can be referenced by multiple device tree source files, and by overriding the attributes of some nodes when referencing them, the configuration reuse requirement of large sets nested within smaller sets is realized, which significantly reduces repetitive configuration work and lowers maintenance costs. Attached Figure Description

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

[0018] Figure 1 This is a flowchart of an object-oriented software module generation method provided in one embodiment of this application; Figure 2 This is a flowchart of an object-oriented software module generation method provided in another embodiment of this application; Figure 3 This is an example diagram of an object-oriented software module system provided in one embodiment of this application; Figure 4 This is a topology diagram of an object-oriented software module system provided in one embodiment of this application; Figure 5 This is a structural block diagram of an object-oriented software module generation apparatus provided in one embodiment of this application; Figure 6 This is a structural block diagram of an electronic device provided in one embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0020] like Figure 1 The diagram illustrates a flowchart of an object-oriented software module generation method according to an embodiment of this application. This object-oriented software module generation method can be applied to a software module generation system that includes a development machine and a target machine. The object-oriented software module generation method may include: Step 101: The development machine compiles the device tree source file to generate a binary device tree file. Each node in the device tree source file corresponds to a software module to be created.

[0021] A binary device tree file (DTB) is a binary format file generated by compiling a device tree source file (DTS) using the device tree compiler (DTC) on the development machine. Typically, binary device tree files organize data in a tree structure to facilitate parsing by the target machine.

[0022] A target machine is a computer device that loads and executes a binary device tree file, generates software modules based on its descriptions, and runs the software. The target machine is the actual platform on which the software modules run; it can be the same physical device as the development machine, or it can be a different physical device connected via a network.

[0023] Each node in the device tree source file corresponds to a software module to be created. A software module, in object-oriented programming, is a basic unit that encapsulates data and behavior; it is essentially a runtime object instance. There is a one-to-one correspondence between nodes and software modules; that is, a node describes all the information of a software module to be created, and the target machine generates the corresponding software module based on the node's description.

[0024] Step 102: The target machine loads the binary device tree file.

[0025] Step 103: The target machine traverses each node in the binary device tree file through the factory class, instantiates the corresponding software module for the node with compatibility attributes, and associates each instantiated software module with the reference number of the corresponding node in the metabase class container. The reference number is created for the referenced node when compiling the binary device tree file.

[0026] The compatibility attribute has a string value indicating the creation type of the software module corresponding to the node. A factory class is a class used in object-oriented programming to create objects; it encapsulates the object instantiation logic and determines which software module class instance to create based on the input compatibility attribute. Instantiation is the process of creating an object in memory based on a class. A software module class is a static definition of a software module, specifying its data structure and behavioral methods. A software module (i.e., a software module object) is a dynamic instance of a class at runtime, occupying actual memory space and capable of performing specific operations.

[0027] In this embodiment, the factory class is responsible for reading the compatibility attributes of each node in the binary device tree file. If the factory class finds a compatibility attribute for a node, it creates an instance of a software module class that matches the compatibility attribute value, thus obtaining the software module. Specifically, the target machine traverses all nodes in the binary device tree file. For each traversed node, the target machine reads the compatibility attribute value of that node. Since the factory class internally maintains a mapping relationship between compatibility attribute values ​​and software module classes, the target machine can match the read compatibility attribute values ​​with the software module classes supported by the factory class. When a software module class that matches the compatibility attribute value is found, the constructor of that software module class is called to create a software module object in memory, thus obtaining the software module.

[0028] During matching, the target machine can first obtain a unique enumeration of software module classes through the string of compatibility attributes, and then find the corresponding software module class based on the enumeration and create it. The implementation code is as follows: vidoEmployeeTypeLUT CFdtUseCase::ms_empLut[] = { VIDO_FDT_MAKE_TYPE_WITH_NAME(EMPLOYEE_TYPE_GEN), VIDO_FDT_MAKE_TYPE_WITH_NAME(EMPLOYEE_TYPE_SINK), VIDO_FDT_MAKE_TYPE_WITH_NAME(EMPLOYEE_TYPE_DUPLI), VIDO_FDT_MAKE_TYPE_WITH_NAME(EMPLOYEE_TYPE_CONCAT), VIDO_FDT_MAKE_TYPE_WITH_NAME(EMPLOYEE_TYPE_3701I), } EMPLOYEE_TYPE CFdtUseCase::vidoEmployeeCompatibleToEnum(intnodeOffset) { for(int i=0;i <NELEMENTS(ms_empLut);++i) { if(!fdt_node_check_compatible(m_pFdt,nodeOffset,ms_empLut[i].compatibleStr)) return ms_empLut[i].type; } return (EMPLOYEE_TYPE)NULL; } It should be noted that when creating a software module, if the factory class cannot find compatibility with a certain node, the corresponding software module cannot be created, and an error must be reported or a critical warning issued. Simultaneously, software modules referencing that node also need to report errors or issue critical warnings during the connection process.

[0029] When compiling a binary device tree file, a unique reference number (phandle) is automatically generated for each referenced node. This reference number can be an integer value that increments from 1, and it remains unique within the same device tree file, serving to uniquely identify each referenced node at the binary level.

[0030] Metabase class containers are data structures used to store pointers to software modules. The metabase class is the common base class for all software module classes, and all software module classes derive from it. Therefore, a pointer to any software module object can be uniformly stored in the container as a pointer to a metabase class object.

[0031] The target machine can also associate the instantiated software modules with the reference number of the current node in the metabase class container, forming a correspondence between nodes and software modules, so that the corresponding software modules can be found in subsequent steps based on the nodes.

[0032] Step 104: For nodes with topological reference attributes, the target machine determines the reference number of the referenced node referenced by the node based on the topological reference attribute, searches for the corresponding software module in the metabase class container using the reference number as the index, and establishes a connection relationship between the found software module and the software module corresponding to the node.

[0033] The topology reference attribute is used to describe the reference relationship between the current node and other nodes. Its attribute value is the reference identifier of the referenced node. The target machine determines which other software modules the current software module should connect to based on the topology reference attribute.

[0034] The referenced node is the node that the topology reference attribute value of the current node points to.

[0035] The connection between two software modules is a logical association or data channel between them. For example, the output of one software module is connected to the input of another software module, or one software module contains another software module.

[0036] After instantiating the software module, the target machine iterates through the topology reference attributes of each node again. For a node with a topology reference attribute, the target machine reads the value of that attribute to determine the referenced node. The target machine then locates the software module corresponding to the current node based on its identifier information. Next, it searches for the corresponding software module in the metabase class container using the reference number as its index. Finally, the target machine calls the connection function of the current software module, passing the referenced software module as a parameter to establish the connection between the two software modules.

[0037] Step 105: The target machine configures the parameters of the corresponding software modules according to the configuration attributes of each node.

[0038] Configuration attributes provide adjustable parameters required for the software module to run, such as network port number, device name, and cache size. The values ​​of configuration attributes can be numeric, string, or array data types. The target machine assigns specific runtime parameters to the software module based on these configuration attributes.

[0039] The target machine iterates through each node, reading the configuration attributes of each node. For each created software module, the target machine assigns the configuration attribute values ​​of the corresponding node to the member variables of that software module. After assigning the configuration attributes of all nodes, all software modules are initialized, and the target machine starts the software.

[0040] In summary, the object-oriented software module generation method provided in this application provides a method that separates the configuration information of the software module from the executable file by storing the configuration information of the software module in an independent device tree file. After the target machine loads the device tree file, the software module can be dynamically created and assembled. In this way, changing the configuration information only requires replacing or modifying the device tree file, without modifying the source code or recompiling. Compared with the generation method of fixing the configuration array in the source code, this method can significantly improve the configuration flexibility and deployment efficiency.

[0041] The topology reference attributes in the device tree source file describe the reference relationships between modules, and reference numbers are automatically generated for referenced nodes during compilation. This allows the target machine to use the reference number as an index to locate the corresponding software module in the metabase class container, directly identifying and establishing connections between modules. Compared to the method requiring developers to manually maintain module numbers, this automatic topology connection between modules avoids the inefficiency and error-proneness of manual number maintenance.

[0042] like Figure 2 The diagram illustrates a flowchart of an object-oriented software module generation method according to an embodiment of this application. This object-oriented software module generation method can be applied to a software module generation system that includes a development machine and a target machine. The object-oriented software module generation method may include: Step 201: The development machine divides the root node of the device tree source file into multiple sub-paths according to the software module category.

[0043] The device tree source file is a device tree description file written in text form. It usually uses a tree structure to organize data, with a root node and all nodes located under the root node.

[0044] Subclass paths are child node paths under the root node, used to group and manage software modules of different categories. In one example, the software module categories include three basic categories: pipes, employees, and actions. Pipes are used for communication between software modules, employees are used for business logic processing, and actions are used for scheduling and assembling workloads during software module runtime.

[0045] The development machine creates multiple child nodes under the root node of the device tree source file, each child node serving as a subclass path. For example, it creates a child node named "pipes" as the path for the pipe category, a child node named "employees" as the path for the employee category, and a child node named "actions" as the path for the action category. Each subclass path is independent and is used to hold nodes for the corresponding software modules.

[0046] Step 202: The development machine creates a node for each software module to be created under each subclass path.

[0047] A node is the basic data unit in a device tree source file. Each node is used to describe all the information of the software module corresponding to that node.

[0048] The development machine creates multiple nodes under each subclass path based on software design requirements. For example, under the "pipes" subclass path, a node named "UDP_IN" is created for message queue pipes, and nodes named "Ctrl2Para" and "Para2Out" are created for transparent pipes; under the "employees" subclass path, a node named "FMY_PATENT_CTRL" is created for control employees, a node named "FMY_PATENT_Param" is created for parameter employees, and a node named "UDPI" is created for UDP input employees; under the "actions" subclass path, nodes named "udpi" and "ctrl_update" are created for actions. Each node corresponds to a software module to be created during target machine runtime.

[0049] Step 203: The development machine sets the corresponding attributes for each node to obtain the device tree source file.

[0050] The attributes corresponding to a node include at least configuration attributes, and may also include at least one of compatibility attributes and topology reference attributes.

[0051] The `compatible` attribute has a string value that indicates the creation type of the software module corresponding to the node. The target machine determines which software module class should be instantiated based on the `compatible` attribute value.

[0052] The compatibility attribute value is the type identifier of the software module corresponding to the node. For example, the compatibility attribute of the UDP_IN node is "PIPE_TYPE_MSGQ", indicating that the node corresponds to the message queue pipe type; the compatibility attribute of the FMY_PATENT_CTRL node is "EMPLOYEE_TYPE_MY_PATENT_CTRL", indicating that the node corresponds to the control employee type.

[0053] Topology reference attributes are used to describe the reference relationships between the current node and other nodes. Specifically, the development machine sets aliases for referenced nodes that need to be referenced by other nodes; the development machine writes the aliases into the topology reference attributes of other nodes.

[0054] When a node needs to reference another node, the development machine writes the alias of the referenced node into the node's topology reference attribute and adds an "&" symbol before the alias to indicate a reference. For example, the "inpipes" attribute of the FMY_PATENT_CTRL node contains "&UDP_IN" and "&Para2Out", indicating that the node references two nodes with aliases "UDP_IN" and "Para2Out"; its "outpipes" attribute contains "<&Ctrl2Para>", indicating that the node also references a node with the alias "Ctrl2Para".

[0055] Configuration attributes are used to provide various adjustable parameters required for the software module to run. The attribute values ​​can be data types such as numbers, strings or arrays. The target machine assigns specific running parameters to the software module according to the configuration attributes.

[0056] The development machine sets configuration properties on each node, with the property values ​​representing the runtime parameters of the software module corresponding to that node. For example, the "netDevName" property of the UDPI node is set to "gem0", indicating the network device name; the "localPort" property is set to... <18002> The "remoteIp" attribute is set to "[c0 a8 02de]", representing the local port number; the "remoteIp" attribute is set to "[c0 a8 02de]", representing the remote IP address; the "remotePort" attribute is set to " <18002> ", indicates the remote port number.

[0057] In this embodiment, the development machine also obtains a subset device tree file, which contains defined nodes; the development machine imports the subset device tree file into the device tree source file; the development machine redefines the attributes of some nodes in the subset device tree file in the device tree source file to override the corresponding attributes in the subset device tree file.

[0058] The subset device tree file stores node definitions that can be shared by multiple device tree source files and can be pre-stored on the development machine. The subset device tree file itself does not constitute a complete device tree file and needs to be imported and used by other device tree source files.

[0059] Specifically, the development machine uses include directives to import the contents of subset device tree files into the current device tree source file. The include directive specifies the path to the subset device tree file, and when the device tree compiler processes the current device tree source file, it inserts the subset device tree file corresponding to that path at the location of the include directive. Typically, a single device tree source file can include multiple subset device tree files.

[0060] Then, the development machine redefines the configuration properties of nodes imported from the subset device tree file within the current device tree source file. When the same configuration property is redefined in the current device tree source file, the property value in the current device tree source file will override the original property value in the subset device tree file. In this way, the development machine can achieve differentiated customization of node parameters when using the subset device tree file without modifying the subset device tree file itself.

[0061] Step 204: The development machine compiles the device tree source file into a binary device tree file using the device tree compiler.

[0062] During compilation, the device tree compiler performs syntax checks and structural optimizations, and automatically generates unique phandles for nodes with aliases. These phandles can be integer values ​​starting from 1 and incrementing, remaining unique within the same device tree file to uniquely identify each referenced node at the binary level.

[0063] The development machine inputs the completed device tree source file into the device tree compiler to perform the compilation operation. The device tree compiler reads the device tree source file, parses the node definitions, attribute assignments, and node reference relationships, automatically assigns a unique reference number to all nodes with aliases, replaces the alias references in the device tree source file with the corresponding reference numbers, generates a binary device tree file, and outputs it. After compilation, the development machine deploys the generated binary device tree file to the target machine.

[0064] Step 205: The target machine loads the binary device tree file.

[0065] After the target machine boots up, it reads the binary device tree file stored in memory. This binary device tree file remains in memory throughout the software's runtime and is not released, allowing it to be directly referenced in subsequent steps without requiring additional copying.

[0066] Step 206: The target machine traverses each node in the binary device tree file through the factory class and instantiates the corresponding software module for the node with compatibility attributes.

[0067] Specifically, the target machine traverses each node in the binary device tree file through the factory class, and instantiates the corresponding software module for the node with compatibility attributes. This can include: for each factory class, the target machine traverses the nodes under the corresponding subclass path in the binary device tree file through the factory class. The subclass path is the path divided according to the software module category under the root node of the binary device tree file; the target machine reads the compatibility attributes of the traversed nodes through the factory class; for the node with compatibility attributes, the target machine determines the software module class that matches the compatibility attributes through the factory class, and instantiates the software module class into a software module.

[0068] In this embodiment, the factory class is responsible for reading the compatibility attributes of each node in the binary device tree file. If the factory class finds a compatibility attribute for a node, it creates an instance of the software module class that matches the compatibility attribute value, thus obtaining the software module. Specifically, the target machine traverses all nodes in the binary device tree file. For example, the pipe factory traverses the nodes under the "pipes" path, the employee factory traverses the nodes under the "employees" path, and the action factory traverses the nodes under the "actions" path. For each traversed node, the target machine reads the compatibility attribute value of that node. Since the factory class internally maintains a mapping relationship between compatibility attribute values ​​and software module classes, the target machine can match the read compatibility attribute values ​​with the software module classes supported by the factory class. When a software module class that matches the compatibility attribute value is found, the constructor of that software module class is called to create a software module object in memory, thus obtaining the software module. For example, the pipeline factory traverses to the UDP_IN node, reads its compatibility attribute as "PIPE_TYPE_MSGQ", matches the appropriate software module class, and creates a message queue pipeline object; the employee factory traverses to the UDPI node, reads its compatibility attribute as "EMPLOYEE_TYPE_UDP_I", and creates a UDP input employee object.

[0069] Step 207: The target machine associates and records the reference numbers of each instantiated software module with the corresponding node in the metabase class container. The reference number is created for the referenced node when compiling the binary device tree file.

[0070] Metabase class containers are data structures used to store pointers to software modules. The metabase class is the common base class for all software module classes, and all software module classes derive from it. Therefore, a pointer to any software module object can be uniformly stored in the container as a metabase class pointer. The indices of the metabase class container correspond one-to-one with the reference numbers of each node, allowing the target machine to directly locate the corresponding software module using the reference number.

[0071] Specifically, associating and recording the reference numbers of each instantiated software module with the corresponding node in the metabase class container can include: the target machine creating a metabase class container, where the index of the metabase class container corresponds one-to-one with the reference number of each node; and storing the pointer of each software module in the metabase class container at the index position corresponding to the reference number of the corresponding node.

[0072] In this embodiment, the target machine creates a metabase class container, where the index of the metabase class container corresponds one-to-one with the reference number of each node. For each software module that has been created, the target machine obtains the reference number of the node corresponding to the software module and stores the pointer of the software module in the metabase class container at the position with the reference number as the index.

[0073] For example, if the reference number of the UDP_IN node is 1, the target machine stores the pointer to the UDP_IN pipe object at index 1 in the metabase class container. In this way, any software module corresponding to a node with a reference number can be directly located in the metabase class container through its reference number.

[0074] Step 208: For nodes with topological reference attributes, the target machine determines the reference number of the referenced node referenced by the node based on the topological reference attribute, searches for the corresponding software module in the metabase class container using the reference number as the index, and establishes a connection relationship between the found software module and the software module corresponding to the node.

[0075] Specifically, finding the corresponding software module from the metabase class container using the reference number as the index can include: the target machine using the reference number of the referenced node as the index to read the pointer to the corresponding index position from the metabase class container, and determining the corresponding software module based on the pointer.

[0076] The target machine iterates through the topology reference attributes of each node again. For a node with a topology reference attribute, the target machine reads its topology reference attribute value to obtain a list of reference numbers of the referenced nodes. The target machine reads the pointer to the corresponding index from the metabase class container using the reference number of the referenced node as the subscript. Since the container subscript and the reference number are in one-to-one correspondence, the time complexity of this operation is O(1). The target machine obtains the software module corresponding to the current node and the software module corresponding to the referenced node. For example, the "inpipes" attribute of the FMY_PATENT_CTRL node stores reference numbers 1 and 3 after compilation. The target machine retrieves the UDP_IN pipe object and the Para2Out pipe object from the metabase class container using 1 and 3 as subscripts, respectively.

[0077] Then, the target machine calls the connection establishment function of the current software module, passing the referenced software module as a parameter to establish a connection between the two software modules. The connection establishment function is a member function in each software module class used to establish connections between modules.

[0078] Different types of software modules have different types of connection establishment functions. When establishing a connection, the target machine calls the corresponding connection establishment function by casting the pointer of the software module object to a base class pointer. For example, the behavior class module adds employees through the InsertEmployee interface, and the employee class module binds pipes through the BindPipe interface.

[0079] When the referenced module object is a pipe type, the bind pipe interface of the current employee object is called to establish the binding relationship between the employee and the pipe, that is, the input or output channel of the employee is connected to the specified pipe. When the referenced module object is an employee type, the add employee interface of the current behavior object is called to establish the assembly relationship between the behavior and the employee, that is, the specified employee is added to the execution sequence of the behavior. For example, the "inpipes" attribute of the FMY_PATENT_CTRL node references two pipe nodes, UDP_IN and Para2Out. After the target machine finds these two pipe objects, it calls the bind input pipe interface of the FMY_PATENT_CTRL employee object, passing in the UDP_IN pipe object and the Para2Out pipe object in sequence to establish the binding relationship between the employee and the two input pipes.

[0080] Step 209: The target machine configures the parameters of the corresponding software modules according to the configuration attributes of each node.

[0081] The target machine iterates through each node and reads the configuration attributes of each node. The target machine then assigns the configuration attribute values ​​of the corresponding nodes to the member variables of the software module one by one.

[0082] If the configuration properties of a certain software module are not filled in in the device tree node, the default parameter values ​​preset in the code can be used.

[0083] For string-type configuration attribute values, the target machine directly assigns the value by referencing the memory address where the string is stored in the binary device tree file, without copying it, in order to reduce memory usage.

[0084] For example, the "netDevName" attribute of the UDPI node is the string "gem0", and the "localPort" attribute is the value 18002. After the target machine reads these configuration attributes, it sets the network device name member variable of the UDPI employee object to "gem0" and the local port member variable to 18002.

[0085] After all the configuration attributes of all nodes have been assigned, all software modules have been initialized and the target machine starts running the software.

[0086] In this embodiment, the target machine can also reconstruct the software module topology. Reconstruction refers to the process of establishing the software modules and connections required by the new device tree by destroying all software modules and connections created based on the original device tree without changing the executable application software.

[0087] Specifically, the target machine creates a special software module through a factory class; the target machine sends a refactoring instruction to all factory classes through the special software module; in response to the refactoring instruction, the target machine destroys the software module it has created and recreates the software module according to the new binary device tree file.

[0088] The target machine creates a special software module through a factory class (e.g., a behavior factory class). This special software module is a behavior type module. When it determines that the conditions for switching the topology are met, it actively initiates a refactoring request. Since different factory classes manage the software modules under their respective paths, the refactoring instruction needs to be sent to all factory classes to ensure that the corresponding software modules under each path are processed correctly.

[0089] Each factory class iterates through all the software modules it creates, destroying each module one by one, releasing the memory resources it occupies, and clearing the associations between modules. It should be noted that the task containing a special software module (i.e., the destruction task that initiates the refactoring) needs to have its destruction temporarily suspended. This task must continue executing the control logic for destruction and reconstruction, and can only exit after all destruction and reconstruction work is completed. Therefore, the target machine should stop all tasks except this one during the destruction phase to ensure the safety and controllability of the destruction process.

[0090] After all factory classes have been destroyed, the target machine loads a new binary device tree file. Each factory class then traverses each node under the corresponding subclass path in the new device tree, re-instantiates the software module according to the node's compatibility attribute, re-establishes the connection relationship between modules according to the node's topology reference attribute, and configures the parameters of each software module according to the configuration attribute.

[0091] In summary, the object-oriented software module generation method provided in this application provides a method that separates the configuration information of the software module from the executable file by storing the configuration information of the software module in an independent device tree file. After the target machine loads the device tree file, the software module can be dynamically created and assembled. In this way, changing the configuration information only requires replacing or modifying the device tree file, without modifying the source code or recompiling. Compared with the generation method of fixing the configuration array in the source code, this method can significantly improve the configuration flexibility and deployment efficiency.

[0092] The topology reference attributes in the device tree source file describe the reference relationships between modules, and reference numbers are automatically generated for referenced nodes during compilation. This allows the target machine to use the reference number as an index to locate the corresponding software module in the metabase class container, directly identifying and establishing connections between modules. Compared to the method requiring developers to manually maintain module numbers, this automatic topology connection between modules avoids the inefficiency and error-proneness of manual number maintenance.

[0093] By extracting configuration information shared by multiple software modules into independent subset device tree files, which can be referenced by multiple device tree source files, and by overriding the attributes of some nodes when referencing them, the configuration reuse requirement of large sets nested within smaller sets is realized, which significantly reduces repetitive configuration work and lowers maintenance costs.

[0094] The technical solution of this application will be illustrated below with a specific example.

[0095] like Figure 3 and 4 As shown, this instance contains three pipe nodes (UDP_IN, Ctrl2Para, Para2Out), three employee nodes (FMY_PATENT_CTRL, FMY_PATENT_Param, UDPI), and two behavior nodes (udpi, ctrl_update). The "inpipes" attribute of the FMY_PATENT_CTRL node references the UDP_IN and Para2Out pipes, and the "outpipes" attribute references the Ctrl2Para pipe. The "inpipes" attribute of the FMY_PATENT_Param node references the Ctrl2Para pipe, and the "outpipes" attribute references the Para2Out pipe. The "inpipes" attribute of the UDPI node references the Para2Out pipe, and the "outpipes" attribute references the UDP_IN pipe. The "employees" attribute of the ctrl_update behavior node references the FMY_PATENT_CTRL and FMY_PATENT_Param employees, and the "employees" attribute of the udpi behavior node references the UDPI employee.

[0096] The device tree source file corresponding to this instance is described as follows: / dts-v1 / ; / { model = "patent"; compatible = "USE_CASE_ID_PATENT"; pipes { UDP_IN: UDPI2Ctrl { compatible = "PIPE_TYPE_MSGQ"; nElementSize = <1024> ; }; Ctrl2Para: Ctrl2Para { compatible = "PIPE_TYPE_OPAQ"; nElementSize =<1024>; }; Para2Out: Para2Out { compatible = "PIPE_TYPE_OPAQ"; nElementSize =<1024>; }; }; employees { FMY_PATENT_CTRL: MY_PATENT_ctrl { compatible = "EMPLOYEE_TYPE_MY_PATENT_CTRL"; inpipes =<&UDP_IN&Para2Out>; outpipes =<&Ctrl2Para>; }; FMY_PATENT_Param: MY_PATENT_Para { compatible = "EMPLOYEE_TYPE_MY_PATENT_PARAM"; inpipes =<&Ctrl2Para>; outpipes =<&Para2Out>; strDevName = " / fm240"; }; UDPI: UDPI { compatible = "EMPLOYEE_TYPE_UDP_I"; inpipes =<&Para2Out>; outpipes =<&UDP_IN>; netDevName = "gem0"; localPort = <18002> ; remoteIp = [c0 a8 02 de]; remotePort =<18002> ; }; }; actions { udpi { compatible = "ACTION_TYPE_GENERIC"; employees =<&UDPI>; priority = <100> ; }; ctrl_update { compatible = "ACTION_TYPE_GENERIC"; employees =<&FMY_PATENT_CTRL&FMY_PATENT_Param>; priority = <200> ; }; }; After the device tree source file is compiled by the device tree compiler, the six nodes with aliases—UDP_IN, Ctrl2Para, Para2Out, FMY_PATENT_CTRL, FMY_PATENT_Param, and UDPI—are automatically assigned reference numbers 1, 2, 3, 4, 5, and 6, respectively. The nodes udpi and ctrl_update, since they are not referenced by other nodes, do not have aliases and therefore do not have reference numbers.

[0097] After the target machine loads the binary device tree file, it performs the following operations: First, the pipe factory iterates through the nodes under the "pipes" subclass path, creating three pipe objects—UDP_IN, Ctrl2Para, and Para2Out—based on the compatibility attributes of each node. The employee factory iterates through the nodes under the "employees" subclass path, creating three employee objects—FMY_PATENT_CTRL, FMY_PATENT_Param, and UDPI. The behavior factory iterates through the nodes under the "actions" subclass path, creating two behavior objects—udpi and ctrl_update. The target machine stores pointers to the six nodes with reference numbers in a metabase class container, at indices 1 to 6.

[0098] Then, the target machine begins establishing the connection. Taking the pipe binding of the FMY_PATENT_CTRL employee as an example, the "inpipes" attribute of this node has a value of "<&UDP_IN&Para2Out>". After DTC compilation, this attribute value is converted into reference numbers 1 and 3. The target machine reads pointers from the metabase class container using indices 1 and 3, obtaining the UDP_IN pipe object and the Para2Out pipe object respectively. It then calls the binding input pipe interface of the FMY_PATENT_CTRL employee object, passing the two pipe objects in sequence to complete the binding of the employee with the input pipe. Similarly, the "outpipes" attribute of this node has a reference number of 2. The target machine retrieves the Ctrl2Para pipe object using index 2 and calls the binding output pipe interface to complete the binding.

[0099] Taking the ctrl_update behavior for adding employees as an example, the “employees” attribute of this node has the value of “<&FMY_PATENT_CTRL&FMY_PATENT_Param>”. After DTC compilation, this is converted into reference numbers 4 and 5. The target machine uses 4 and 5 as subscripts to retrieve the FMY_PATENT_CTRL employee object and the FMY_PATENT_Param employee object from the metabase class container, calls the add employee interface of the ctrl_update behavior object, and passes the two employee objects in sequence to complete the assembly of the two employees by this behavior.

[0100] Finally, the target machine configures the parameters. Taking a UDPI employee as an example, the node's "netDevName" attribute value is "gem0", "localPort" attribute value is 18002, "remoteIp" attribute value is 192.168.2.222, and "remotePort" attribute value is 18002. After reading these configuration attributes, the target machine assigns the above values ​​to the corresponding member variables of the UDPI employee object.

[0101] After completing the generation of software modules based on the device tree, topology establishment, and parameter configuration, the target machine starts the software.

[0102] like Figure 5 The diagram illustrates a structural block diagram of an object-oriented software module generation system according to an embodiment of this application. The system includes a development machine 510 and a target machine 520. The development machine 510 is used to compile the device tree source file to generate a binary device tree file. Each node in the device tree source file corresponds to a software module to be created. Target machine 520 is used to load the binary device tree file; The target machine 520 is also used to traverse each node in the binary device tree file through the factory class, instantiate the corresponding software module for the node with compatibility attribute, and associate each instantiated software module with the reference number of the corresponding node in the metabase class container. The reference number is created for the referenced node when compiling the binary device tree file. The target machine 520 is also used to determine the reference number of the referenced node referenced by the node based on the topology reference attribute for nodes with topology reference attributes, and to find the corresponding software module from the metabase class container with the reference number as the index, and to establish the connection relationship between the found software module and the software module corresponding to the node. The target machine 520 is also used to configure the parameters of the corresponding software modules according to the configuration attributes of each node.

[0103] In an optional embodiment, the target machine 520 is further configured to create a metabase class container, wherein the index of the metabase class container corresponds one-to-one with the reference number of each node; and to store the pointers of each software module into the index position corresponding to the reference number of the corresponding node in the metabase class container. The target machine 520 is also used to read the pointer to the corresponding index position from the metabase class container using the reference number of the referenced node as the index, and to determine the corresponding software module based on the pointer.

[0104] In an optional embodiment, the target machine 520 is further configured to: Special software modules can be created using factory classes; Send refactoring instructions to all factory classes through a special software module; Each factory class, in response to a refactoring instruction, destroys the software modules it has created and recreates the software modules based on the new binary device tree file.

[0105] In an optional embodiment, the target machine 520 is further configured to: For each factory class, the nodes under the corresponding subclass path in the binary device tree file are traversed through the factory class. The subclass path is the path under the root node of the binary device tree file divided according to the software module category. The compatibility properties of the traversed nodes are read through the factory class; For nodes with compatibility attributes, a factory class is used to determine the software module class that matches the compatibility attribute, and the software module class is instantiated as a software module.

[0106] In an optional embodiment, development machine 510 is used for: Under the root node of the device tree source file, multiple sub-paths are divided according to the software module category; Create a node for each software module to be created under each subclass path; Set corresponding attributes for each node; The device tree source file is compiled into a binary device tree file using a device tree compiler.

[0107] In an optional embodiment, development machine 510 is also used for: Obtain a subset of the device tree file, which contains the defined nodes; Import the subset device tree file into the device tree source file; Redefine the attributes of some nodes in the subset device tree file in the device tree source file to override the corresponding attributes in the subset device tree file.

[0108] In an optional embodiment, development machine 510 is also used for: Set an alias for the referenced node that needs to be referenced by other nodes; Write the alias in the topology reference property of other nodes.

[0109] In summary, the object-oriented software module generation system provided in this application embodiment, by storing the configuration information of the software module in the form of an independent device tree file, completely separates it from the executable file. After the target machine loads the device tree file, the software module can be dynamically created and assembled. In this way, changing the configuration information only requires replacing or modifying the device tree file, without modifying the source code and recompiling. Compared with the generation method of fixing the configuration array in the source code, it can significantly improve the configuration flexibility and deployment efficiency.

[0110] The topology reference attributes in the device tree source file describe the reference relationships between modules, and reference numbers are automatically generated for referenced nodes during compilation. This allows the target machine to use the reference number as an index to locate the corresponding software module in the metabase class container, directly identifying and establishing connections between modules. Compared to the method requiring developers to manually maintain module numbers, this automatic topology connection between modules avoids the inefficiency and error-proneness of manual number maintenance.

[0111] By extracting configuration information shared by multiple software modules into independent subset device tree files, which can be referenced by multiple device tree source files, and by overriding the attributes of some nodes when referencing them, the configuration reuse requirement of large sets nested within smaller sets is realized, which significantly reduces repetitive configuration work and lowers maintenance costs.

[0112] One embodiment of this application provides a computer-readable storage medium storing at least one instruction, which is loaded and executed by a processor to implement the object-oriented software module generation method described above.

[0113] One embodiment of this application provides an electronic device that includes the object-oriented software module generation system described above.

[0114] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of this application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0115] like Figure 6 As shown, the electronic device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. The RAM 603 may also store various programs and data required for the operation of the electronic device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0116] Multiple components in electronic device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of displays, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows electronic device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0117] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as data processing methods. For example, in some embodiments, the data processing methods may be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the data processing methods described above may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform data processing methods by any other suitable means (e.g., by means of firmware).

[0118] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0119] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

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

[0121] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0122] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0123] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0124] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0125] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for generating object-oriented software modules, characterized in that, In a software module generation system comprising a development machine and a target machine, the method includes: The development machine compiles the device tree source file to generate a binary device tree file, and each node in the device tree source file corresponds to a software module to be created; The target machine loads the binary device tree file; The target machine traverses each node in the binary device tree file through the factory class, instantiates the corresponding software module for the node with compatibility attribute, and associates each instantiated software module with the reference number of the corresponding node in the metabase class container. The reference number is created for the referenced node when compiling the binary device tree file. For a node with a topological reference attribute, the target machine determines the reference number of the referenced node referenced by the node based on the topological reference attribute, and uses the reference number as the index to search for the corresponding software module in the metabase class container, and establishes a connection relationship between the searched software module and the software module corresponding to the node. The target machine configures the parameters of the corresponding software modules according to the configuration attributes of each node.

2. The object-oriented software module generation method according to claim 1, characterized in that, The step of associating and recording the reference numbers of the instantiated software modules with the corresponding nodes in the metabase class container includes: the target machine creating a metabase class container, the index of the metabase class container corresponding one-to-one with the reference number of each node; and storing the pointer of each software module in the index position corresponding to the reference number of the corresponding node in the metabase class container. The step of finding the corresponding software module from the metabase class container using the reference number as the index includes: the target machine reading the pointer at the corresponding index position from the metabase class container using the reference number as the index, and determining the corresponding software module based on the pointer.

3. The object-oriented software module generation method according to claim 1, characterized in that, The method further includes: The target machine creates special software modules through a factory class; The target machine sends a refactoring instruction to all factory classes through the special software module; The target machine, in response to the refactoring instruction through each factory class, destroys the software modules it has created and recreates the software modules according to the new binary device tree file.

4. The object-oriented software module generation method according to claim 1, characterized in that, The target machine traverses each node in the binary device tree file using a factory class, instantiating corresponding software modules for nodes with compatibility attributes, including: For each factory class, the target machine traverses the nodes under the corresponding subclass path in the binary device tree file through the factory class. The subclass path is the path divided according to the software module category under the root node of the binary device tree file. The target machine reads the compatibility attributes of the traversed nodes through the factory class; For nodes with compatibility attributes, the target machine determines a software module class that matches the compatibility attribute through the factory class, and instantiates the software module class into a software module.

5. The object-oriented software module generation method according to claim 1, characterized in that, The development machine compiles the device tree source file to generate a binary device tree file, including: The development machine divides multiple sub-paths under the root node of the device tree source file according to the software module category; The development machine creates a node for each software module to be created under each subclass path; The development machine sets corresponding attributes for each node; The development machine uses a device tree compiler to compile the device tree source file into a binary device tree file.

6. The object-oriented software module generation method according to claim 5, characterized in that, The method further includes: The development machine obtains a subset device tree file, which contains defined nodes; The development machine imports the subset device tree file into the device tree source file; The development machine redefines the attributes of some nodes in the subset device tree file in the device tree source file to override the corresponding attributes in the subset device tree file.

7. The object-oriented software module generation method according to claim 5, characterized in that, The method further includes: The development machine sets aliases for referenced nodes that need to be referenced by other nodes; The development machine writes the alias into the topology reference attribute of the other nodes.

8. A software module generation system, characterized in that, The software module generation system includes a development machine and a target machine; The development machine is used to compile the device tree source file to generate a binary device tree file, where each node in the device tree source file corresponds to a software module to be created. The target machine is used to load the binary device tree file; The factory class traverses each node in the binary device tree file, instantiates the corresponding software module for the node with compatibility attribute, and associates each instantiated software module with the reference number of the corresponding node in the metabase class container. The reference number is created for the referenced node when the binary device tree file is compiled. For a node with a topological reference attribute, the reference number of the referenced node is determined according to the topological reference attribute. The corresponding software module is searched from the metabase class container using the reference number as the index, and a connection relationship is established between the searched software module and the software module corresponding to the node. Configure the parameters of the corresponding software modules according to the configuration attributes of each node.

9. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction, which is loaded and executed by a processor to implement the object-oriented software module generation method as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, The electronic device includes the software module generation system as described in claim 8.

Images