WO2020215425A1 - Software operating method and system, computing device and storage medium - Google Patents

Abstract

A software operating method. Operated software comprises a plurality of mutually independent functional modules, wherein the functional modules are suitable for processing input data so as to obtain output data; and the functional modules have input buffer regions for buffering the input data of the functional modules. The method is suitable to be implemented in an operating system, and the operating system resides in a computing device. The method comprises: acquiring a data mapping table of software, wherein the data mapping table is suitable for recording directions of transmission of data between a plurality of functional modules (S210); acquiring output data of one functional module (S220); determining, on the basis of the data mapping table, a subsequent functional module that takes the output data as input data, and storing the output data in an input buffer region of the subsequent functional module (S230); and when the input buffer region comprises all input data required by the subsequent functional module, calling the subsequent functional module to process data (S240).

Description

Software operating method, system, computing device and storage medium Technical field

The present invention relates to the technical field of software engineering, in particular to a software operation method, system, computing device and storage medium.

Background technique

A typical programming paradigm or method in software programming is the programming method based on control flow. Control flow is the order in which the logic of the control program is executed. Its basic feature is to decompose the target system to be developed into functions or steps to form a flow, and then complete the steps in sequence. The processing or operating logic of a general-purpose computer is in this way, using an execution unit CPU to run a program containing a set of instructions. Therefore, most programming languages such as assembly language, C/C++, JAVA, etc. are control flow-oriented. The problem with this programming paradigm is that with the increase in software scale and complexity, the calls between software functions increase, which makes the dependency or coupling relationship between software functional modules become huge and complicated. The difficulty of system development and maintenance has increased exponentially. Although the emergence of object-oriented, event-driven and various design patterns has alleviated this problem to a certain extent, how to design a software system that is easy to develop, maintain and expand is still an urgent problem to be solved.

The data flow-oriented programming paradigm is to encapsulate the necessary groupable functions in the system into independent functional units, and then realize the overall functions of the system by controlling the data flow of the functional units. Since the hardware circuit is composed of the signal connection between the chip and the chip, programming languages oriented to the field of hardware design or simulation, such as labview, VHDL, Verilog, etc., all use the programming paradigm based on data flow.

Therefore, there is a need for a software operation method that can introduce data flow-oriented programming paradigms into procedural programming languages to achieve decoupling between functional modules.

Summary of the invention

To this end, the present invention provides a software running method, system, computing device and storage medium, in an effort to solve or at least alleviate the above problems.

According to one aspect of the present invention, a software running method is provided, the software includes a plurality of mutually independent functional modules, the functional modules are adapted to process input data to obtain output data, and the functional modules have functions for caching The input buffer area of its input data, the method is adapted to be executed in an operating system, the operating system resides in a computing device, and the method includes: acquiring a data mapping table of the software, the data mapping table being suitable To record the transfer direction of data between multiple functional modules; obtain the output data of a functional module; based on the data mapping table, determine the subsequent functional module with the output data as the input data, and store the output data in all In the input buffer area of the subsequent functional module; and when the input buffer includes all input data required by the subsequent functional module, the subsequent functional module is called for data processing.

Optionally, in the software running method according to the present invention, the data mapping table is configured in the main module of the software or in other files, and the other files are independent of the software; the acquiring of the software The steps of the data mapping table include: obtaining and loading the data mapping table from the main module or other files.

Optionally, in the software running method according to the present invention, the functional module further has an output buffer area for buffering its output data; the step of obtaining the output data of a functional module includes: from the output buffer area of the functional module Read the output data in.

Optionally, in the software operating method according to the present invention, the functional module further includes a data transmission interface for sending output data; the step of obtaining the output data of a functional module includes: receiving the data transmission interface of the functional module The output data sent.

Optionally, in the software running method according to the present invention, the function module also has a corresponding call entry and an input state buffer area for buffering the input data state. After the input data of the function module is stored in its input buffer area, Setting the state of the corresponding input data in the input state buffer area to be available; the step of invoking the subsequent function module for data processing includes: according to the input state buffer area, checking what is required by the subsequent function module The state of the input data; when all the states of the required input data are available, call the subsequent function module for data processing.

Optionally, in the software running method according to the present invention, the function module further has an output state buffer area for buffering the output data state; after the step of calling the subsequent function module for data processing, it further includes : Store the output data of the subsequent functional module in its output buffer area; and set the status of the output data in its output state buffer area to be available.

Optionally, in the software running method according to the present invention, it further includes: acquiring and recording the address of at least one of the input buffer area, input state buffer area, output buffer area, and output state buffer area of each functional module, wherein, The addresses of the input buffer area, input state buffer area, output buffer area, and output state buffer area are provided by corresponding functional modules.

Optionally, in the software operation method according to the present invention, the functional module may be multiplexed in a manner of creating multiple instances, each instance corresponding to an input buffer area and/or an output buffer area respectively.

Optionally, in the software running method according to the present invention, the input data and output data of each functional module are identified by a combination of data name and data type.

Optionally, in the software running method according to the present invention, the first function module called in the software is a function module that does not have input data.

According to one aspect of the present invention, a software running system is provided, which resides in a computing device and is suitable for running software. The software includes a plurality of mutually independent functional modules, and the functional modules are adapted to process input data to Obtain output data, the software running system includes a scheduling module, the scheduling module includes: an input buffer register interface, suitable for recording the input buffer address of each functional module, the input buffer is used to buffer the input data of the functional module Module registration interface, suitable for recording the call entry address of each functional module and the input data set as its trigger condition; data mapping loading interface, suitable for obtaining the data mapping table of the software, and setting functions according to the data mapping table The mapping relationship between the output data of the module and the input data of the subsequent functional module; the data distributor is adapted to obtain the output data of the functional module, and send the obtained output data to the corresponding subsequent functional module according to the data mapping table When the input buffer area includes all the input data required by the subsequent function module, the call entry address of the subsequent function module is sent to the scheduler; the scheduler is suitable for receiving the call entry address of the function module And call the function module for data processing.

Optionally, in the software operating system according to the present invention, the data mapping table is configured in the main module of the software or configured in other files, and the other files are independent of the software; the data mapping table The loading interface is suitable for: obtaining and loading the data mapping table from the main module or other files.

Optionally, in the software operating system according to the present invention, the scheduling module further includes: an output buffer area registration interface, adapted to record the output buffer area addresses of each functional module, and the output buffer area is used for buffering function modules. Output data; the data distributor is adapted to: read output data from the output buffer area of the functional module.

Optionally, in the software operating system according to the present invention, the function module includes a data transmission interface for sending output data; the scheduling module further includes: a data receiving interface, a data transmission interface suitable for receiving the function module Sending the output data, and sending the received output data to the data distributor.

Optionally, in the software operating system according to the present invention, the scheduling module further includes: an input state buffer area registration interface, adapted to record the input state buffer area address of each functional module, and the input state buffer area is used for buffering The state of the input data of the functional module; the data distributor is also suitable for: including all the input data required by the subsequent functional module in the input buffer area and all of these input data are available, the call entry address of the subsequent functional module Send to the scheduler so that the scheduler can call the subsequent function module.

Optionally, in the software operating system according to the present invention, the scheduling module further includes: an output state buffer area registration interface, adapted to record the address of the output state buffer area of each functional module, and the output state buffer area is used for buffering The state of the output data of the function module; the scheduler is suitable for: after calling the function module for data processing, store the output data of the function module in its output buffer area, and store the output data in its output state buffer area The status is set to available.

