WO2007040419A1

WO2007040419A1 - Software integration (assembly) method

Info

Publication number: WO2007040419A1
Application number: PCT/RU2005/000581
Authority: WO
Inventors: Georgy Mikhailovich Shagov
Original assignee: Georgy Mikhailovich Shagov
Priority date: 2005-10-04
Filing date: 2005-11-18
Publication date: 2007-04-12
Also published as: RU2005130659A; RU2306597C2

Abstract

The invention relates to software integration (assembly) methods. The inventive method consists in forming a binary matrix of pointers to function of modules in a main memory by a defined program module, in assembling said modules in the form of individual files in such a way that, when a function is called from a module N, wherein K is the function serial number in the module, the control is transmitted to the function whose address is stored in the matrix in the N-th line and K-th column. In the case when, during the use of a debugger of another error detection system, it is discovered that the module and the file corresponding thereto contain an error, the inventive method consists, after making required corrections in the algorithm source-code, in reloading said module, in subsequently translating/compiling said source code, in reloading the previous module version into a new definitive version and in testing it. The use of said invention enables a design engineer to save time and makes it possible to introduce changes into an already started system without rerunning it.

Description

METHOD FOR ASSEMBLY (ASSEMBLY) OF THE SOFTWARE

FIELD OF THE INVENTION This invention relates to methods for assembling (assembling) software (software), namely to forming a plurality of software modules in separate files.

When using this method, developers have the opportunity to replace the functionality of any matrix element without rebuilding and / or restarting the system.

State of the art

From the prior art at the moment two methods of software assembly are known: • Static assembly

• Dynamic assembly (or dynamic layout),

(i.e. the method of connecting standard functions and / or data to the executable program at the time of accessing them by calling them from a special library). in the general case, the software being developed today, in its final working phase, is a machine code

(be it processor directives or commands of any virtual machine). This code can be called a “black box”.

If the “black box” contains an error, then the general way to neutralize it is reduced to the following steps:

1. Search or localization of the problem. This operation can be performed by various methods: a. Analysis of external system data: messages about errors, logs, entries in the database, etc. b. Reproducing a Problem in a Runable Environment

"Black box" in debug mode. 2. Remedy by changing the "original code" 3. Reassembly of the "black box"

4. System restart

5. Obtaining confirmation that the problem has been resolved by re-testing.

For large software companies, this procedure is much more complicated.

With this approach, a lot of time is wasted to eliminate even very minor errors. Moreover, the reassembly of the “black box” alone can take several hours. Accordingly, if there are two or three problems that are distributed between two, three developers, then only the reassembly process can take several days.

SUMMARY OF THE INVENTION An object of the present invention is to prevent the black box from being assembled and / or restarting the system.

The technical result that is achieved by using the claimed invention is to save the developer’s time and to provide the ability to make changes to an already launched system without restarting it.

The specified technical result is achieved due to the fact that in the method of compiling (assembling) the software, a certain software module generates in binary memory a binary matrix of pointers to the functions of the modules, which collected in the form of separate files, with their subsequent loading into the executable program, so that when a function is called from module N, where K is the number of the function in the module, control is transferred to the function whose address is in the matrix in the Nth row, K- th column, and the module and the corresponding file containing the error are reloaded after making the necessary corrections to the source code of the algorithm, followed by compilation and rebooting of the previous version of the module to a debugged new one, with subsequent testing. In a preferred embodiment of the proposed invention, the module containing the error is replaced by another module whose corresponding functions are set in such a way that when they are executed, a decision is made about which function of the module (previously or newly assembled) should be executed, or about which script -file performing the corresponding function must be executed by the corresponding script machine (interpreter).

DESCRIPTION OF DRAWINGS FIG. 1 is a block diagram of a computing system according to the present invention.

In FIG. Figure 2 shows a block diagram of the binding of a software module and its constituent elements to RAM, the file system, and the I / O bus. In FIG. Figure 3 shows a classic example of a fragment of a program written in C.

In FIG. 4 shows a block diagram of a matrix of pointers.

In FIG. Figure 5 shows a diagram in which an example of an algorithm executed on a certain abstract algorithmic programming language.

In FIG. Figure 6 shows the block diagram of the "control" module.

