Component construction method, system construction method, related device and electronic device

Abstract

The application discloses a component construction method, a system construction method, related devices and electronic equipment. The application finds the root cause of the problem from the basic component structure of the software system, takes the module division angle as the breakthrough point, pre-agrees a set of fixed interfaces, constructs an abstract interaction model of things by the fixed interfaces, carries out module (element or component) isolation / division based on the fixed interfaces, standardizes the boundary and interaction mode of the module, so that the modules are not coupled or weakly coupled, each module can be developed independently, and the modules can be configured and assembled before running, so that a large number of independent elements and components can be developed for software system development based on the components, thereby, the application solves the technical problems in the software development of the prior art from the basic component structure of the software system, that is, the root cause of the problem, so that the software development is improved in iteration efficiency, stability, change adaptability, resource consumption, system complexity and the like.

Description

Technical Field

[0001] This application belongs to the field of software development technology, and in particular relates to a component construction method, a system construction method, related devices and electronic devices. Background Technology

[0002] As modern software systems become increasingly complex, the technical systems and frameworks involved in software development are becoming increasingly large, and business functions are becoming more numerous and changing more frequently.

[0003] Modularization has always been a core issue in software development. Existing modular frameworks provide corresponding specifications and technical solutions for module construction and assembly. These technologies include, but are not limited to: A) Connecting fine-grained classes using reverse injection (IoC, Inversion of Control) configuration, as exemplified by Spring, to form a complete system for operation (e.g., Spring Boot combines modules with dependency libraries, scanning annotated beans in the library to complete module assembly when the application starts); B) Microservice-izing components, as exemplified by Docker and Kubernetes, using independently runnable applications to build components, running and updating components in multiple runtime environments, and relying on the Kubernetes service management system to complete component connections; C) Packaging components in a specific way, as exemplified by Jigsaw, for loading and connecting components in the same runtime environment; D) Packaging components in a specific way, as exemplified by OSGi (Open Service Gateway Initiative), for dynamically loading, unloading, updating, and connecting components in the same runtime environment, etc.

[0004] The above technical architecture A is a single application running in an independent environment, technical architecture B is a microservice architecture, and technical architecture D is an optimization of technical architecture C. Ideally, technical architecture D combines the characteristics of both single application and microservice architecture. The applicant found that existing common technologies such as A / B / C / D generally have problems in software development, such as development and iteration efficiency, stability, adaptability to changes, resource consumption, and system complexity. Summary of the Invention

[0005] In view of this, this application provides a component construction method, a system construction method, related devices and electronic devices. By isolating and dividing modules based on defined fixed interfaces and interface specifications, the boundaries and interaction modes of modules are standardized and regulated, enabling the development of a large number of independent elements and components. On this basis, component-based software system development (construction) is carried out, thereby solving the above-mentioned problems in software development from the basic structural composition of the software system, i.e., the root cause of the problem.

[0006] The specific technical solution is as follows:

[0007] A component construction method, comprising:

[0008] Obtain the individual target components required to build the target component; wherein the component is assembled from a set of components, each component being developed through an abstract interaction model that constructs things using interfaces from a predefined set of fixed interfaces;

[0009] Assemble the target components and expose parameters and services during assembly;

[0010] Configure component element information for the assembly results;

[0011] The assembly results with completed metadata configuration are packaged into components to obtain the target component.

[0012] Optionally, obtaining the multiple target elements required to construct the target component includes:

[0013] Determine if the target component required to build the target component exists in the component library;

[0014] If present, select the desired target component from the component library;

[0015] If it does not exist, develop the required target component;

[0016] Specifically, the target components required for development are realized by developing corresponding modules based on the fixed interfaces in the fixed interface set. When developing a module, the interfaces and interface methods defined in the fixed interface set are used to refer to the internal references to the external modules and the operations on the referenced targets. The services provided by the module to the external modules and the operations contained therein are implemented as the corresponding interfaces and interface methods in the fixed interface set.

[0017] Optionally, assembling the various target components includes:

[0018] Different target components are associated with each other based on a preset association method, so that the target components can be assembled into a component through the interrelation between the target components;

[0019] The association method can be any one of the following: specifying the association between different target components based on a configuration file, specifying the association between different target components by running a specific program, specifying the association between target components by matching the module features of different target components, or specifying the association between different target components based on changes in preset environment variables during component construction.

[0020] Optionally, when associating different target components with each other, the component modules of the corresponding target components can be parameterized to adjust the internal functional logic of the modules to adapt to the needs of the associated modules.

[0021] Optionally, the predefined set of fixed interfaces includes resource class interfaces, process class interfaces defined by treating things as resources and processes, and also includes extended interfaces.

[0022] A system construction method, comprising:

[0023] Obtain the target components required to build the target software system; wherein each component is developed as an abstract interaction model that constructs things through fixed interfaces in a fixed interface set;

[0024] Instantiate each target component to obtain a component instance of each target component;

[0025] The target software system is obtained by assembling the various component instances.

[0026] Optionally, obtaining the various target components required to construct the target software system includes:

[0027] Determine whether the target components required to build the target software system exist in the component library;

[0028] If it exists, select the desired target component from the component library;

[0029] If it does not exist, develop the required target component using any of the component construction methods described above.

[0030] Optionally, in the above system construction methods:

[0031] Components are developed by constructing an abstract interaction model of things using interfaces from a predefined set of fixed interfaces;

[0032] References from a component to the outside of the component and operations on the referenced target are referred to using the interfaces and interface methods defined in the fixed interface set;

[0033] The services provided by the component to the outside world and the operations contained therein are implemented as the corresponding interfaces and interface methods of the fixed interface set.

[0034] Optionally, the instantiation of each target component to obtain a component instance of each target component includes:

[0035] The container loads each target component and the instantiation configuration information written for each target component, and creates component instances of each target component based on the loaded target components and instantiation configuration information.

[0036] Optionally, assembling the various component instances to obtain the target software system includes:

[0037] The container loads information that is associated with different target components based on a preset association method. The component instances of each target component are associated with each other based on the loaded association information. The associated component instances constitute the target software system.

[0038] The association method can be any of the following: specifying the association between different target components based on a configuration file, specifying the association between different target components by running a specific program, or not specifying the association between different target components.

[0039] Matching the module features of the target component specifies the association between target components, and specifying the association between different target components based on changes in preset environment variables during software system construction.