Optionally, in the software operating system according to the present invention, the scheduling module further includes: a data mapping release interface adapted to map the mapping relationship between the output data of the functional module to the input data of the subsequent functional module from the data mapping Delete from the table.

Optionally, in the software operating system according to the present invention, the scheduling module further includes: a system control interface adapted to receive control data to control the operation of the software.

Optionally, in the software operating system according to the present invention, the system control interface includes: a startup interface, adapted to receive startup data to start the operation of the software, or send the call entry address of the designated function module to the dispatcher To start the operation of the software.

According to one aspect of the present invention, there is provided a computing device, including: at least one processor and a memory storing program instructions; when the program instructions are read and executed by the processor, the computing device is caused to execute the above The described software operation method.

According to one aspect of the present invention, there is provided a readable storage medium storing program instructions, when the program instructions are read and executed by a computing device, the computing device is caused to execute the software running method described above.

According to the technical solution of the present invention, by dividing the software into multiple independent modules, the decoupling of the functional modules is realized, and the necessary technical means are provided for solving the large division of labor in the software development process. This solution not only makes the functional modules available for one-time development everywhere and improves development efficiency, but also makes the developed software easy to modify and maintain, and has a wide range of application values.

Description of the drawings

In order to achieve the above and related purposes, this article describes certain illustrative aspects in conjunction with the following description and drawings. These aspects indicate various ways in which the principles disclosed herein can be practiced, and all aspects and their equivalents are intended to be Into the scope of the claimed subject matter. By reading the following detailed description in conjunction with the accompanying drawings, the above and other objectives, features and advantages of the present disclosure will become more apparent. Throughout this disclosure, the same reference numerals generally refer to the same parts or elements.

FIG. 1 shows a schematic diagram of the structure of a computing device 100 according to an embodiment of the present invention;

FIG. 2 shows a flowchart of a software running method 200 according to an embodiment of the present invention;

FIG. 3 shows a schematic diagram of a software running system 300 according to an embodiment of the present invention;

4 to 6 respectively show a structure diagram of a scheduling module 400 according to an embodiment of the present invention, a flowchart of a corresponding software operation method, and a data flow diagram between corresponding functional modules;

7-9 respectively show a structure diagram of a scheduling module 700 according to another embodiment of the present invention, a flowchart of a corresponding software operation method, and a data flow diagram between corresponding functional module instances.

Detailed ways

Hereinafter, exemplary embodiments of the present disclosure will be described in more detail with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

In software engineering, in order to solve the problem of coupling between the functional modules of the programming language based on control flow, which makes the development and dimension of the system more difficult, this solution provides a data flow-based software operation method that can realize each functional module Decoupling.

FIG. 1 is a block diagram of an example computing device 100. In the basic configuration 102, the computing device 100 typically includes a system memory 106 and one or more processors 104. The memory bus 108 may be used for communication between the processor 104 and the system memory 106.

Depending on the desired configuration, the processor 104 may be any type of processor, including but not limited to: a microprocessor (μP), a microcontroller (μC), a digital information processor (DSP), or any combination thereof. The processor 104 may include one or more levels of cache, such as the first level cache 110 and the second level cache 112, the processor core 114, and the registers 116. The exemplary processor core 114 may include an arithmetic logic unit (ALU), a floating point number unit (FPU), a digital signal processing core (DSP core), or any combination thereof. The example memory controller 118 may be used with the processor 104, or in some implementations, the memory controller 118 may be an internal part of the processor 104.

Depending on the desired configuration, the system memory 106 may be any type of memory, including but not limited to: volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.), or any combination thereof. The system memory 106 may include an operating system 120, one or more applications 122, and program data 124. In some embodiments, the application 122 may be arranged to operate with the program data 124 on the operating system. In some embodiments, the application 122 includes a software operating system, and the software operating system includes instructions for executing the software operating method 200 of the present invention, so that the computing device 100 can execute the software operating method 200. The specific implementation steps of the software operation method 200 will be detailed below.

The computing device 100 may also include an interface bus 140 that facilitates communication from various interface devices (eg, output device 142, peripheral interface 144, and communication device 146) to the basic configuration 102 via the bus/interface controller 130. The example output device 142 includes a graphics processing unit 148 and an audio processing unit 150. They can be configured to facilitate communication with various external devices such as displays or speakers via one or more A/V ports 152. The example peripheral interface 144 may include a serial interface controller 154 and a parallel interface controller 156, which may be configured to facilitate communication via one or more I/O ports 158 and input devices such as keyboards, mice, pens, etc. , Voice input devices, image input devices) or other peripherals (such as printers, scanners, etc.) to communicate. The example communication device 146 may include a network controller 160, which may be arranged to facilitate communication with one or more other computing devices 162 via a network communication link via one or more communication ports 164.

A network communication link may be an example of a communication medium. The communication medium may generally be embodied as computer readable instructions, data structures, and program modules in a modulated data signal such as a carrier wave or other transmission mechanism, and may include any information delivery medium. A "modulated data signal" may be a signal, one or more of its data sets or its changes may be carried out in the signal in a manner of encoding information. As a non-limiting example, communication media may include wired media such as a wired network or a dedicated line network, and various wireless media such as sound, radio frequency (RF), microwave, infrared (IR), or other wireless media. The term computer readable media used herein may include both storage media and communication media. In some embodiments, a computer-readable medium stores one or more programs, and the one or more programs include instructions for executing certain methods.

The computing device 100 can be implemented as a part of small-sized portable (or mobile) electronic devices, such as cellular phones, digital cameras, personal digital assistants (PDAs), personal media player devices, wireless web browsing devices, personal heads Wearable devices, application-specific devices, or hybrid devices that can include any of the above functions. Of course, the computing device 100 can also be implemented as a personal computer including a desktop computer and a notebook computer configuration, or a server with the above configuration. The embodiments of the present invention do not limit this.

In the embodiment of the present invention, a software running system is deployed in the computing device, so that the computing device can execute the software running method 200 of the present invention. Among them, the software operating system is a system used to run software codes. For example, it can be implemented as a software integrated development environment (IDE), which can integrate functions such as code writing, analysis, compilation, and debugging. The existing integrated development environments include visual stodio, eclipse, Delphi, etc., and the software operating system of the present invention can be a completely independent research and development environment, or it can be improved on the existing development environment. The software code can be written based on any development language such as assembly language, C/C++ language, JAVA language, python language.

In order to avoid the difficulty of development and maintenance caused by the mutual coupling between the functional modules of the software, the software to be run (hereinafter referred to as "software") of the present invention is written in the data flow paradigm, and the software operating system of the present invention can Software written in the data flow paradigm is compiled and run.

FIG. 2 shows a schematic flowchart of a software running method 200 according to an embodiment of the present invention. The method is suitable for execution in a software operating system, which resides in a computing device.

In the embodiment of the present invention, the software includes a plurality of mutually independent functional modules. There is no coupling relationship between the functional modules, and independent data processing can be performed on a group of data, that is, each functional module can receive its own input data and process the received input data to obtain its own output data. In order to mark the association between data (input data and output data) and functional modules and to identify different data types, a combination of data name and data type can be used to identify data. The data types include string, integer, floating point, array, object, no type, etc. For example, it can be identified by string or integer. In the embodiment of the present invention, the combination of data name and data type can be called named data.

The function module may include a corresponding call entry, an input buffer area for buffering input data, and an input state buffer area for buffering the state of input data. In an implementation of the present invention, the input buffer area address and the input state buffer area address of the functional module are provided by the corresponding functional module or established when the software is running.