In FIG. 7 is a block diagram of an algorithm for implementing the requirements for the “machine code” of a “software module)).

In FIG. 8 flowchart of the “function-function)).

In FIG. 9 is a diagram of the process of loading the module with the number M.

In FIG. 10 is a diagram showing the result of loading the proxy module with number M.

In FIG. 11 is a block diagram of the loading algorithm by the “managing”) module of the “main” modules.

In FIG. Figure 12 shows the standard block diagram of compiling the source code of the algorithm into a “software”) module.

In FIG. 1 is a block diagram of a computing system according to the present invention. A computing system includes a central processing unit (CPU), RAM, I / O buses, and a file system. A computing system may also include various elements not shown in the drawing for the purpose of clarity of its presentation, such as drives, keyboards, display devices, network connections, additional memory buses, additional CPUs, etc. In FIG. Figure 2 shows a block diagram of the binding of a software module and its constituent elements to RAM, the file system, and the I / O bus.

FIG. 3 illustrates the following example.

This is a classic example of a program written in C. The proposed approach is that the given source code

(the source code is the text of the program in an algorithmic language; on a computer, the source text is either directly executed by an interpreter - translator capable of simultaneously translating and executing a program written in a high-level algorithmic language, or is preliminarily translated by the compiler into a standard boot code that can be repeatedly executed in a certain computing environment) is considered as two components - “algorithm” and “system”. "Algorithm" (in this example) is the output to the console of the string "Hello world". “Security” in this case is meant by some functionality that implements the “printf” function. An example is the "MSVCRT.DLL" or the "LIBC" library.

The meaning of this conditional decomposition of the source code is to state that the “algorithm” must be modifiable directly during the operation of the system, without restarting and / or rebuilding.

This modification is carried out using the matrix and codes of the main modules. The matrix can be performed in various ways.

The most preferable ones are the tables “specifying a function). Those. the matrix is a two-dimensional data array, the number of rows in which corresponds to the number of “basic” modules, while the number of elements in each row coincides with the number of algorithm functions of the corresponding module. Each matrix element is a pointer to the corresponding function of the corresponding module (see Fig. 4).

“Algorithm” is the source code of the “main” modules. By “index to function)) we mean a certain physical object that uniquely identifies the function of the module, so that the transfer of control at a given pointer (address), within the framework of the executing machine, would lead to the execution of this function.

Accordingly, how this control will be transferred to a particular function, this method does not normalize in any way, since it depends on what specific code is executed by which particular machine / processor. For example, if this is machine code (processor instructions), then the address of the function is nothing more than 4 bytes (a pointer to a function in a 32-bit system or 8 bytes of 64-bit) and the transfer of control is nothing more than an assembler command “call ". “Cycle”) is a machine code, the pointers to the functions of which, as in the case of the algorithm, are matrix elements, with the only difference being that there is a black box under these elements, the algorithm of which is immutable. At the same time, “cychnosti”, being nothing more than matrix elements, can be replaced.

The source code is executed in the form of an algorithmic programming language. The main requirement for the source code is the availability of a translator (a program that converts text written in one language into text in another language) or a compiler. A compiler is a program that converts text written in an algorithmic language into a program consisting of machine instructions. The compiler creates a complete version of the program in machine language. This translator / compiler has the following requirements:

• A translator / compiler based on this source code can assemble a “software module)) (according to GOST 19781- 90 software module is a program or functionally complete fragment of a program intended for: storage; Broadcast associations with other software modules; and loading into RAM). • In the “machine code” (in this case, machine codes are understood to mean both the instructions of the processor and the instructions of a virtual machine) obtained as a result of translation / compilation, the notion of “index for a function” must be present)). A function pointer refers to a physical object that uniquely identifies the function of a module, so that transferring control to a given pointer (address), within the framework of the executing machine, would lead to the execution of this function.

An additional, but not mandatory, requirement is the presence of an interpreter (an interpreter is a translator capable of simultaneously translating and executing a program written in a high-level algorithmic language) for a given programming language.

In FIG. Figure 5 shows a diagram in which an example of an algorithm performed in a certain abstract algorithmic programming language is considered.

The diagram shows a primitive algorithm consisting of two functions, “functionl”, “function2”, and “tunction2” calls “functionl” (line 7). Suppose that this source code is the base for building some kind of software module.