[0040] Optionally, the above system construction method also includes:

[0041] The target software system is run using a container;

[0042] In response to load, unload, or update instructions for components and / or associations between components of the target software system, during the operation of the target software system, the instructions are dynamically loaded, unloaded, or updated for at least one component and / or associations between components indicated by the target software system.

[0043] An operating device is used to load required modules, associate and assemble the loaded modules into an operable system according to a preset association method, and run the resulting system within the operating device.

[0044] The loaded modules are developed using an abstract interaction model that constructs things through fixed interfaces in a fixed interface set.

[0045] Optionally, the operating device can parameterize the corresponding modules to adjust the internal functional logic of the modules to adapt to the needs of the associated modules.

[0046] Optionally, the module is a component or assembly; the module can be loaded, unloaded, updated, or configured by the operating device during runtime to create, cancel, and modify modules of the system during runtime;

[0047] The information of the association method can be loaded, unloaded or updated by the running device during runtime, so as to establish, cancel and change the association relationship between different modules during runtime.

[0048] Optionally, the operating device may parameterize the corresponding association method when loading or updating the association method in order to adjust and adapt the association relationship between modules.

[0049] Optionally, the association method is implemented by a parameterizable association component;

[0050] The association method is loaded, updated, and parameterized by generating instances of the associated components and by loading, updating, and parameterizing the instances of the associated components.

[0051] Optionally, the operating device is a container device.

[0052] A component building apparatus, comprising:

[0053] The first acquisition module is used to acquire the target components required to build the target component; wherein, the component is assembled from a set of components, and each component is developed through an abstract interaction model that constructs things through a fixed interface in a fixed interface set;

[0054] The first assembly module is used to assemble the various target components and expose parameters and services during assembly;

[0055] The meta-information configuration module is used to configure component meta-information for the assembly results.

[0056] The packaging module is used to package the assembly results with completed metadata configuration into components to obtain the target component.

[0057] A system construction apparatus, comprising:

[0058] The second acquisition module is used to acquire the target components required to build the target software system; wherein each component is developed through an abstract interaction model that constructs things using fixed interfaces in a fixed interface set;

[0059] The instantiation module is used to instantiate each target component and obtain component instances of each target component;

[0060] The second assembly module is used to assemble the various component instances to obtain the target software system.

[0061] An electronic device, comprising:

[0062] Memory, used to store at least the computer instruction set;

[0063] A processor is configured to invoke and execute the computer instruction set in the memory, thereby implementing the component construction method as described in any of the preceding descriptions, or implementing the system construction method as described in any of the preceding descriptions.

[0064] This application addresses the root cause of problems by tracing the basic structure of software systems. It takes module partitioning as its starting point, pre-defining a set of fixed interfaces to construct abstract interaction models of things. Based on these fixed interfaces, modules (components or components) are isolated / partitioned, and the boundaries and interaction patterns of modules are standardized and regulated. This results in decoupling or weak coupling between modules, allowing each module to be developed independently and configured and assembled before operation. This enables the development of numerous independent components for component-based software system development / construction. Thus, this application solves the technical problems existing in software development from the root cause—the basic structure of the software system—improving aspects such as iteration efficiency, stability, adaptability to change, resource consumption, and system complexity. Attached Figure Description

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

[0066] Figure 1(a) shows the module calling method of existing technology A based on a single application such as Spring Boot;

[0067] Figure 1(b) shows the system module calling method of existing technology B based on microservice architecture;

[0068] Figure 1(c) shows the system call method of existing technology D based on a single container like OSGi, constructed using a dynamic component architecture;

[0069] Figure 2 This is a flowchart of the component construction method provided in this application;

[0070] Figure 3 This application provides a classification and lineage diagram of the fixed interfaces defined in this application;

[0071] Figure 4 This is an exemplary step flow of the development components provided in this application;

[0072] Figure 5 This is a flowchart of the system construction method provided in this application;

[0073] Figure 6 This application provides a four-stage system development process: interface definition, module development, system configuration, and device operation.

[0074] Figure 7This is an exemplary step flow of the software development system provided in this application;

[0075] Figure 8 This is another flowchart of the system construction method provided in this application;

[0076] Figure 9 This is an exemplary procedure for operating and updating the software system provided in this application;

[0077] Figure 10 This is a structural diagram of the component construction apparatus provided in this application;

[0078] Figure 11 This is a structural diagram of the system construction device provided in this application. Detailed Implementation

[0079] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0080] Modularization in software engineering has always been a core issue in software development. How to preserve existing knowledge in the form of software modules, how to form valuable, stable, adaptable and easy-to-assemble modular components, how to effectively reuse modular components during system development and construction, and how to continuously adjust and update the system according to changes in environment and requirements during system operation and maintenance all affect many core values ​​of the software system, such as quality, development iteration efficiency, R&D and maintenance costs, and response efficiency to changes.

[0081] The core of modularity lies in the division, construction, and assembly of modules. Existing modular frameworks, such as the technical architectures A / B / C / D mentioned above, provide corresponding specifications and technical solutions for module construction and assembly. Based on a further analysis and research of each technical framework (A / B / C / D), the following details the defects or problems existing in each framework during software development.

[0082] Among them, technology framework A is a single application. Its advantage is that it is a single application and runs in an independent environment. However, considering the module calling method of technology A based on a single application like Spring Boot in Figure 1(a), the disadvantages of technology framework A are as follows:

[0083] 11) Although Spring uses IoC injection and configuration to decouple modules, it is mainly used for automated adaptation and assembly of common services. The invocation and operation of these services are still performed by developers in the code. Code dependency means that any changes need to be made in the code. Changes in business logic or dependent libraries may lead to changes in the code itself, requiring re-integration, compilation, and deployment.

[0084] 12) The dependencies of the library (module) are integrated into various application systems, so library upgrades and refactoring will affect each system.

[0085] 13) Dependencies in code integration lead to a lack of module isolation. Problems in local modules affect the overall system and increase the possibility of conflicts, making the system increasingly complex and difficult to maintain.

[0086] 14) For large-scale systems, it is not convenient to develop and integrate in groups, making it difficult to improve the parallelism of research and development and development efficiency;

[0087] 15) When the application becomes large, it is not easy to scale up, and the deployment and maintenance costs are high.