It should be noted that the functional modules in the present invention can be multiplexed by creating multiple instances. Multiple instances corresponding to one functional module have the same processing function. The difference lies in the data being processed. Each instance corresponds to an input buffer area and/or output buffer area, and a corresponding input state buffer area and/or output state buffer area. As shown in Fig. 2, the method 200 starts at step S210.

In step S210, a data mapping table of the software is obtained, and the data mapping table is suitable for recording the transfer direction of data among multiple functional modules.

According to an embodiment, the data mapping table can be configured in a functional module of the software, for example, in the main module of the software, that is, the data mapping table is directly defined in the main function. Accordingly, when the software is running, The data mapping table is dynamically obtained and loaded in the main module.

The data mapping table can also be configured in other files, which are stored independently of the main body of the software. Correspondingly, when the software is running, the data mapping table is dynamically obtained and loaded from the other file.

The data mapping table records the direction of data transfer between multiple functional modules. Specifically, the data mapping table includes multiple pieces of output data to input data mapping relationship, for example, the mapping relationship link ("Module_A_Output", "Module_B_X") indicates that the output data Module_A_Output of function module A is mapped to the input of function module B The data Module_B_X, that is, when the function module A is called and the output data Module_A_Output is generated, the output data Module_A_Output will be used as the input data Module_B_X of the function module B to participate in the data processing of the function module B.

The multiple mapping relationships in the data mapping table show the direction of data transfer between multiple functional modules. Correspondingly, each functional module of the software can be called in sequence according to the order indicated by the data mapping table to perform corresponding data processing Features. Except for the start function module of the software (that is, the first function module called in the software) and the termination function module (the last function module called in the software), the output data generated by other function modules need to be transferred according to the data mapping table To at least one subsequent functional module, so that the subsequent functional module can perform data processing.

Subsequently, in step S220, the output data of a functional module is obtained.

According to the specific configuration of the functional module, the output data of the functional module can be obtained in different ways.

According to an embodiment, the functional module has an output buffer area for buffering its output data. Accordingly, in step S220, the output data can be read from the output buffer area of the functional module. The address of the output buffer area of the functional module can be provided by the functional module, for example, that is, the output buffer area of the functional module is defined in the functional module.

According to another embodiment, the function module includes a data sending interface for sending output data (the data sending interface may be, for example, a send function). Accordingly, in step S220, the function module may be received through a corresponding data receiving interface The output data sent by the data sending interface.

Subsequently, in step S230, based on the data mapping table, the subsequent functional module whose output data is the input data is determined, and the output data is stored in the input buffer area of the subsequent functional module.

According to an embodiment, the functional module further has an input state buffer area for buffering the input data state. When the input data of the functional module is stored in its input buffer area, the corresponding input data in the input state buffer area is set to be available. For example, the function module B has a corresponding input buffer area InputBuffer_B and an input status buffer area InputStatusBuffer_B, and the input data of the function module B includes Module_B_X and Module_B_Y. The input buffer InputBuffer_B stores the values of the input data Module_B_X and Module_B_Y, and the input status buffer InputStatusBuffer_B stores the status flags of the input data Module_B_X and Module_B_Y. The value of the status flag includes, for example, 0 and 1. When the status flag is 0, it means The input data is available (that is, the input data has been obtained); when the status flag is 1, it means that the input data is not available (that is, the input data has not been obtained). In the initial state, the status flags in the input status buffer InputStatusBuffer_B are all 1, that is, the input data has not been obtained yet and is in an unavailable state. When a certain input data is stored in the input buffer area, for example, when the input data Module_B_X is stored in the input buffer area InputBuffer_B, the state corresponding to the input data Module_B_X in the input status buffer InputStatusBuffer_B is set to available, that is, the input data Module_B_X The value of the corresponding status identifier Module_B_X_Status is set to 0.

Subsequently, in step S240, when all input data required by the subsequent functional module is included in the input buffer area, the subsequent functional module is called for data processing.

According to an embodiment of the present invention, the status of the input data required by the subsequent function module can be checked. When the status of the input data is all available, it is determined that the subsequent function module meets the calling conditions, and the subsequent function module is called for data deal with. According to an embodiment, the input buffer area and the input state buffer area of the subsequent function module can be cleared after the subsequent function module is called (that is, the state identifier stored in the input state buffer area is reset to the initial value).

According to an embodiment, the functional module also has an output state buffer area for buffering the output data state. The address of the output state buffer area can be provided by the functional module, for example, that is, the output state buffer area is defined in the functional module. After calling the subsequent functional module for data processing, the output data of the subsequent functional module is stored in its output buffer area, and the state of the output data in its output state buffer area is set to available.

It should be noted that steps S220 to S240 take a functional module as an example, and describe the process of transferring the output data generated by the functional module to the subsequent functional module and calling the subsequent functional module for data processing. Those skilled in the art can understand that during the running process of a software, for multiple functional modules, steps S220 to S240 need to be executed repeatedly until the last functional module is called to obtain the output result of the entire software.

In addition, it should be noted that the software running system of the present invention can run in a single-thread mode or a multi-thread mode. In the single-thread mode, the system has only one functional module running at any time. When there is a running function module in the scheduling module, it waits for the running of the function module to end; when there is no running module in the scheduling module, it ends the running and returns. By adding multi-threaded management functions, concurrent execution of functional modules can be implemented to improve operating efficiency. Or increase queue management to reduce stack usage during system calls. This solution will not be described again.

The method 200 illustrates the method and process of the software operating system to run the software. The following will introduce the composition structure of the software operating system in detail.

FIG. 3 shows a schematic diagram of a software running system 300 according to an embodiment of the present invention. The software operating system 300 resides in a computing device (such as the aforementioned computing device 100), and is suitable for executing the software operating method 200 of the present invention. As shown in FIG. 3, the software operating system 300 includes a scheduling module. In the embodiment of the present invention, the scheduling module is a key module in the software operating system 300, which is used for data flow according to the data mapping table of the software. Run the software. Those skilled in the art can understand that in addition to the scheduling module, the software running system 300 also includes other modules, such as a code compiling module, a code debugging module, etc., but it is not limited thereto.

As shown in FIG. 3, the scheduling module includes an input buffer registration interface 302, a module registration interface 304, a data mapping setting interface 306, a data distributor 308, and a scheduler 310.

The input buffer register interface 302 is adapted to record the address of the input buffer of each functional module, and the input buffer is used to buffer the input data of the functional module.

The module registration interface 304 is suitable for recording the call entry address of each function module and the input data set as its trigger condition.

The data mapping loading interface 306 is adapted to obtain the data mapping table of the software, and set the mapping relationship between the output data of the functional module and the input data of the subsequent functional module according to the data mapping table.

According to an embodiment, the data mapping table can be configured in a functional module of the software, for example, in the main module of the software, that is, the data mapping table is directly defined in the main function; it can also be configured in other files. The file is stored independently of the main body of the software. Correspondingly, the data mapping loading interface 306 is adapted to dynamically obtain and load the data mapping table from the main module or other files.

The data distributor 308 is adapted to obtain the output data of the functional module, and send the obtained output data to the input buffer area of the corresponding subsequent functional module according to the data mapping table, and when the input buffer area is included in the subsequent functional module's required When all input data of the following function module is input, the call entry address of the subsequent function module is sent to the scheduler.

There are many ways to obtain the output data of the function module. According to an embodiment, the scheduling module further includes an output buffer register interface 312, adapted to record the output buffer address of each functional module, and the output buffer is used to buffer the output data of the functional module. Correspondingly, the data distributor 308 is adapted to read output data from the output buffer area of the functional module.