The method assumes that with the help of a translator / compiler a “program module)) will be assembled, which will be loaded into the executable system. At this stage, the method does not differ from the known technical solutions, except that:

• The program module must be a “core” module (described below) • The machine code of the module must be assembled in such a way that a call to the fιmctionl function made from the fimction2 function should not result in the transfer of control to the function function, and control should passed to the function whose address is currently in the corresponding matrix element. For example, suppose that the number of our module in the system is N, and the number of the functionl function in the module is 1, then the implementation of the token of line 7 is reduced to the fact that control is transferred to the function whose address is in the matrix in the Nth line, 1- ohm column (see diagram in Fig. 7). In this diagram:

• a solid arrow means that the value of the corresponding pointer (the place of the arrow's exit) contains the address of the corresponding function of the corresponding module, for example, Pointer 1 of the line M contains the address of function 1 of the “main” module M.

• a dashed line means that when the function of the algorithm is called, the function whose address is in the corresponding matrix pointer will be called. For example, when calling the function “functionl” of module M, a function will be called whose address is in the matrix of pointers in row M, the first column.

This is the requirement for the “machine code” of the “software module” method.

The method does not regulate exactly how the machine code will be executed in such a way that it (the code) Satisfied this requirement. There are many algorithms for solving this problem, but this issue is not considered in the framework of this method.

The “main” module is a “software” module obtained as a result of translation / compilation of the source code of the algorithm (see Fig. 12). The "main" module also contains additional functionality "and data:

• a unique identifier of the module (within the system) required by the control module to identify this “basic module”;

• functionality initializing the corresponding elements of the matrix row with pointers to the functions of this module; here it is necessary to note that each algorithmic function of the “original code” of this “main model” also has its own identifier, so that each “function code)) has its own unique (within the module) identifier;

• a pointer to a matrix received from the manager)) module (the presence of a matrix implies the presence of a “software module)) where this matrix will be executed, physically created. This module is a “control” module (see Fig. 6). The same modules (in the given example, it is one), which will directly contain the code of the performed functions of the algorithm - the script refers to the "main"> modules). The “Control” module has the following technical requirements: o 1. Storage of the matrix of elements. о 2. “The control)) module implements the algorithm for loading the“ basic)) modules (see the diagram in Fig. 11).

"Proxy-module" is nothing more than “Software module” with the same “set” of functions of the “main” module, but the implementation of these functions does not come down to the execution of their functionality, but to delegating the execution of the corresponding function to either the corresponding main module (s), or some other functionality that implements this function. These functions of the “proxy-module” will be called “proxy-functions” (see the diagram in Fig. 8). This means that the “proxy module” must “know” (have a link to the main module) the existence of the “main” module (or a multitude of them, in the general case). It should be noted that the presence of “proxy-modules” is not a mandatory part of the system. Their presence, structure is determined directly by the problem being solved. Their presence is natural and most rational, certain technical requirements are imposed on them: - the functions of the “main” module are implemented, as described above;

- the so-called additional function is implemented and the data that is executed in the “main” module (this is necessary in order for the algorithm for loading the “proxy-module” and the “main” module to be absolutely identical). - manager)) the module does not distinguish between "basic" and "proxy-modules)>.

Explanations for the circuit of FIG. 9:

A solid arrow means that the value of the corresponding pointer (the place starting from the arrow) contains on the diagram the address of the corresponding function of the corresponding module, for example, Pointer 1 of the line M contains the address of function 1 of the “main”) module M. The principle of carrying out the invention

The method is implemented due to the fact that a certain software module generates in binary memory a binary matrix of pointers to the functions of the modules. These modules are assembled as separate files, with their subsequent loading into the executable program, so that when a function is called from module N, where K is the number of the function in the module, control is transferred to the function whose address is in the matrix in the Nth row, Kth column.

If during the use of a debugger or other error detection system it was found that the module and its corresponding file contain an error, this module is overloaded after making the necessary corrections to the source code of the algorithm, followed by translation / compilation of the source code. At the final stage, the previous version of the module is rebooted into a debugged new one, followed by testing.