[0088] Technical architecture B is a microservice architecture, which alleviates many problems of monolithic applications; however, it also brings other problems. Referring to the system module calling method of technical architecture B based on microservice architecture shown in Figure 1(b), the main drawback of this technology is:

[0089] 21) Microservices bring about the problem of service unavailability, introducing a series of issues such as service governance, tracing, and monitoring;

[0090] 22) Microservices break down business logic into services, leading to a series of problems such as distributed transactions and data consistency.

[0091] 23) The inter-process calling method of microservices brings additional system overhead. Using microservices often requires more hardware devices and network bandwidth to support the operation, data transmission and collaboration of large systems on many nodes.

[0092] 24) Microservices introduce a large number of runtime components, each requiring independent configuration, deployment, operation, and maintenance, and also needing to be interconnected. Maintaining operational health itself also introduces a large number of additional components, making problem tracking and localization more complex. Essentially, it externalizes complexity.

[0093] Technical architecture D is an optimization of technical architecture C; the following discussion focuses solely on technical architecture D. Ideally, technical architecture D combines the characteristics of both monolithic applications and microservice architectures. However, it presents numerous practical problems, hindering its widespread adoption. Referring to Figure 1(c), technical architecture D, based on a system call approach using a single container like OSGi built with dynamic components, suffers from the following issues:

[0094] 31) OSGi's advantages lie in its modularity and dynamism, emphasizing component reuse and system component development. However, due to the different service interfaces exposed between components, assembling various components together is not easy. In fact, many components need to know the interface characteristics and usage of the called party in order to use the services of other components. This rigid combination pattern reduces the standardization and reusability of components, makes OSGi's component loading meaningless, and restricts the variability of the system.

[0095] 32) Dynamic loading, due to explicit or implicit code dependencies between components (such as referencing packages, classes, or methods exported by other bundles), can prevent components loaded using the classloader from being completely unloaded. Such systems cannot be updated smoothly, potentially leading to system failures caused by the coexistence of old and new code, and even memory leaks. Therefore, component loading provided by the OSGi architecture also presents numerous problems in practice.

[0096] 33) The root cause of the above problems is that the modules are not truly independent and there are hidden, spreading dependencies. These dependencies make it difficult for the atomic components of the system to be formed, and also affect the dynamic loading and release of modules at runtime, thus reducing the dynamic changes and adaptability of the system.

[0097] In summary, existing technical architectures generally suffer from problems in system development, such as development and iteration efficiency, stability, adaptability to changes, resource consumption, and system complexity.

[0098] Existing modular frameworks (such as the technical frameworks A / B / C / D mentioned above) do not involve methods for dividing modules, which affects the isolation, decoupling, and reusability of modules. The module development process is independent of the software system assembly and operation process, and is a key step for the system to respond quickly and effectively to changes and to update and iterate the system. Poor module isolation, decoupling, and reusability are the root causes of the problems in existing technical architectures.

[0099] To address the problems existing in the above-mentioned existing technical architectures, this application seeks the root causes from the basic structural composition of the software system, and provides solutions from the perspective of module division. Specifically, it provides a component construction method, a system construction method, related devices, and electronic devices. The related devices include an operating device, a component construction device, and a system construction device.

[0100] Optionally, the solution in this application is implemented based on the Spring and OSGi (Apache Felix) technology framework.

[0101] This application starts by defining a fixed interface specification for inter-module calls, provides a module partitioning scheme, and based on this, proposes a component construction method that makes the developed components easier to associate and reuse. It also proposes a system construction method (a component-based system construction method) that allows the system to dynamically load, unload, update, and change one or more components as needed during runtime (including but not limited to changes in internal business logic and / or the external environment), thereby fundamentally solving the technical problems existing in current technical architectures.

[0102] To implement the proposed component construction method, system construction method, and related devices, this application defines a set of fixed interfaces and matching interface methods, forming a corresponding fixed interface set, so as to provide a foundation for subsequent module division and component / system construction.

[0103] A module can be a component or a part.

[0104] This application specifically views all things as resources and processes. Resources represent the static state of "things", and processes represent the dynamic state of "things". It also regards the calculation and processing of any system as the result of the process running on resources. Accordingly, it defines two types of interfaces: "resources" and "processes". That is, the fixed interfaces in the fixed interface set include at least "resource" class interfaces and "process" class interfaces.

[0105] Resources refer to entities that store information about "things," while processes refer to operations that handle such information.

[0106] Optionally, considering scenarios where the abstract models of resources and processes may be difficult to cover, an extended model can be further added in practical applications. Therefore, in addition to the two types of interfaces, "resources" and "processes", an extended interface can be added. These three types of interfaces together constitute a fixed interface set.

[0107] In one example, this application defines a set of 15 interfaces for the three interface types mentioned above, and provides corresponding interface methods. See [link to relevant documentation]. Figure 3 This illustrates the classification and lineage of these interfaces.

[0108] It should be noted that, without loss of generality, the interfaces and interface methods of the "Resources" and "Processes" categories designed in actual applications may be added to, reduced to, or changed compared to this example, as long as they follow the same or similar abstraction of relationships between things, they can have the same or similar technical effects; similarly, the interfaces and methods of the "Extension" category designed may also be added to, reduced to, or changed compared to this example, as long as they follow the same or similar abstraction of relationships between things, they can have the same or similar technical effects.

[0109] Furthermore, without loss of generality, the interface set in this example can also be replaced with any other predefined interface set. As long as the replacement interface follows the same or similar abstraction of things and can express the relationship between modules, it can have the same or similar technical effect.

[0110] Based on this, an abstract interaction model of things is constructed based on the defined fixed interface, the boundaries and interaction modes of modules are standardized and normalized, the division / isolation of modules (components or components) is realized, and the development of modules (components or components) is carried out to form corresponding component libraries and component libraries.

[0111] For any module, references and operations not contained within this module (including but not limited to objects, methods, or procedures, which typically point to other modules) are referred to using one or more defined fixed interfaces and interface methods; for any module, if it provides services and operations (including but not limited to objects, methods, or procedures) to the outside of the module, these services and operations are implemented as one or more defined interfaces and methods.

[0112] Furthermore, this application defines methods for associating modules to link required modules (components / devices) during the development / building of a component or system. These association methods include, but are not limited to: specifying associations between different modules using configuration files, specifying associations between different modules by running specific programs, specifying associations between different modules based on matching certain characteristics of the modules, or specifying associations between different modules based on changes in specific environment variables.