According to another embodiment, the function module includes a data sending interface for sending output data, and the scheduling module further includes a data receiving interface 314. The data receiving interface 314 is adapted to receive the output data sent by the data sending interface of the function module, and The received output data is sent to the data distributor 308. Correspondingly, the data distributor 308 obtains the output data of the functional module from the data acceptance interface 314.

According to an embodiment, the scheduling module further includes an input state buffer register interface 316, the interface 316 is adapted to record the input state buffer address of each functional module, and the input state buffer is used to buffer the state of the input data of the functional module. Correspondingly, the data distributor 308 is also adapted to check the status of the input data of the subsequent functional module. When all the input data required by the subsequent functional module is included in the input buffer area and all the input data is available, the subsequent functional module The call entry address of is sent to the scheduler so that the scheduler can call the subsequent function module.

The scheduler 310 is adapted to receive the call entry address of the function module and call the function module to perform data processing.

According to an embodiment, the scheduling module further includes an output state buffer register interface 318, the interface 318 is adapted to record the output state buffer address of each functional module, and the output state buffer is used to buffer the state of the output data of the functional module. Correspondingly, the scheduler 310 is further adapted to: after calling the function module for data processing, store the output data of the function module in its output buffer area, and set the status of the output data in its output state buffer area to be available.

According to an embodiment, the scheduling module further includes a data mapping release interface 320, adapted to delete the mapping relationship between the output data of the functional module and the input data of the subsequent functional module from the data mapping table.

According to an embodiment, the scheduling module further includes a system control interface 322 adapted to receive control data to control the operation of the software. The system control interface 322 may include, for example, a start interface 324, which is adapted to receive start data (for example, START) to start the operation of the software, or to call a designated function module (that is, a function module in the software without input data) The entry address is sent to the scheduler 310 to start the running of the software.

Those skilled in the art can understand that in addition to the start interface 324, the system control interface 322 may also include other interfaces, such as a stop interface for terminating software operation, a pause interface for suspending software operation, etc., but it is not limited thereto.

Figures 2 and 3 generally illustrate the software operating method and software operating system of the present invention. Two embodiments will be used to illustrate the structure of the software operating system and the flow of the software operating method of the present invention in detail.

Example one

In the first embodiment, the software to be run includes a main module and at least one functional module.

The main module is the entrance to the software and is responsible for performing the following actions:

1. Load function module: call the initialization function of each module;

2. Load the data mapping table: load the data mapping table for the scheduling module of the software operating system;

3. Start the system: call the start interface of the dispatch module to make the dispatch module enter the running state.

The function module includes the following parts:

1. Input buffer area, used to buffer input data;

2. Input state buffer area, used to buffer the state of input data (available or unavailable);

3. Callback function, which is a function function for data processing of functional modules;

4. The initialization function is called when the software is running, and is responsible for registering the entry address and input data set with the dispatch module, the input buffer address and the input state buffer address.

In the first embodiment, the function module does not include an output buffer area, and the output data of the function module is sent to the scheduling module 400 through a data sending interface (for example, a send function).

Fig. 4 shows a structural diagram of a scheduling module 400 according to the first embodiment of the present invention. As shown in FIG. 4, the scheduling module 400 includes:

The input buffer register interface 402 is used to register the input buffer address of each functional module, and record each input buffer address in the input buffer address table 410.

The input state buffer register interface 404 is used to register the input state buffer address of each functional module, and record each input state buffer address in the input state buffer address table 412.

The module registration interface 406 is used to register the call entry address of each function module and the input data set as its trigger condition, and record the call entry address and input data of each function module in the call entry address and input data correspondence table 414.

The data mapping table load/remove interface 408 is used to load the data mapping table 416, set the mapping relationship between output data and input data, and delete the mapping relationship between output data and input data from the data mapping table.

The target data name list buffer 418 is used to record the data names of the output data received to the subsequent functional module during the data transfer process.

The data distributor 420 is used to send the received output data to the input buffer area of the corresponding function module and update its status according to the transmission path defined by the data mapping table, and to check each input in the input data set required to trigger the module For the status of the data, it is judged whether the module call can be implemented, if it is possible, the call entry address is sent to the scheduler 422 for calling, and the result is waited for; if not, it returns directly.

The scheduler 422 is used to receive the call entry address of the function module 430 and implement the call.

The system status register 424 is used to save the current status of the scheduling module 400, which is in an unexecutable status when initialized.

The named data sending interface 426 is used to receive named data and check the system status of the scheduling module 400. If it is in an unexecutable state, return; if it is in an executable state, send the named data to the data distributor 420.

The system control interface 428 is an interface used to start the software operation. It is responsible for setting the state of the scheduling module 400 to a runnable state, and sending the agreed named data used to indicate the start of the software, such as "START" without type and without The naming data of the content; according to actual needs, other control interfaces can also be agreed, such as system stop, suspend, pause, etc.

Fig. 5 shows a flowchart of the software running method corresponding to the first embodiment. As shown in Figure 5, first, the main module loads the function module, and the function module registers the entry function, named data set (ie input data set), input buffer area and input state buffer area address with the dispatch module. Accordingly, the dispatch module records Registration information of each functional module.

Subsequently, the main module loads the data mapping table to the scheduling module, and accordingly, the scheduling module records the data mapping table.

Subsequently, the main module starts the scheduling module, and the scheduling module sends named data (such as "START") indicating the start of the system. The data distributor 420 in the scheduling module receives the named data, determines the target function module according to the data mapping table, and assigns the received naming The data is sent to the input buffer area of the target function module. When the input data status of the target function module is valid (ready to use), reset the status of each input data in the input status buffer area, and send the call entry address to the scheduler 422, and the scheduler 422 calls the function module for data processing , The generated named data (output data) is sent to the data distributor 420, and the data distributor 420 determines the transfer direction of the received named data according to the data mapping table, and so on, until the last function module in the software is called. , After returning the result data, the software operation ends.

The following takes C language as an example to give an example of writing a software functional module and main module under the technical solution of the first embodiment, combined with the specific actions of the scheduling module 400 in the first embodiment, to illustrate more clearly How the present invention is used in the process of writing decoupled software modules. For ease of understanding, in this embodiment, the data name and data type are all expressed in character strings.

In this example, the C language description of the interface of the scheduling module is as follows:

1. Data sending API

int Send(const char*DataName,const char*DataType=0,void*DataAddress=0);

2. Named data cache address and status address registration API

int RegistNamedData(const char*DataName, int*StatusAddress=0, const char*DataType=0, void**DataRecieveAddress=0);

3. Data mapping setting API

int Link(const char*strFrom,const char*strTo);

4. Data mapping release API

int unLink(const char*strFrom,const char*strTo);

5. The registration API of the module entry address and its corresponding named data set

int Regist(int(*Callback)(),const char*DataName,const char*DataType=0);

6. System control API

int Run()

{

return Send("START");

};

This API implements the system startup interface in the first embodiment, and sends untyped named data named "START".

Next, explain how to write functional modules.

First, suppose that in a traditional C language system, there are three modules that have a calling relationship with each other. The usual writing is:

int A(int iX)

{

return iX+10;

};

int B(int iX,int iY)

{

return A(iX)+iY;

};

int C(int iX, int iY, int iZ)

{

return B(iX,iY)-iZ;

}

int main()