At the first stage of the formation of a binary matrix in a software module, i.e. when the program (system) is started, loading of the “main” modules is performed. This means that there is a list of main modules according to which each module is loaded in accordance with the circuit shown in FIG. 11. This list is nothing more than an array of names of the “main” modules. How, where the specified list is located, as well as how the download is initiated, this method does not consider. This can be done in various ways.

After all the main modules are loaded, you can proceed directly to debugging the system. As previously noted in the classic software debugging scheme, when any or malfunctions, for the developer, the phases of rebuilding and restarting the system are inevitable.

This method avoids the restart and / or rebuild phase of the system. This saves time. This is achieved due to the fact that if an error is detected, then it is done:

1. Localization of the problem. The result of the analysis should be a conclusion about which functions of which module should be changed to achieve a positive result. This operation can be performed by various methods: a. Analysis of the external data of the system, such as: error messages, logs, records in the database, etc. b. Reproduction of a problem in an environment where the “black box” can be started in debug mode. 2. Next, the module containing the error is reloaded. (The system itself does not restart at the same time.) The reboot algorithm matches the boot algorithm shown in the diagram shown in FIG. 11. Schematically, the result of loading the module with the number M is shown in the diagram shown in FIG. 9. At the same time, it can act as the “main” module as itself

The "main" module, and the corresponding "proxy-module"; In this regard, we will distinguish between two ways to reboot:

Method A:

By making the necessary corrections to the source code of the “basic” algorithm of the module. o Translation / Compilation of the “main” module. o Rebooting the “old” module to the “new” “main” module (see diagram in Fig. 11) o In this case, the “new” main module is not required perform all the functions of the main module. In the general case, only those functions that need a reboot can be performed. It also means that the “new” core modules, in the general case, can be assembled in a multitude. Method B:

Rebooting the “main” module containing the error to the corresponding “proxy-module”. but. Schematically, the result of loading the module with the number M is shown in FIG. 10 b. It should be noted that: i. the identifier of “proxy-module” coincides with the identifier of the corresponding “main” module, this is necessary in order to set pointers to functions in the global matrix

“Basic” module to pointers to the functions of the corresponding “proxy-module” ii. the corresponding main module must be initialized with a pointer to the global matrix. This is necessary so that at the moment when control is transferred to the functions of the main module, all calls to the functions of the algorithm would be correctly delegated to the calls of those functions, the pointers to which are currently in the matrix. iii. The proxy module is not required to perform all the functions of the main module. In the general case, only those functions that need a reboot can be performed. iiii. For each “main” module, there can be one or many “proxy modules” with. At the same time, the “proxy function” algorithm in the “proxy” is implemented in such a way that: (Fig 6.) i. the algorithm checks for the presence of a script file in the "known" file system directory. ii. if it exists, it executes the file using the “script-machine” (interpreter). iii. if there is no file, the corresponding function of the “main” module is performed. d. The file (s) of functions whose algorithm is to be changed are laid out in a predetermined directory of the file system. Thus, when the corresponding proxy function is called, it will execute it using the appropriate script machine if there is a script file, if the file is not found, the corresponding function of the “main model” will be called. In general, the whole “function” algorithm will completely depends on the specific task, and in general it is impossible to determine which algorithm will be used. 3. After the module is rebooted and the functionality of the necessary nodes is retested.

With this development approach, the technical result is the developer’s time spent on debugging, since when: • using Method A, the system did not need to be restarted,

• when using Method B, the system did not need either rebuilding or restarting.

Claims

FORMULA

1. A method for assembling (assembling) software, characterized in that a certain program module generates in binary memory a binary matrix of pointers to the functions of the modules, which are collected as separate files, followed by their loading into the executable program, so that when the function is called from module N, where K is the number of the function in the module, control is transferred to the function whose address is in the matrix in the Nth row, Kth column, and the module and the corresponding file containing the error are overloaded after entering the necessary corrections to the source code of the algorithm, followed by compilation and reloading of the previous version of the module to a debugged new one, followed by testing.

2. The method according to p. 1, characterized in that the module containing the error is replaced by another module whose corresponding functions are set in such a way that when they are executed, a decision is made about which function of the module (previously or newly assembled) should be performed, or which script file that performs the corresponding function should be executed by the corresponding script machine (interpreter).