[0113] Optionally, when associating modules (components or assemblies) with each other, the modules can be parameterized according to configuration files or other equivalent methods to adjust the internal functional logic of the modules to meet the needs of the associated modules.

[0114] Optionally, the module can be a Spring bean developed based on Java, and can be associated and configured using Spring's XML or Groovy methods.

[0115] This application uses predefined fixed interfaces and methods to express the relationships between modules. The development of any module should adhere to this interface specification to ensure that modules can be combined through these interfaces. During development, any module needs to express unknown parts that do not belong to its own module (reference points where the module is coupled with external modules) using these defined fixed interfaces and methods. Furthermore, any module that might be referenced by other modules needs to implement the corresponding defined fixed interfaces and methods. By adhering to the unified interface specification defined in this application, independent modules can be developed, iterated, and changed without interference.

[0116] Based on the defined association between modules, these independent modules can be assembled into various integrated systems, so that the assembled systems can be run on operational devices.

[0117] Based on the development of modules using defined fixed interfaces to form a component library, further development and construction of components can be carried out based on the component library. See also Figure 2 The flowchart shown illustrates the component construction method. The processing steps of the component construction method provided in this application include:

[0118] Step 201: Obtain the target components required to build the target component; wherein, the component is assembled from a set of components, each of which is developed by constructing an abstract interaction model of things through an interface of a predefined fixed interface set.

[0119] When developing components, the target components required to build the target component can be obtained according to the requirements. First, it can be determined whether the target components required to build the target component exist in the component library of the platform's basic library. If they exist, the required target components can be selected directly from the component library. If they do not exist (some or all of the target components do not exist in the component library), the required target components can be temporarily developed based on the fixed interfaces defined in the fixed interface set and the interface specifications that must be followed.

[0120] The following is an example of a component developed based on a fixed interface and corresponding specifications. This component provides an implementation of the IProcessor interface, while the code uses two external references: IListable and IBiProcessor.

[0121]

[0122] Step 202: Assemble each target component and expose parameters and services during assembly.

[0123] For each target component acquired, different target components can be further associated with each other based on a preset association method, so as to assemble each target component into a component through the association between target components. In this process, the parameters and services of the component are exposed to the outside world when associating components.

[0124] When associating different target components with each other, the component modules of the corresponding target components can be parameterized to adjust the internal functional logic of the modules to adapt to the needs of the associated modules.

[0125] Regarding the association between components, the association methods can be, but are not limited to: specifying the association between different target components based on configuration files, specifying the association between different target components by running a specific program, specifying the association between target components by matching the module characteristics of different target components, or specifying the association between different target components based on changes in preset environment variables during component development.

[0126] For example, the various target elements obtained can be assembled into a component using Spring's XML configuration file. The following provides an example of associating components using Spring's XML configuration file, and the component's parameters (such as framework.test.counter.processor in this example) and services (such as the bean with the id "counter" defined in this example) can be exposed externally in the configuration file:

[0127]

[0128] Step 203: Configure component element information for the assembly results.

[0129] Step 204: Package the assembly results with completed metadata configuration into components to obtain the target component.

[0130] After assembling / assembling each target component to obtain the corresponding assembly result, the component meta-information is further configured, and the assembly result with completed meta-information configuration is packaged to form a component, thereby realizing the construction of the target component.

[0131] Optionally, you can configure the component's metadata according to the iPojo specification and package it into an OSGi bundle using the maven-ipojo-plugin tool provided by iPojo to achieve component building. The component's metadata about iPojo will be compiled into the bundle's MANIFEST.MF. The following provides an example of the component packaging configuration information:

[0132]

[0133] Packaged components can be used in subsequent system build processes or published to a component library for later use. Components in the component library can specifically be OSGi-defined components.

[0134] See Figure 4 This application provides an exemplary step-by-step process for component development based on the component construction method of this application.

[0135] The processing flow of the system construction method disclosed in the embodiments of this application is as follows: Figure 5 As shown, it specifically includes:

[0136] Step 501: Obtain the target components required to build the target software system; wherein each component is a component developed by constructing an abstract interaction model of things through fixed interfaces in a fixed interface set, the fixed interface set including at least fixed interfaces defined by treating things as resources and processes.

[0137] From a global perspective, this application divides the software system development process into four stages: interface definition, module development, system configuration, and device operation. For details, please refer to... Figure 6 The system development process is shown in four stages: interface definition, module development, system configuration, and device operation.

[0138] The first phase of interface definition refers to defining fixed interfaces by treating things as resources and processes. For details, please refer to the relevant explanations on fixed interfaces and fixed interface sets above, which will not be repeated here.

[0139] The subsequent three stages, namely module development, system configuration, and device operation, are relatively independent processes (there may be nesting within the processes), and the stages do not maintain a certain order. For example, system configuration can be performed first, and then the components can be developed only when there are no suitable components in the component library.

[0140] The module development phase refers to the development of modules based on defined fixed interfaces and interface specifications, resulting in a large number of independent components and parts, forming the component library and part library required by the platform's basic library. Both the interface definition phase (first stage) and the module development phase (second stage) are preprocessing (pre-processing) parts of the overall software system development / build process. Figure 5 The system construction process shown mainly corresponds to the third and fourth stages.

[0141] Based on the development of modules according to the defined fixed interfaces and the interface specifications to be followed, and the formation of a component library, when it is necessary to build the target software system, it can first be determined from the component library whether the target component required to build the target software system exists. If it exists, the target component required can be selected directly from the component library. If it does not exist, the target component required can be temporarily developed based on the component construction method and process provided in this application.

[0142] The components are developed by constructing an abstract interaction model of things using interfaces from a predefined set of fixed interfaces; references from the components to the outside world and operations on the referenced targets are referred to using the interfaces and interface methods defined in the set of fixed interfaces; services provided by the components to the outside world and the operations contained therein are implemented as the corresponding interfaces and interface methods of the set of fixed interfaces.

[0143] Step 502: Instantiate each target component to obtain a component instance of each target component.

[0144] Next, the acquired target components are instantiated.

[0145] First, for the acquired target component, an instantiation configuration file (such as a config file) needs to be written for its instantiation configuration. Optionally, the filename of the instantiation configuration file follows the specification {component name}-{instance name}.config. For example, counter-counter1.config defines an instance of the component counter, whose instance name is counter1. The following is an example configuration file for component instantiation:

[0146]

[0147] The instantiation configuration file mentioned above is a properties file, where: requests.filter is used to configure the filtering conditions for external references of the current instance; service.description is used for self-description so that the filter can perform runtime filtering and matching; service.ranking is used to indicate the priority of the current instance, and when multiple instances match successfully, the one with higher priority will be assembled first; config is used to fill in the configuration of component parameters for the current instance, with # as the separator, such as in the example above, config means that the test.documents.base parameter in the Spring XML configuration is configured as scores / ; the remaining parameters are mainly used for setting the runtime environment.

[0148] Based on the instantiation configuration files written for the target components, the container can load each target component and the instantiation configuration information written for each target component, and create component instances of each target component based on the loaded target components and instantiation configuration information.

[0149] Step 503: Assemble the various component instances to obtain the target software system.

[0150] This embodiment assembles various component instances into a whole system by associating them with each other. Specifically, a container can be used to load association information specified for different target components based on a preset association method, and the component instances of each target component are associated with each other based on the loaded association information. The associated component instances then constitute the required target software system.

[0151] Regarding the association of components, the above association methods may include, but are not limited to: specifying the association between different target components based on configuration files, specifying the association between different target components by running a specific program, specifying the association between target components by matching the module features of different target components, and specifying the association between different target components based on changes in preset environment variables during system development.

[0152] In an alternative implementation, an association instance config is written to associate component instances and references of each target component.

[0153] Furthermore, optionally, the platform's base library provides a parameterizable linker component for generating associations. Correspondingly, by generating instances of the linker component, an associated instance for implementing component association can be obtained. The convention is to generate an instance of the linker component using `{component name}-{reference instance name}_{pointer to instance name}_{reference name}.config`, such as `linker-counter_matcher_processor.config`. The first part of the filename, `linker`, indicates that an instance of the linker component is being generated. The following `counter_matcher_processor` refers to a reference to the instance `matcher`, which is referenced by the instance `counter`. This reference is named `processor` within `counter`. The following provides an example configuration file for linker instantiation:

[0154] bean = "matcher"

[0155] service.description="counter_matcher_processor"

[0156] name="processor"

[0157] requires.filters=""service","(service.description\=matcher)"]

[0158] The configuration file for the linker instantiation described above is a properties file. Here, `service.description` and `requirements.filter` have the same meaning as the component instance, used to match and filter instances, connecting the component instances at both ends of the adaptation pipeline; `name="processor"` declares that the linker is used to replace a reference named `processor`; `bean` indicates which component it is linked to, in this case, a bean named `matcher`. Through this linker, the `processor` reference in the `counter` instance is pointed to the `matcher` bean in the `matcher` instance.

[0159] After completing the writing of the above components, configuration files, and related documents, the system is assembled. All these files constitute the overall system files of the target software system, which can be deployed to the running device provided in this application.

[0160] Based on this, the associated information specified for different target components based on a preset association method can be loaded into the container on the running device, and the component instances of each target component can be associated with each other and assembled into a complete software system based on the loaded associated information, so as to obtain the required target software system.

[0161] See Figure 7 This application provides an exemplary step-by-step process for constructing a software system based on the system construction method described herein.

[0162] As can be seen from the above scheme, this application seeks the root cause of the problem from the basic composition structure of the software system. Accordingly, it takes the perspective of module division as the starting point, regards things as resources and processes, defines fixed interfaces, constructs an abstract interaction model of things with fixed interfaces, and performs module (element or component) isolation / division based on fixed interfaces. It standardizes and regulates the boundaries and interaction modes of modules, so that there is no coupling or weak coupling between modules. Each module can be developed independently and configured and assembled before running. This enables the development of a large number of independent elements and components for component-based software system development / construction. Thus, this application solves the technical problems existing in software development from the basic composition structure of the software system, i.e., the root cause of the problem, and improves software development in terms of iteration efficiency, stability, change adaptability, resource consumption, system complexity, etc.

[0163] Furthermore, in this application, the module development phase focuses on individual, independent modules, while the system configuration phase associates different modules with the overall system. These different phases separate module development and association. In the module development phase, modules are constructed based on defining fixed interfaces by treating things as resources and processes, and following the abstraction of relationships between things, without relying on functional or business customizations, thereby improving module independence and reusability.

[0164] In one embodiment, see Figure 8 The system construction method disclosed in this application may further include the following processing after step 503:

[0165] Step 504: Run the built target software system using a container.

[0166] Specifically, after the constructed target software system is published to the running device of this application, the target software system can be run based on the running device of this application.

[0167] Optionally, the running device of this application is a container device. Further, based on hardware and software devices capable of running a Java environment, the running device can be a Felix iPojo container or a similar OSGi environment containing the component library and component library provided in this application. The component library can provide common, general-purpose components for configuration, while the component library can provide common, instantiable components and some default-loaded component instances to provide platform services.

[0168] Correspondingly, containers (such as the iPojo container) can be used in the running device to load various files such as components, configurations, associations, and instantiations of the published target software system. Based on the loaded files, a series of system components are instantiated and connected in the container to form a whole system and execute the system's business logic and functions.

[0169] Specifically, this can be achieved by executing the corresponding command, such as `java –cp lib / org.apache.felix.main.jar org.apache.felix.main.Main`, to start the container and load the default component instances and services.

[0170] Optionally, the runtime can scan a specified directory through the platform service and load the component bundles and instantiation configuration files in that directory into the container. Of course, these objects can also be loaded from other storage or in other ways in an equivalent manner.

[0171] The operating apparatus of this application will be described in further detail in the following embodiments.

[0172] Step 505: In response to load, unload, or update instructions for components and / or associations between components of the target software system, during the operation of the target software system, dynamically load, unload, or update the at least one component and / or associations between components indicated by the above instructions in the target software system.

[0173] When the software system needs to be updated, the relevant files of components, configurations or associations in the specified directory can be modified. In actual applications, it may also be necessary to redevelop or configure these files according to the component building process and / or system configuration process of this application.

[0174] The operating device can monitor the designated directory through platform services. Based on changes in the content of objects within that directory, such as the addition, deletion, or modification of components / associations, it triggers loading, unloading, or updating instructions for the corresponding components and / or associations. Responding to these instructions, during software system operation, it dynamically unloads deleted components / associations, loads newly added components / associations, and reloads modified components / associations from the directory to update the software system according to the new configuration. This is easily understood; equivalent updates to these configurations can also be made from other storage or through other methods.