{

int iX,iY,iZ,iResult;

iX=1, iY=2, iZ=3;

iReturn=C(iX,iY,iZ);

printf("%d\r\n",iReturn);

return 0;

}

By implementing the present invention, the software can be written into six modules, including five functional modules, which are stored in

A.c, B.c, C.c, D.c, E.c, and a main module are stored in main.c.

The content of A.c is as follows:

int A(int iX)

{

return iX+10;

};

int*pX;

int iXStatus;

int iReturn;

int Callback()

{

iReturn=A(*pX);

Send("Module_A_Output","int",&iReturn);

return 0;

};

extern "C" int ModuleA()

{

Regist(Callback,"Module_A_X","int");

RegistNamedData("Module_A_X",&iXStatus,"int",&pX);

return 0;

};

int gINIT=ModuleA();

The content of B.c is as follows:

int B(int iX,int iY)

{

return iX+iY;

};

int*pX;

int*pY;

int iXStatus;

int iYStatus;

int iReturn;

int Callback()

{

iReturn=B(*pX,*pY);

Send("Module_B_Output","int",&iReturn);

return 0;

};

extern "C" int ModuleB()

{

Regist(Callback,"Module_B_X","int");

Regist(Callback,"Module_B_Y","int");

RegistNamedData("Module_B_X",&iXStatus,"int",&pX);

RegistNamedData("Module_B_Y",&iYStatus,"int",&pY);

return 0;

};

int gINIT=ModuleB();

The content of C.c is as follows:

int C(int iX,int iY)

{

return iX-iY;

};

int*pX;

int*pY;

int iXStatus;

int iYStatus;

int iReturn;

int Callback()

{

iReturn=C(*pX,*pY);

Send("Module_C_Output","int",&iReturn);

return 0;

};

extern "C" int ModuleC()

{

Regist(Callback,"Module_C_X","int");

Regist(Callback,"Module_C_Y","int");

RegistNamedData("Module_C_X",&iXStatus,"int",&pX);

RegistNamedData("Module_C_Y",&iYStatus,"int",&pY);

return 0;

};

int gINIT=ModuleC();

The content of D.c is as follows:

int*pResult;

int iResultStatus;

int Callback()

{

printf("%d\r\n",*pResult);

return 0;

};

extern "C" int ModuleD()

{

Regist(Callback,"Module_D_Result","int");

RegistNamedData("Module_D_Result",&iResultStatus,"int",&pResult);

return 0;

};

int gINIT=ModuleD();

The content of E.c is as follows:

int iX,iY,iZ;

int iStartStatus;

int Callback()

{

iX=1, iY=2, iZ=3;

Send("Module_E_X","int",&iX);

Send("Module_E_Y","int",&iY);

Send("Module_E_Z","int",&iZ);

return 0;

};

extern "C" int ModuleE()

{

Regist(Callback,"Module_E_START");

return 0;

};

int gINIT=ModuleE();

The content of main.c is as follows:

int main()

{

ModuleA();

ModuleB();

ModuleC();

ModuleD();

ModuleE();

Link("Module_E_X","Module_A_X");

Link("Module_A_Output","Module_B_X");

Link("Module_E_Y","Module_B_Y");

Link("Module_B_Output","Module_C_X");

Link("Module_E_Z","Module_C_Y");

Link("Module_C_Output","Module_D_Result");

Link("START","Module_E_START");

return Run();

}

In particular, as those skilled in the art know, the compiler usually supports the initialization of global variables. At this time, the initialization of each module of A, B, C, D, and E can be automatically completed when the system loads the program, without the need for the main module Explicitly completed in, so the content of main.c becomes:

int main()

{

Link("Module_E_X","Module_A_X");

Link("Module_A_Output","Module_B_X");

Link("Module_E_Y","Module_B_Y");

Link("Module_B_Output","Module_C_X");

Link("Module_E_Z","Module_C_Y");

Link("Module_C_Output","Module_D_Result");

Link("START","Module_E_START");

return Run();

}

In order to facilitate understanding, in this example, the content of the data mapping table is directly defined in the main function. However, those skilled in the art should easily think that the data mapping table can be stored independently of the main body of the program, and through dynamic Way to load.

The specific operation process and the calling relationship between modules are shown in Figure 6:

First, load each module, register the named data and state cache address; load the data mapping table; start the scheduling module; the scheduling module sends the named data START. The dispatch module receives the named data START, and sends it to the module E according to the data mapping table. Check the calling conditions of module E, if the conditions are met, reset the input data state of module E, and call module E. Module E sends output data Module_E_X, and the scheduling module receives output data Module_E_X, and sends it to the input buffer area of Module_A_X according to the data mapping table. Determine the trigger condition of module A, if the condition is met, reset the input data state of module A, and call module A. Module A processes the data and sends the output data Module_A_Output. The scheduling module receives the output data Module_A_Output and sends it to the input buffer of Module_B_X according to the data mapping table. The dispatch module checks the trigger condition of module B, and the call cannot be implemented due to lack of named data Module_B_Y; the dispatch module returns to module A; the module A returns to the dispatch module; the dispatch module returns to the module E. Module E continues to send the named data Module_E_Y; the scheduling module receives Module_E_Y and sends it to the input buffer of Module_B_Y according to the data mapping table; the scheduling module checks the trigger condition of module B, the condition is met, resets the input state of module B, and calls Module B. Module B processes the data and sends the output data Module_B_Output. The scheduling module receives Module_B_Output and sends it to the buffer of Module_C_X according to the data mapping table. The dispatch module checks the trigger condition of module C, and the call cannot be implemented due to lack of input data Module_C_Y. The dispatch module returns to module B, module B returns to dispatch module, and the dispatch module returns to module E. Module E continues to send the named data Module_E_Z, and the scheduling module receives Module_E_Z and sends it to the input buffer of Module_C_Y according to the data mapping table. The dispatch module checks the trigger condition of module C, and the condition is met, resets the input data state of module C, and calls module C. Module C processes the data and sends the output data Module_C_Output. The scheduling module receives Module_C_Output and sends it to Module_D_Result according to the data mapping table. The scheduling module checks the trigger condition of the module D, the condition is met, resets the input data state of the module D, and calls the module D. Module D prints the data and returns to the dispatch module, from the dispatch module to the module C, from the module C to the dispatch module, from the dispatch module to the module E, from the module E to the dispatch module; from the dispatch module to the main, End.

Similar to the above C language software example, in the C++ language-based programming example, you can first define a base class to describe the interface of the functional module in general. For example, a given base class is defined as follows:

class_Base

{

public:

virtualCallback();

};

Correspondingly, in the scheduling module, the description of the function module entry can be specifically implemented by the pointer of the object. At this point, in contrast to the above C language example, the registration API of the module entry address and its corresponding named data set can be changed to:

int Regist(_Base*pModual,const char*DataName,const char*DataType=0);

The other interfaces do not need to be changed.

At the same time, the data cache, data processing function, and initialization in the corresponding module definition can all correspond to class variables, overloaded functions and constructors.

Specifically, here, taking module A in embodiment 2 as an example, its C++ description becomes:

class CA:public_Base

{

int*iX;

int iXStatus;

int iReturn;

public:

CA()

{

Regist(this,"Module_A_iX","int");

RegistNamedData("Module_A_iX",&iXStatus,"int",&iX);

}

virtual int Callback()

{

iReturn=*iX+10;

Send("Module_A_Output","int",&iReturn);

return 0;

};

};

CA*gOBJ=0;

int gINIT=A();

extern "C" int A()

{

if(gOBJ＝＝0)gOBJ＝new CA();

return 0;

}