[0175] Newly added or updated components and configurations are instantiated and connected within the iPojo container (only the changed components and configurations are partially updated), forming a unified system with the unchanged parts of the system, thus updating the software system. New business logic and functions are then executed on the updated software system. See also... Figure 9 It provides an exemplary procedure for running and updating a software system.

[0176] In this embodiment, any local component within the container and its corresponding instance and association can be dynamically loaded, updated and unloaded during system operation, thereby causing changes to the overall system. Moreover, since all operations in this application are performed within a single process, the efficiency of its dynamic loading and unloading is significantly improved compared to microservices.

[0177] The operating apparatus disclosed in the embodiments of this application is further described in detail below.

[0178] The runtime device may be, but is not limited to, a Java environment that can run with Spring or (and) OSGi framework libraries, for loading the required modules, associating and assembling the loaded modules into a runnable system according to a preset association method, and running the assembled system within the runtime device.

[0179] The loaded module is a module (element or component) developed by constructing an abstract interaction model of things using fixed interfaces in a fixed interface set. The fixed interface set includes at least fixed interfaces defined by treating things as resources and processes.

[0180] Optionally, the loaded modules can be loaded, unloaded, updated, or configured by the running device at runtime to create, cancel, and modify system modules at runtime.

[0181] Furthermore, the association information between modules can be loaded, unloaded, or updated by the running device during runtime, so as to establish, cancel, and change the association relationship between different modules during runtime.

[0182] Optionally, when loading or updating modules, the operating device can parameterize the corresponding modules to adjust their internal functional logic to adapt to the needs of associated modules. Similarly, when loading or updating association methods, the operating device can parameterize the corresponding association methods to adjust and adapt the association relationships between modules. Specifically, this can be done, but is not limited to, parameterizing modules or association methods based on configuration files or other equivalent methods.

[0183] Association methods can be implemented by parameterizable association components. By generating instances of association components and loading, updating, and parameterizing these instances, the association methods can be loaded, updated, and parameterized.

[0184] For parameterized configuration of components / associations, iPojo's component configuration method can be used to generate instances based on its parameter injection method. This includes packaging with XML configuration files or configuring config files using Felix ConfigAdmin. The latter method allows for dynamic configuration of multiple instances of the same component in the same runtime environment.

[0185] Corresponding to the component construction method described above, this application also discloses a component construction apparatus, the composition of which is as follows: Figure 10 As shown, it includes:

[0186] The first acquisition module 11 is used to acquire the target components required to construct the target component; wherein, the component is assembled from a set of components, and each component is developed by an abstract interaction model that constructs things through an interface in a predefined fixed interface set;

[0187] The first assembly module 12 is used to assemble the various target components and expose parameters and services during assembly;

[0188] Meta-information configuration module 13 is used to configure component meta-information for the assembly results;

[0189] Packaging module 14 is used to package the assembly results with completed meta-information configuration into components to obtain the target component.

[0190] In one embodiment, the first acquisition module 11 is specifically used for:

[0191] Determine if the target component required to build the target component exists in the component library;

[0192] If present, select the desired target component from the component library;

[0193] If it does not exist, develop the required target component;

[0194] Specifically, the target components required for development are realized by developing corresponding modules based on the fixed interfaces in the fixed interface set. When developing a module, the interfaces and interface methods defined in the fixed interface set are used to refer to the internal references to the external modules and the operations on the referenced targets. The services provided by the module to the external modules and the operations contained therein are implemented as the corresponding interfaces and interface methods in the fixed interface set.

[0195] In one embodiment, the first assembly module 12 is specifically used for:

[0196] Different target components are associated with each other based on a preset association method, so that the target components can be assembled into a component through the interrelation between the target components;

[0197] The association method can be any one of the following: specifying the association between different target components based on a configuration file, specifying the association between different target components by running a specific program, specifying the association between target components by matching the module features of different target components, or specifying the association between different target components based on changes in preset environment variables during component development.

[0198] In one embodiment, the first assembly module 12 performs parameterized configuration of the component modules of the corresponding target components when associating different target components with each other, so as to adjust the internal functional logic of the module to adapt to the needs of the associated module.

[0199] In one implementation, the predefined set of fixed interfaces includes resource class interfaces, process class interfaces defined by treating things as resources and processes, and also includes extended interfaces.

[0200] The component building apparatus disclosed in this application is described simply because it corresponds to the component building method disclosed in the corresponding method embodiments above. For any similarities, please refer to the description of the corresponding method embodiments above, which will not be detailed here.

[0201] Corresponding to the system construction method described above, this application also discloses a system construction apparatus, the composition of which is as follows: Figure 11 As shown, it includes:

[0202] The second acquisition module 21 is used to acquire the various target components required to build the target software system; wherein each component is developed by an abstract interaction model that constructs things through fixed interfaces in a fixed interface set;

[0203] Instantiation module 22 is used to instantiate each target component and obtain component instances of each target component;

[0204] The second assembly module 23 is used to assemble the various component instances to obtain the target software system.

[0205] In one embodiment, the second acquisition module 21 is specifically used for:

[0206] Determine whether the target components required to build the target software system exist in the component library;

[0207] If it exists, select the desired target component from the component library;

[0208] If it does not exist, the required target component can be developed using the component construction method provided in this application.

[0209] In one implementation, the component is developed by constructing an abstract interaction model of things using interfaces from a predefined set of fixed interfaces;

[0210] References from a component to the outside of the component and operations on the referenced target are referred to using the interfaces and interface methods defined in the fixed interface set;

[0211] The services provided by the component to the outside world and the operations contained therein are implemented as the corresponding interfaces and interface methods of the fixed interface set.

[0212] In one implementation, the instantiation module 22 is specifically used for:

[0213] The container loads each target component and the instantiation configuration information written for each target component, and creates component instances of each target component based on the loaded target components and instantiation configuration information.

[0214] In one embodiment, the second assembly module 23 is specifically used for:

[0215] The container loads the association information specified for different target components based on a preset association method. Based on the loaded association information, the component instances of each target component are associated with each other, and the associated component instances constitute the target software system.

[0216] The association method can be any one of the following: specifying the association between different target components based on a configuration file, specifying the association between different target components by running a specific program, specifying the association between target components by matching the module features of different target components, or specifying the association between different target components based on changes in preset environment variables during software system development.

[0217] In one embodiment, the system construction apparatus may further include an operation and modification module for:

[0218] The target software system is run using a container;

[0219] In response to load, unload, or update instructions for components and / or associations between components of the target software system, during the operation of the target software system, the instructions are dynamically loaded, unloaded, or updated for at least one component and / or associations between components indicated by the target software system.

[0220] The system construction apparatus disclosed in this application is relatively simple to describe because it corresponds to the system construction method disclosed in the corresponding method embodiments above. For any similarities, please refer to the description of the corresponding method embodiments above, which will not be detailed here.

[0221] This application also discloses an electronic device, which may be, but is not limited to, a device in a variety of general-purpose or special-purpose computing device environments or configurations, such as: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, etc. The electronic device's structure includes at least:

[0222] Memory is used to store computer instruction sets;

[0223] Computer instruction sets can be implemented in the form of computer programs.

[0224] A processor is used to implement the component construction method or system construction method disclosed in any of the above method embodiments by executing a computer instruction set.

[0225] The processor can be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices.

[0226] In addition to these components, electronic devices may also include communication interfaces, communication buses, and other parts. Memory, processor, and communication interface communicate with each other through the communication bus.

[0227] Communication interfaces are used for communication between electronic devices and other devices. Communication buses can be Peripheral Component Interconnect (PCI) buses or Extended Industry Standard Architecture (EISA) buses, and can be categorized into address buses, data buses, control buses, etc.

[0228] In summary, the component construction method, system construction method, and related devices and electronic devices disclosed in this application have at least the following advantages / optimizations compared to existing single-application, microservice, and traditional OSGi solutions:

[0229] 1) In terms of system architecture, compared to a single application, this application divides a large system into multiple modules with no coupling (or weak coupling) between modules. Each module can be developed independently and configured and assembled before running.

[0230] 2) Compared to microservices, the modules in this application are less coupled, and the connection between modules is through fixed interfaces, which are independent of the specific interface implementation. Microservices, on the other hand, have upstream and downstream dependencies based on service logic. Downstream services must fully understand the business interfaces of upstream services, which means that downstream services depend on upstream services. These dependencies will be reflected in the development, update, operation and maintenance processes.

[0231] 3) Compared to microservices, the components in this application have a finer granularity. Microservices use processes as the basic unit, and the resource cost of running services is relatively high, which determines that it is not suitable to break down services into smaller fragments. For this application, the granularity is code blocks. Any part of the code, if it has its own independence (even if it is only one class) and its association with other code blocks is variable, can be cut into components;

[0232] 4) For system development, compared to a single application, the lifecycles and iterations of each component are relatively independent, allowing for independent development, testing, deployment, and updates, and enabling rapid development and iteration;

[0233] 5) Compared to microservices, because the components in this application are more granular, adjustments to the affected system parts are more precise, and the development and iteration costs and cycles are also shorter. The operating environment of this application is simpler (only a Felix container needs to be run in scenarios using Felix OSGi), and module startup and loading are more convenient and faster (only dragging and dropping components to a specified storage area is required in scenarios using Felix OSGi), making testing and deployment easier. This application offers lower software development support costs and better efficiency.

[0234] 6) Regarding system maintenance, this application offers greater advantages in system elasticity compared to single applications and microservices. For a componentized system, the assembly and unassembly processes are dynamic. The types and number of components running within a container are dynamically variable. Components requiring expansion can be deployed to a container as needed and coexist with other component services, unlike microservices like Docker that exclusively occupy container resources. Furthermore, resources are shared within containers; unused component functions consume little or no CPU and memory, while active components utilize more computing resources. Therefore, frequent scheduling of components and containers is unnecessary, reducing operational costs.

[0235] 7) Compared to microservices, this application is a monolithic application that runs independently in a single process. It does not require a complex support framework, and its development and operation do not require high levels of software and hardware resources or personnel management skills from the user.

[0236] 8) Compared to microservices, this application is a monolithic application, which does not involve inter-process communication or cross-network communication, nor does it have the problem of unavailable dependent services. It consumes fewer resources, has low requirements for system monitoring and management, and does not bring additional overhead. At the same time, monolithic applications are also easier to implement transactional and consistent data processing;

[0237] 9) Compared to microservices, which require starting and stopping the process to update local modules, the component loading and updating in this application is an operation of an in-process daemon thread, which is faster than microservices and can realize system updates without the business being aware of it.

[0238] 10) Regarding module reuse, in microservices and traditional OSGi development, dependencies between modules are established through interfaces or inter-process calls. These interfaces are customized by each module based on its function or business logic, resulting in dual coupling during development and runtime, impacting the module's practical value. The modularity of this application stems from component isolation based on fixed interfaces. This standardizes and regulates module boundaries and interaction patterns, enabling the development of numerous independent components. These components can be assembled at different levels to build more complex and flexible systems. Such components offer higher reusability and are more suitable for building component repositories, accumulating software assets, and rapidly deploying systems.

[0239] It should be noted that although this application is based on the Spring and OSGi (Apache Felix) technology framework, the use of fixed interfaces for component / system development is not limited to the above technologies. Any software development system (including but not limited to the technologies mentioned in technologies A, B, C, and D) can achieve more independent and reusable module optimization effects by adopting similar methods for module division.

[0240] In addition, it should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0241] For ease of description, the above systems or devices are described separately as various modules or units based on their functions. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware components.

[0242] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0243] Finally, it should be noted that in this document, relational terms such as first, second, third, and fourth are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0244] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A component construction method, characterized in that, include: Obtain all target components required to construct the target component; wherein, a fixed interface set is predefined, which is a pre-agreed and standardized global abstract interaction interface system used to unify and standardize module boundaries and module interaction modes; the component is assembled from a set of components, each component is developed by constructing an abstract interaction model of things using the interfaces in the fixed interface set, and the module uses only the corresponding interfaces and interface methods in the fixed interface set to reference external content and provide services to the outside world; the module includes elements or components. Assemble the target components and expose parameters and services during assembly; Configure component element information for the assembly results; The assembly results with completed metadata configuration are packaged into components to obtain the target component.