No modification is required in the main function of the corresponding main module.

Example two

In the second embodiment, the software to be run includes a main module and at least one functional module.

The main module is the entrance to the software and is responsible for performing the following actions:

1. Load function module: call the initialization function of each module;

2. Load the instance list: create a function module instance according to the instance list;

3. Load the data mapping table: load the data mapping table for the scheduling module;

4. Start the system: call the start interface of the dispatch module to make the dispatch module enter the running state, and send the designated start module to the dispatch queue.

The function module includes the following parts:

1. Callback function used to create an instance: used to create an instance, including the required system resources, input and output data cache and data state cache, etc., complete the registration of the input and output data cache and state cache address, and return the instance address;

2. Callback function used to release the instance: used to reclaim related resources of a given instance

3. Function callback function: the function function of the function module for data processing

4. Initialization function: Called when the system is loaded, responsible for registering the module name with the scheduling module, module-related function callback entry, instance creation callback entry, and release callback function entry.

In the second embodiment, the function module includes an output buffer area, and accordingly, the scheduling module can read the output data of the function module from the output buffer area of the function module. In addition, this embodiment provides an implementation manner in which the same functional module (ie, functional module instance) is used multiple times in the same software. At this time, each functional module instance has its own independent input and output data and buffer area. Correspondingly, the scheduling module provides related interfaces for managing functional module instances.

Fig. 7 shows a structural diagram of a scheduling module 700 according to the second embodiment of the present invention. As shown in FIG. 7, the scheduling module 700 includes:

The function module registration interface 702 is used to register a function module, and record the module name of the function module, the calling entry, the function entry for creating the function module instance, and the function entry for releasing the function module instance into the function module table cache 712.

The function module instance creation interface 704 is used to create an instance of a given function module, query the function module list, call the instance creation function, and save the instance name and the instance address returned by the creation function in the function module instance table cache 714.

Instance input buffer area and input state buffer area registration interface 706, used to register the input buffer area and input state buffer area addresses of each instance, and record the input buffer area and input state buffer area addresses in the input buffer area and input state buffer area Address table 716.

Instance output buffer area and output status buffer area registration interface 708, used to register the output buffer area and output status buffer area address of each instance, and record the output buffer area and output status buffer area address in the output buffer area and output status buffer area Address table 718.

The data mapping table loading/removing interface 710 is used to load the data mapping table 720, set the mapping relationship between output data and input data, and delete the mapping relationship between output data and input data from the data mapping table.

The data distributor 722 is used to send the output data of the function module that has completed the call to the receiving buffer of the corresponding function module instance according to the transmission path defined by the data mapping table and update its status, and to check all the inputs required by the instance According to the data status, it is judged whether the call can be implemented, and if so, the instance is sent to the dispatch queue 724.

The dispatch queue 724 is used to buffer the queue of the instance of the function module that implements the call.

The scheduler 726 is configured to obtain the call entry address from the dispatch queue 724 and implement the call.

The system status register 728 is used to save the current status of the scheduling module 700, which is in an unexecutable status when initialized.

The system control interface 730 is an interface used to start the software operation, check and update the system status, and is responsible for sending the specified function module instance to the dispatch queue. The function module corresponding to the instance should be a module without input. If it is not specified for starting Instances of function modules, the system should start all instances of function modules without input. In addition, according to actual needs, other control interfaces can also be agreed, such as system stop, suspend, pause, etc.

Fig. 8 shows a flowchart of the software running method corresponding to the second embodiment. As shown in Figure 8, first, the main module loads the function module, and the function module registers the module name, entry function, instance creation function, and instance release function with the dispatch module. Accordingly, the dispatch module records various registration information of the function module.

Subsequently, the main module loads the function module instance table to the dispatch module, and the dispatch module calls the instance creation function of each module according to the instance table to create each instance. The function module instance creation function initializes the input data and the input state buffer address, and registers it with the dispatch module. Accordingly, the dispatch module records the instance name and instance address in the instance list buffer.

Subsequently, the main module loads the data mapping table to the dispatch module, and the dispatch module records the data mapping table.

The main module calls the dispatch module to start the interface to start the software operation, the dispatch module reads the function module instance from the dispatch queue, and calls the function module entry function corresponding to the instance with the instance as a parameter. The called function module reads the input data buffer area of a given instance, performs data processing functions, and writes the generated data and status into the instance output buffer. According to the data mapping table, the scheduling module sends the output data of the running instance in the normal state to the input buffer of the corresponding subsequent function module instance, and checks all the input data states of the function module instance, when all are valid In the state, all input states of the instance are reset and the instance is sent to the dispatch queue. Check whether the dispatch queue is empty, if it is empty, it ends, if it is not empty, it returns.

Taking C language as an example, an example of writing a functional module and main module of a software under the technical solution of the second embodiment is given below, and combined with the specific actions of the scheduling module 700 in the second embodiment, to explain more clearly How the present invention is used in the process of writing decoupled software modules. For ease of understanding, in this embodiment, the data name and data type are all expressed in character strings.

In this example, the C language description of the interface of the scheduling module is as follows:

1. Function module registration API

int RegisterModule(const char*ModuleName,int(*Callback)(),void*(*Create)(const char*InstanceName),void(*Release)(void*));

2. Create function module instance API

int Instance(const char*ModuleName,const char*InstanceName);

3. Enter the named data cache address and state address registration API

int RegistInput(const char*InstanceName,const char*InputName,int*StatusAddress=0,const char*DataType=0,void**DataRecieveAddress=0);

4. Output named data cache address and status address registration API

int RegistOutput(const char*InstanceName,const char*OutputName,int*StatusAddress=0,const char*DataType=0,void**DataRecieveAddress=0);

5. Data mapping setting API

int Link(const char*fromInstanceName,const char*strFrom,const char*toInstanceName,const char*strTo);

6. Data mapping release API

int unLink(const char*fromInstanceName,const char*strFrom,const char*toInstanceName,const char*strTo);

7. System startup API

int Start(const char*InstanceName);

In addition, in actual use, a query interface for information such as registered modules, module instances, and mappings in the scheduling module can be added, which will not be repeated here.

In this example, the sample codes of the function modules A to E and the main module main are as follows (wherein, the convention for the meaning of the status identifier is: 0 represents normal, and others represent errors).

The content of A.c is as follows:

int A(int iX)

{

return iX+10;

};

typedef struct

{

int*pInput0;

int iInputStatus0;

int Output0;

int*pOutput0;

int iOutputStatus0;

}Moudle_Instance;

void*Create(const char*Instance Name)

{

Module_Instance*pInstance=(Module_Instance*)calloc(sizeof(Module_Instance));

pInstance->pOutput0=&pInstance->Output0;

RegistInput(InstanceName,"MODULE_A_INPUT_0",&pInstance->iInputStatus0,"int",&pInstance->pIn put0);

RegistOutput(InstanceName,"MODULE_A_OUTPUT_0",&pInstance->iOutputStatus0,"int",&pInstance->pOutput0);

return pInstance;

}

void Release(void*p)

{

free(p);

}

int Callback(void*p)

{

Moudle_Instance*pInstance=(Moudle_Instance*)p;

*pInstance->pOutput0=A(*pInstance->pInput0);

pInstance->iOutputStatus0=0;

return 0;

};

extern "C" int ModuleA()

{

Regist("ModuleA",Callback,Create,Release);

return 0;

};

int gINIT=ModuleA();

The content of B.c is as follows:

int B(int iX,int iY)

{

return iX+iY;

};