2. The method according to claim 1, characterized in that, The process of obtaining multiple target elements required to construct the target component includes: Determine if the target component required to build the target component exists in the component library; If present, select the desired target component from the component library; If it does not exist, develop the required target component; Specifically, the target components required for development are realized by developing corresponding modules based on the fixed interfaces in the fixed interface set. When developing a module, the interfaces and interface methods defined in the fixed interface set are used to refer to the internal references to the external modules and the operations on the referenced targets. The services provided by the module to the external modules and the operations contained therein are implemented as the corresponding interfaces and interface methods in the fixed interface set.

3. The method according to claim 1, characterized in that, Assembling the various target components includes: Different target components are associated with each other based on a preset association method, so that the target components can be assembled into a component through the interrelation between the target components; The association method can be any one of the following: specifying the association between different target components based on a configuration file, specifying the association between different target components by running a specific program, specifying the association between target components by matching the module features of different target components, or specifying the association between different target components based on changes in preset environment variables during component construction.

4. The method according to claim 3, characterized in that, When associating different target components with each other, the component modules of the corresponding target components are parameterized to adjust the internal functional logic of the modules to adapt to the needs of the associated modules.

5. The method according to claim 1, characterized in that, The predefined set of fixed interfaces includes resource class interfaces and process class interfaces defined by treating things as resources and processes, as well as extended interfaces.

6. A system construction method, characterized in that, include: Obtain all target components required to build the target software system; wherein, a fixed interface set is predefined, which is a pre-agreed and standardized global abstract interaction interface system used to unify and standardize module boundaries and module interaction modes; each component is developed by constructing an abstract interaction model of things using fixed interfaces in the fixed interface set, and the module uses only the corresponding interfaces and interface methods in the fixed interface set to reference external content and provide services to the outside world; the module includes elements or components. Instantiate each target component to obtain a component instance of each target component; The target software system is obtained by assembling the various component instances.

7. The method according to claim 6, characterized in that, The acquisition of the target components required to build the target software system includes: Determine whether the target components required to build the target software system exist in the component library; If it exists, select the desired target component from the component library; If not, the required target component shall be developed by the method described in any one of claims 1-5.

8. The method according to claim 7, characterized in that: Components are developed by constructing an abstract interaction model of things using interfaces from a predefined set of fixed interfaces; References from a component to the outside of the component and operations on the referenced target are referred to using the interfaces and interface methods defined in the fixed interface set; The services provided by the component to the outside world and the operations contained therein are implemented as the corresponding interfaces and interface methods of the fixed interface set.

9. The method according to claim 6, characterized in that, The instantiation of each target component to obtain a component instance of each target component includes: The container loads each target component and the instantiation configuration information written for each target component, and creates component instances of each target component based on the loaded target components and instantiation configuration information.

10. The method according to claim 6, characterized in that, The assembly of the various component instances to obtain the target software system includes: The container loads the association information specified for different target components based on a preset association method. Based on the loaded association information, the component instances of each target component are associated with each other, and the associated component instances constitute the target software system. The association method can be any one of the following: specifying the association between different target components based on a configuration file, specifying the association between different target components by running a specific program, specifying the association between target components by matching the module features of different target components, or specifying the association between different target components based on changes in preset environment variables during software system construction.

11. The method according to claim 10, characterized in that, Also includes: The target software system is run using a container; In response to load, unload, or update instructions for components and / or associations between components of the target software system, during the operation of the target software system, the instructions are dynamically loaded, unloaded, or updated for at least one component and / or associations between components indicated by the target software system.

12. An operating device, characterized in that, Used to load the required modules, associate and assemble the loaded modules into a runnable system according to a preset association method, and run the resulting system in the operating device; Specifically, a fixed interface set is predefined, which is a pre-agreed and standardized global abstract interaction interface system used to unify and standardize module boundaries and module interaction modes. The loaded modules are developed by constructing abstract interaction models of things using fixed interfaces in the fixed interface set. When a module references external content or provides services to the outside world, it only uses the corresponding interfaces and interface methods in the fixed interface set. The modules include elements or components.

13. The operating device according to claim 12, characterized in that, The operating device can parameterize the corresponding modules to adjust the internal functional logic of the modules to adapt to the needs of the associated modules.

14. The operating device according to claim 13, characterized in that, The module is a component or assembly; the module can be loaded, unloaded, updated or configured by the operating device during runtime, so as to establish, cancel and change the system's modules during runtime; The information of the association method can be loaded, unloaded or updated by the running device during runtime, so as to establish, cancel and change the association relationship between different modules during runtime.

15. The operating device according to claim 14, characterized in that, When loading or updating the association method, the operating device performs parameterized configuration of the corresponding association method in order to adjust and adapt the association relationship between modules.

16. The operating device according to claim 15, characterized in that, The association method is implemented by a parameterizable association component; The association method is loaded, updated, and parameterized by generating instances of the associated components and by loading, updating, and parameterizing the instances of the associated components.

17. The operating device according to claim 12, characterized in that, The operating device is a container device.

18. A component assembly apparatus, characterized in that, include: The first acquisition module is used to acquire the target components required to construct the target component. A fixed interface set is predefined, which is a pre-agreed and standardized global abstract interaction interface system used to unify and standardize module boundaries and module interaction modes. A component is assembled from a set of components, each of which is developed using an abstract interaction model that constructs things through fixed interfaces in the fixed interface set. When a module references external content or provides services, it only uses the corresponding interfaces and interface methods in the fixed interface set. The module includes elements or components. The first assembly module is used to assemble the various target components and expose parameters and services during assembly; The meta-information configuration module is used to configure component meta-information for the assembly results. The packaging module is used to package the assembly results with completed metadata configuration into components to obtain the target component.

19. A system construction apparatus, characterized in that, include: The second acquisition module is used to acquire the target components required to build the target software system. A fixed interface set is predefined, which is a pre-agreed and standardized global abstract interaction interface system used to unify and standardize module boundaries and module interaction modes. Each component is developed by constructing an abstract interaction model of things using fixed interfaces in the fixed interface set. When a module references external content or provides services, it only uses the corresponding interfaces and interface methods in the fixed interface set. The module includes elements or components. The instantiation module is used to instantiate each target component and obtain component instances of each target component; The second assembly module is used to assemble the various component instances to obtain the target software system.

20. An electronic device, characterized in that, include: Memory, used to store at least the computer instruction set; A processor is configured to invoke and execute the computer instruction set in the memory, thereby implementing the component construction method as described in any one of claims 1-5, or the system construction method as described in any one of claims 6-11.

Images