typedef struct

{

int*pInput0;

int*pInput1;

int iInputStatus0;

int iInputStatus1;

int Output0;

int*pOutput0;

int iOutputStatus0;

}Module_Instance;

void*Create(const char*InstanceName)

{

Module_Instance*pInstance=(Module_Instance*)calloc(sizeof(Module_Instance));

pInstance->pOutput0=&pInstance->Output0;

RegistInput(InstanceName,"MODULE_B_INPUT_0",&pInstance->iInputStatus0,"int",&pInstance->pIn put0);

RegistInput(InstanceName,"MODULE_B_INPUT_1",&pInstance->iInputStatus1,"int",&pInstance->pIn put1);

RegistOutput(InstanceName,"MODULE_B_OUTPUT_0",&pInstance->iOutputStatus0,"int",&pOutput->pOutput0);

return pInstance;

}

void Release(void*p)

{

free(p);

}

int Callback(void*p)

{

Module_Instance*pInstance=(Module_Instance*)p;

*pInstance->pOutput0=B(*pInstance->pInput0,*pInstance->pInput1);

pInstance->iOutputStatus0=0;

return 0;

};

extern "C" int ModuleB()

{

Regist("ModuleB",Callback,Create,Release);

return 0;

};

int gINIT=ModuleB();

The content of C.c is as follows:

int C(int iX,int iY)

{

return iX-iY;

};

typedef struct

{

int*pInput0;

int*pInput1;

int iInputStatus0;

int iInputStatus1;

int Output0;

int*pOutput0;

int iOutputStatus0;

}Module_Instance;

void*Create(const char*InstanceName)

{

Moudle_Instance*pInstance=(Module_Instance*)calloc(sizeof(Module_Instance));

pInstance->pOutput0=&pInstance->Output0;

RegistInput(InstanceName,"MODULE_C_INPUT_0",&pInstance->iInputStatus0,"int",&pInstance->pIn put0);

RegistInput(InstanceName,"MODULE_C_INPUT_1",&pInstance->iInputStatus1,"int",&pInstance->pIn put1);

RegistOutput(InstanceName,"MODULE_C_OUTPUT_0",&pInstance->iOutputStatus0,"int",&pInstance->Output0);

return pInstance;

}

void Release(void*p)

{

free(p);

}

int Callback(void*p)

{

Module_Instance*pInstance=(Module_Instance*)p;

*pInstance->pOutput0=C(*pInstance->pInput0,*pInstance->pInput1);

pInstance->iOutputStatus0=0;

return 0;

};

extern "C" int ModuleC()

{

Regist("ModuleC",Callback,Create,Release);

return 0;

};

int gINIT=ModuleC();

The content of D.c is as follows:

typedef struct

{

int*pInput0;

int iInputStatus0;

}Module_Instance;

void*Create(const char*InstanceName)

{

Module_Instance*pInstance=(Module_Instance*)calloc(sizeof(Module_Instance));

RegistInput(InstanceName,"MODULE_D_INPUT_0",&pInstance->iInputStatus0,"int",&pInstance->pIn put0);

return pInstance;

}

void Release(void*p)

{

free(p);

}

int Callback(void*p)

{

Module_Instance*pInstance=(Module_Instance*)p;

printf("%d\r\n",*pInstance->pInput0);

return 0;

};

extern "C" int ModuleD()

{

Regist("ModuleD",Callback,Create,Release);

return 0;

};

int gINIT=ModuleD();

The content of E.c is as follows:

typedef struct

{

int Output0;

int*pOutput0;

int iOutputStatus0;

int Output1;

int*pOutput1;

int iOutputStatus1;

int Output2;

int*pOutput2;

int iOutputStatus2;

}Module_Instance;

void*Create(const char*InstanceName)

{

Module_Instance*pInstance=(Module_Instance*)calloc(sizeof(Module_Instance));

pInstance->pOutput0=&pInstance->Output0;

pInstance->pOutput1=&pInstance->Output1;

pInstance->pOutput2=&pInstance->Output2;

RegistOutput(InstanceName,"MODULE_E_OUTPUT_0",&pInstance->iOutputStatus0,"int",&pInstance->pOutput0);

RegistOutput(InstanceName,"MODULE_E_OUTPUT_1",&pInstance->iOutputStatus1,"int",&pInstance->pOutput1);

RegistOutput(InstanceName,"MODULE_E_OUTPUT_2",&pInstance->iOutputStatus2,"int",&pInstance->pOutput2);

return pInstance;

}

void Release(void*p)

{

free(p);

}

int Callback(void*p)

{

Module_Instance*pInstance=(Module_Instance*)p;

pInstance->iOutputStatus0=pInstance->iOutputStatus1=pInstance->iOutputStatus2=0;

*pInstance->pOutput0＝1;

*pInstance->pOutput1=2;

*pInstance->pOutput2=3;

return 0;

};

extern "C" int ModuleE()

{

Regist("ModuleE",Callback,Create,Release);

return 0;

};

int gINIT=ModuleE();

Finally, using the system API, assuming that in the windows system, if the five modules A～E are compiled as

A.dll～E.dll five dynamic libraries, with the help of Windows API LoadLibary, the content of main.c is as follows:

int main()

{

LoadLibary("A.dll");

LoadLibary("B.dll");

LoadLibary("C.dll");

LoadLibary("D.dll");

LoadLibary("E.dll");

Instance("ModuleA","InstanceA");

Instance("ModuleB","InstanceB");

Instance("ModuleC","InstanceC");

Instance("ModuleD","InstanceD");

Instance("ModuleE","InstanceE");

Link("ModuleE","MODULE_E_OUTPUT_0","ModuleA","MODULE_A_INPUT_0");

Link("ModuleA","MODULE_A_OUTPUT_0","ModuleB","MODULE_B_INPUT_0");

Link("ModuleE","MODULE_E_OUTPUT_1","ModuleB","MODULE_B_INPUT_1");

Link("ModuleB","MODULE_B_OUTPUT_0","ModuleC","MODULE_C_INPUT_0");

Link("ModuleE","MODULE_E_OUTPUT_2","ModuleC","MODULE_C_INPUT_1");

Link("ModuleC","MODULE_C_OUTPUT_0","ModuleD","MODULE_D_INPUT_0");

return Start("InstanceE");

}

The specific operation process and the calling relationship between modules are shown in Figure 9:

First, load each module, register the module name, module entry function, module instance creation function and release function; load the instance list; load the data mapping table; start the scheduling module. The scheduling module sends instance E (InstanceE) into the scheduling queue. Read the dispatch queue to obtain instance E, the dispatch module calls instance E, and resets the input data set state of instance E. The scheduling module sends the named data MODULE_E_OUPUT_0, and sends it to the buffer of MODULE_A_INPUT_0 according to the data mapping table to determine the trigger condition of instance A. If the condition is met, the instance A is placed in the dispatch queue. The scheduling module sends the named data MODULE_E_OUPUT_1 and sends it to the buffer of MODULE_B_INPUT_1 according to the data mapping table to determine the trigger condition of instance B. If it is not met, continue. The scheduling module sends the named data MODULE_E_OUPUT_2 and sends it to the buffer of MODULE_C_INPUT_1 according to the data mapping table to determine the trigger condition of instance C. If it is not met, continue. Check the dispatch queue; read the dispatch queue to obtain instance A, the dispatch module calls instance A, and resets the input data set state of instance A. The scheduling module sends the named data MODULE_A_OUPUT_0, and sends it to the buffer of MODULE_B_INPUT_0 according to the data mapping table to determine the trigger condition of instance B. If the condition is met, the instance B is placed in the dispatch queue. Check the dispatch queue; read the dispatch queue to obtain instance B, the dispatch module calls instance B, and resets the input named data set state of instance B. The scheduling module sends the named data MODULE_B_OUPUT_0, and sends it to the buffer of MODULE_C_INPUT_0 according to the data mapping table to determine the trigger condition of the instance C, and the condition is met, and the instance C is placed in the dispatch queue. Check the dispatch queue; read the dispatch queue, obtain instance C, dispatch module calls module C, and reset the input named data set state of instance C. The scheduling module sends the named data MODULE_C_OUPUT_0, and sends it to the buffer of MODULE_D_INPUT_0 according to the data mapping table to determine the trigger condition of the instance D. If the condition is met, the instance D is placed in the dispatch queue. Check the dispatch queue; read the dispatch queue, obtain instance D, the dispatch module calls module D, and reset the input named data set state of instance D; check that the dispatch queue is empty, return to main; end.

According to the solution of the present invention, a module with independent data processing capability is written as a functional module, and data transmission and processing are realized based on the mapping relationship provided by the data mapping table. This solution fundamentally solves the problem of functional coupling and data coupling in the software development process. At the level of source software compilation, it is possible to realize the method of functional module isolation and system processing logic independence, which provides the necessary technical means for solving the large division of labor in the software development process. The implementation of this program not only enables functional modules to be used everywhere at one time, greatly improving development efficiency, but also makes the developed software products easy to modify, easy to maintain, and have great use and promotion value.

Claims (21)

1. A software operation method, the software includes a plurality of mutually independent functional modules, the functional modules are adapted to process input data to obtain output data, and the functional modules have an input buffer area for buffering the input data, The method is adapted to be executed in an operating system that resides in a computing device, and the method includes:

   Acquiring a data mapping table of the software, where the data mapping table is suitable for recording the transfer direction of data among multiple functional modules;

   Obtain the output data of a functional module;

   Based on the data mapping table, determine the subsequent functional module that uses the output data as input data, and store the output data in the input buffer area of the subsequent functional module; and

   When the input buffer area includes all the input data required by the subsequent functional module, the subsequent functional module is called for data processing.
2. 3. The method of claim 1, wherein the data mapping table is configured in a main module of the software or in other files, and the other files are independent of the software;

   The step of obtaining the data mapping table of the software includes: obtaining and loading the data mapping table from the main module or other files.
3. The method according to claim 1 or 2, wherein the function module further has an output buffer area for buffering its output data;

   The step of obtaining the output data of a functional module includes: reading the output data from the output buffer area of the functional module.
4. The method according to claim 1 or 2, wherein the functional module further comprises a data sending interface for sending output data;

   The step of obtaining the output data of a functional module includes: receiving the output data sent by the data sending interface of the functional module.
5. The method according to any one of claims 1-4, wherein the function module further has a corresponding call entry and an input state buffer area for buffering the state of input data, and when the input data of the function module is stored in it After entering the buffer area, set the state of the corresponding input data in the input state buffer area to available;

   The step of calling the subsequent function module for data processing includes:

   According to the input state buffer area, check the state of the input data required by the subsequent functional module;

   In the case where all the required input data states are available, the subsequent function module is called to perform data processing.
6. The method according to claim 3, wherein the functional module further has an output state buffer area for buffering the output data state;

   After the step of calling the subsequent function module for data processing, the method further includes:

   Store the output data of the subsequent functional module in its output buffer area; and

   Set the status of the output data in its output status buffer area to available.
7. The method of claim 1, further comprising:

   Obtain and record the address of at least one of the input buffer area, input state buffer area, output buffer area, and output state buffer area of each functional module, wherein the input buffer area, input state buffer area, output buffer area, and output state The address of the buffer area is provided by the corresponding function module.
8. The method according to claim 1, wherein the functional module can be multiplexed by creating multiple instances, and each instance corresponds to an input buffer area and/or an output buffer area.
9. The method of claim 1, wherein:

   The input data and output data of each functional module are identified by a combination of data name and data type.
10. The method according to claim 1, wherein the first function module called in the software is a function module without input data.
11. A software running system that resides in a computing device and is suitable for running software. The software includes a plurality of mutually independent functional modules, and the functional modules are adapted to process input data to obtain output data. The software runs The system includes a scheduling module, the scheduling module includes:

    The input buffer area registration interface is suitable for recording the address of the input buffer area of each functional module, and the input buffer area is used to buffer the input data of the functional module;

    Module registration interface, suitable for recording the call entry address of each function module and the input data set as its trigger condition;

    The data mapping loading interface is adapted to obtain the data mapping table of the software, and set the mapping relationship between the output data of the functional module and the input data of the subsequent functional module according to the data mapping table;

    The data distributor is adapted to obtain the output data of the functional module, and according to the data mapping table, send the obtained output data to the input buffer area of the corresponding subsequent functional module, and when the input buffer area is included in the subsequent functional module When all required input data, the call entry address of the subsequent function module is sent to the scheduler;

    The scheduler is adapted to receive the call entry address of the function module and call the function module for data processing.
12. The system according to claim 11, wherein the data mapping table is configured in the main module of the software or in other files, and the other files are independent of the software;

    The data mapping loading interface is suitable for obtaining and loading the data mapping table from the main module or other files.
13. The system according to claim 11 or 12, wherein the scheduling module further comprises:

    The output buffer area registration interface is suitable for recording the output buffer area address of each functional module, and the output buffer area is used to buffer the output data of the functional module;

    The data distributor is adapted to read output data from the output buffer area of the functional module.
14. The system according to claim 11 or 12, wherein the functional module includes a data sending interface for sending output data;

    The scheduling module further includes: a data receiving interface adapted to receive output data sent by the data sending interface of the function module, and send the received output data to the data distributor.
15. The system according to any one of claims 11-14, wherein the scheduling module further comprises:

    The input state buffer area registration interface is suitable for recording the address of the input state buffer area of each functional module, and the input state buffer area is used to buffer the state of the input data of the functional module;

    The data distributor is further adapted to: when all the input data required by the subsequent functional module is included in the input buffer area and all the input data is available, the call entry address of the subsequent functional module is sent to the scheduler so that the scheduler Call the subsequent function module.
16. The system according to claim 13, wherein the scheduling module further comprises:

    The output state buffer area registration interface is suitable for recording the address of the output state buffer area of each functional module, and the output state buffer area is used to buffer the state of the output data of the functional module;

    The scheduler is adapted to store the output data of the function module in its output buffer area after calling the function module for data processing, and set the status of the output data in its output state buffer area to be available.
17. The system according to claim 11, wherein the scheduling module further comprises:

    The data mapping release interface is adapted to delete the mapping relationship between the output data of the functional module and the input data of the subsequent functional module from the data mapping table.
18. The system according to claim 11, wherein the scheduling module further comprises:

    The system control interface is adapted to receive control data to control the operation of the software.
19. The system of claim 18, wherein the system control interface comprises:

    The startup interface is adapted to receive startup data to start the operation of the software, or send the call entry address of the designated function module to the scheduler to start the operation of the software.
20. A computing device including:

    At least one processor; and

    Memory storing program instructions;

    When the program instructions are read and executed by the processor, the computing device is caused to execute the method according to any one of claims 1-10.
21. A readable storage medium storing program instructions, when the program instructions are read and executed by a computing device, the computing device executes the method according to any one of claims 1-10.

Images