JPH04278632A - Software converting/reforming method - Google Patents

Abstract

PURPOSE:To improve the maintenance properties, the reliability and the reuse performance of software by attaining a method to convert the structure based on the inter-module coupling relation for a program consisting of plural modules. CONSTITUTION:An existing source program 5 analyzes the constitution, the structure, the variable, etc., of a module based on a module analyzing program 2 and then converts and reforms these constitution, structure and variable, etc., based on a coupling degree conversion program 3. Therefore the inter- module coupling degree is improved to a program already produced with a simple operation. Then the independence is secured for each module. As a result, the maintenance properties, the reliability and the reuse performance can be improved for the program itself.

Description

[Detailed description of the invention]

0001

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software-assisted conversion and reconfiguration method for program variable structures and processing structures.

0002

BACKGROUND OF THE INVENTION A conventional method is described by Glenford J.
As discussed in "Composite/Structured Design of Software" by John Myers, translated by Yoshihisa Kunitomo and Takeo Ito,
It only defines the concepts in the design of the created software. Also, from the viewpoint of converting and reconfiguring software, as described in Japanese Patent Application Laid-Open No. 1-55643, the scope of influence within the program is investigated for each variable, and it is defined in the storage device and the user can make inquiries. It is only intended to inform the public of the scope of influence. Examine the relationships between modules in a program, convert and reconfigure those relationships,
I could not find any literature on how to ensure the consistency of variables used in each, or how to preserve functionality.

0003

[Problems to be Solved by the Invention] The above-mentioned prior art does not take into consideration the automation of variable conversion, and has the problem of low reliability regarding consistency due to variable conversion and reconfiguration during user operations. there were.

[0004] An object of the present invention is to provide a method for ensuring consistency of variables between modules or preserving functionality.

Another object of the present invention is to support a composite design method, obtain a good modular structure for software, and improve the productivity, reliability, or performance of software. There is a particular thing.

[0006]

[Means for solving the problem] In order to achieve the above objective, the ripple effect on other modules due to conversion/reconfiguration of a certain variable is investigated, and a module that generates a ripple effect from the viewpoint of preserving functions according to the converted rules. All processing related to variables is automatically corrected.

[0007] In order to achieve the other object mentioned above, the degree of inter-module coupling between modules within a program is automatically converted.

[0008]

[Operation] According to the present invention, on the premise of preserving the functions of the software, a good module structure is obtained for the software, and the productivity, reliability, and performance of the software are improved. It is. Also,
This also extends the life cycle of software.

[0009]

[Example] First, the degree of coupling between modules (module
An overview of coupling) will be explained below. The degree of inter-module coupling defines the degree of relationship and dependence between the plurality of modules constituting a program. The concept of inter-module coupling is discussed in Glenford J. My
The concept is discussed on pages 39 to 80 of "Composite/Structured Design of Software" by Yoshihisa Kunitomo and Takeo Ito, translated by Yoshihisa Kunitomo and Takeo Ito.

A module is a collection of executable program instructions that may be independently compiled. The calling relationship between modules will be explained based on FIG. 2. In FIG. 2, module B (22),
D (24) is called by module A (21). Module C (23) is called by module B. In this case, modules B, C, and D are said to be "dependent" on module A, and modules B and D are said to be "dependent" on module A.
It is said to be ``directly dependent'' on. Also, module A,
B is said to be a "superior module" to module C.
Module B is said to be a "direct upper module" of module C. From now on, we will explain using the above definition.

[0011] The degree of coupling between modules targeted this time is:
Based on the depth of the relationship between modules, they are classified into the following five stages. Here, the modules will be explained in descending order of the degree of coupling between modules.

FIG. 3 shows a common coupling.
FIG. (
31) represents a "variable with a structure" that is common and external to the modules (32) that make up the program. Common coupling is characterized in that data is exchanged between modules by using an external variable with a structure as a common variable between the modules in two or more modules that have a control relationship.

FIG. 4 shows an external join (external c
FIG. 2 is a diagram conceptually representing a program of "upling". (41) is a module (42) that constitutes a program.
) represents a global variable that has no common external structure. External coupling is characterized by passing data between modules by using unstructured global variables (external variables) as common variables between modules in two or more modules that have a control relationship. shall be.

If you look at these common connections and external connections differently, they are divided in terms of processing content, but processing groups that exist within the same program use the same variable area, that is, processing groups. When viewed as a module, it can be seen as a program that includes modules and variable areas. Also, when module A includes module B and module B uses a variable of module A, this is due to the inclusion relationship.
It can be considered a common join or an outer join.

FIG. 5 shows the control coupling (control co
FIG. Control coupling controls the logic of a module by passing control information as an argument when transferring control in a module that has two or more control relationships. Taking the figure as an example, the controlled module (51) is the upper module (
Based on the control argument (53) issued by (52), multiple procedures (54) in the module are executed by the control procedure (54).
The operation is controlled by selection 55).

FIG. 6 shows the stamp co
FIG. (61) represents an upper module, (62) represents an argument with structure, and (63) represents a module controlled by (61). Stamp binding is characterized in that data is exchanged between modules in two or more modules that have a control relationship using variables having a structure.

FIG. 7 shows data coupling
FIG. 2 is a diagram conceptually representing a program of . (7
1) represents an upper module, (72) represents an argument without structure, and (73) represents a module controlled by (71). Data coupling is characterized in that, in modules that have a control relationship between two or more, data is exchanged between modules only by passing parameters of data elements.

The independence of modules increases as the degree of coupling between modules becomes weaker. Therefore, in the example of coupling degree mentioned above, common coupling has the lowest module independence, outer coupling, control coupling, stamp coupling, and data coupling have higher module independence in this order, and in the reverse order, the degree of inter-module coupling is the lowest. become weak. As the independence of modules increases, the reliability, maintainability, module reusability, and ease of modification of the entire software including these modules improves.

Next, an embodiment of the software conversion and reconfiguration method according to the present invention will be described. FIG. 1 shows a configuration diagram of an apparatus implementing the present invention. "Software conversion processor"
The "module analysis program" (2) in the program memory that operates in (1) receives the identifier of the module that will be the center of software conversion and reconfiguration from the "input device section" (4), and Existing source program" (5) is analyzed and information about modules, such as external variables, inter-module dependencies, and degree of coupling between modules, is stored in Table A (7) and Table B (8).
), is stored in table C (9), and the processing is passed to the "coupling degree conversion program" (3) in the program memory, which also operates on the "software conversion processor" (1). Here, based on the information in table A (7), table B (8), and table C (9), the main module of the existing source program is determined by the module specified by the "input device section" (4). It is converted into an inter-coupling degree and stored in the "new source program" (6). The above operations convert and reconfigure the software.

In the embodiment described below, mutual conversion of the degree of coupling between modules is the object of processing. Hereinafter, the term "coupling degree" refers to the degree of coupling between modules, and the term "conversion" refers to the conversion of the degree of coupling between modules. Note that software using the C language will be used here, and modules will be described as functions.

1. Analyzing the module Here, the "module analysis program" shown in FIG. 1(2) will be explained.

The degree of coupling between modules is determined based on the above-mentioned characteristics. However, when multiple degrees of coupling are determined simultaneously between certain modules, it is assumed that the degree of coupling is the strongest. The analysis procedure is shown below.

FIG. 8 is an operational flowchart of the step of analyzing a module in the "module analysis program" shown in FIG. 1(2). First, the "existing source program" shown in Figure 1 (5) is analyzed, and externally defined variables used by all modules included in the program are extracted by lexical analysis and stored in table A (8
01), the call sections of other modules are similarly extracted and stored in table B (802). Next, "convert"
It is checked whether there are any external variables used by the specified module (803). If not, the process moves to the judgment unit for stamp combination or data combination (82
1). If so, check whether it is used by another module based on the information in Table B (80
4). If it is not used, the process is moved to the judgment unit for stamp combination or data combination (822
). If it has been used, the external variable is made a common variable and it is checked whether it has a structure (805). If the module does not have a structure, the module that uses the common variable and the module that is specified as "conversion" are determined to be externally connected, and that information is stored in table C (8
06). If the module has a structure, it is determined that the module using the common variable and the module for which "conversion" has been specified are commonly connected, and the information is stored in table C (807). Based on the information of the calling section of the module in Table B, it is checked whether there is a module related to the module designated for "conversion" (808). If there is none, the process ends (823). In some cases, in order to directly check the relationship with the upper module, you can check whether the argument of the module specified with "conversion" has a structure (
809). If the module does not have a structure, it is determined that the module is directly connected to the upper module, and
The information is stored in table C (810). If the module has a structure, it is determined that the module is stamp-bound directly with the upper module, and that information is stored in Table C.
(811). Next, in order to check the relationship between that module and dependent modules, it is checked from the information of the calling part of the module in table B whether the module call argument for that module has a structure (812). If the module does not have a structure, it is determined that this module and the directly dependent module are data-linked, and the information is stored in table C (813). If the module has a structure, it is determined that this module and the directly dependent module are stamp-connected, and the information is stored in table C (814).

Here, a specific example of a program using the C language will be given. Note that in this example, the module to which "conversion" is specified is "main."

First, the program example shown in FIG. 9 will be explained as the existing source program shown in FIG. 1(5). The source program is analyzed, and information about the variable "a" (94) defined in the common area between modules is stored in table A. Based on the information in Table A, for each module, externally defined variables used by that module and callers of other modules are extracted and stored in Table B. Table B contains "main" (91
), “phone_check” (92), “addr
_put" (93) is stored. Next, a search is made from Table B for a module that uses the external variable "a" used by the module "main" for which "conversion" is specified. The found “phone_c”
As for "heck", "a" has a structure, so
It is determined that there is a common bond. From the information in table B:
Search for other modules related to "main". Since the found "addr_put" is not a common join or an outer join, it is assumed to be a stamp join or a data join. Therefore, the target module “m”
ain”. Here, since the argument "b" is a structure, the module "main" and the module "
addr_put” is determined to be a stamp combination. The determination result is stored in table C. FIG. 10 shows the contents of the table stored in this process.

Next, the program example shown in FIG. 11 will be explained using the existing source program shown in FIG. 1(5). Analyze the source program and check the variables "name" (114) and "address" defined in the common area between modules.
s" (115) and "phone" (116) are stored in table A. Based on the information in table A,
For each module, externally defined variables used by that module and calling parts of other modules are extracted and stored in table B. Table B has "
main” (111), “phone_check” (
112), information about "addr_put" (113) is stored. Next, select the external variable "name" used by the module "main" specified for "conversion".
, "address", and "phone" are searched from table B. Searched for
phone_check”, its common variable “p
Since "hone" has no structure, it is determined that it is an outer join. Search for other modules related to "main" from the information in table B. Searched for
addr_put" is not a common join or an outer join, so it is considered to be a stamp join or a data join. Therefore, the argument to the target module "main" is further examined. Here, since the argument "b" is a structure,
Module “main” and module “addr_pu”
t'' is determined to be a stamp combination. The determination result is stored in table C. FIG. 12 shows the contents of the table stored in this process.

Next, the program example shown in FIG. 13 will be explained using the existing source program shown in FIG. 1(5). Analyze the source program and search for variables defined in common areas between modules. Since nothing is stored in table A, the calling parts of other modules are extracted for each module and stored in table B. Table B contains "main" (131
), “phone_check” (132), “add
r_put” (133) is stored. Next, other modules related to "main" are searched from the information in table B. The ``phon'' that was found
Since "e_check" and "addr_put" are not common joins or outer joins, they are considered to be stamp joins or data joins. Therefore, the argument to the target module "main" is further examined. Here, "phon"
e_check”, the argument “a” is a structure, so the module “main” and the module “pho
ne_check” is determined to be a stamp combination. Also, between "addr_put", the argument "b" is a structure, so the module "main" and the module "
addr_put” is determined to be a stamp combination. The determination result is stored in table C. FIG. 14 shows the contents of the table stored in this process.

Next, the program example shown in FIG. 15 will be explained using the existing source program shown in FIG. 1(5). Analyze the source program and search for variables defined in common areas between modules. Since nothing is stored in table A, the calling parts of other modules are extracted for each module and stored in table B. Table B contains "main" (151
), “phone_check” (152), “add
r_put" (153) is stored. Next, other modules related to "main" are searched from the information in table B. The ``phon'' that was found
Since "e_check" and "addr_put" are not common joins or outer joins, they are considered to be stamp joins or data joins. Therefore, the argument to the target module "main" is further examined. Here, "phon"
Since the argument "phone" has no structure between the module "main" and the module "phone_check", it is determined that the module "main" and the module "phone_check" are data coupled. Also, between “addr_put”, the argument “d
Since "data_name" and "data_phone" do not have a structure, the module "main" and the module "addr_put" are determined to be a stamp combination. The determination result is stored in table C. FIG. 16 shows the contents of the table stored in this process.

2. Converting the coupling degree between modules Here, the "coupling degree conversion program" shown in FIG. 1(3) will be explained.

[0030] Here, it is assumed that the degree of coupling of the module to be converted has been determined using the method described in "1. Analyzing the module". Here again, a specific example using a program using the C language will be given. At the same time, in this example as well, the module for which "conversion" is specified is set as "main", as in "1. Analyzing modules". Note that the "determination process described above" here refers to determination using the method of "1. Analyze the module."

2.1 Convert common join to outer join. The conversion procedure is shown below.

FIG. 17 is an operational flowchart showing the step of converting a common connection into an outer connection in the "module analysis program" shown in FIG. 1(4). In the above judgment process, among the variables stored in table A, variables that have the structure used by the module to be converted are targeted for decomposition, and each component that makes up that structure is stored in table D as element variables. Store (1701). table D
The variables stored in table B are
It is checked that variables with the same name do not exist in all modules that use variables having the structure to be decomposed stored in (1702). At this time, if a variable with the same name exists, that variable name is changed and stored in table D (1
703), returns to the process (1702), and checks again to see if a variable with the same name does not exist. After checking the variables with the same name (1710), create a definition part for each variable stored in table D (1704), and create a definition section for each variable stored in table D. The definition part of the variable is deleted, and the reference part of the variable is rewritten according to Table D (1705).

Here, a specific example of a program using C language will be given. Note that here, the common combination program example shown in FIG. 9 is assumed to be the existing source program shown in FIG. 1 (5) which is the source of conversion.

[0034] In the above-mentioned determination process, table C contains "ma
"in" and "phone_check" are a common combination, and "a" is stored as their common variable. Here, each component of the structure of the variable "a" is defined as an element variable, "name", "address"
s" and "phone" are stored in table D. Here, the contents of table D are shown in FIG. The variables stored in table D are the modules “main” and “pho”.
Since there is no variable with the same name in "ne_check", each variable "name" stored in table D,
Definition parts are created for "address" and "phone", the definition part of the common variable "a" is deleted, and for the reference part, for example, "a.name" is rewritten as "name" according to Table D. The converted program is shown in FIG. 11.

2.2 Convert common joins to stamp joins. The conversion procedure is shown below.

FIG. 19 is an operation flowchart showing the step of converting a common connection into a stamp connection in the "module analysis program" shown in FIG. 1(4). In the above judgment process, based on the information stored in Table C, the external variables used by the module to be converted are set as common variables, and the common variables are added to the topmost module of the module that uses them. A definition section is created using as an internal variable (1901). For other modules, interface sections and definition sections are created using the common variables as call arguments (1902). Also,
For common variables between modules, the definition part is deleted (1903).

Here, a specific example of a program using the C language will be given. Note that here, the common combination program example shown in FIG. 9 is assumed to be the existing source program shown in FIG. 1 (5) which is the source of conversion.

In the above-mentioned determination process, table C contains "ma
in” and “phone_check” are a common combination, their common variable is “a”, and “main” is “ph”.
one_check" is stored as a direct upper module. A definition section is created for the common variable "a" in the upper module "main". And its directly dependent module “phone_che”
Create an interface part and a definition part using the call argument of the "ck" module as the common variable. Furthermore, regarding the common variable "a" between modules stored in table C, its definition part is deleted. here,
The converted program is shown in FIG.

2.3 Convert outer join to data join. The conversion procedure is shown below.

FIG. 20 is an operational flowchart showing the step of converting an external link into a data link in the "module analysis program" shown in FIG. 1(4). In the above judgment process, from the information stored in table C, the external variables used by the module to be converted are set as common variables, and the common variables are stored in the module that is the highest level of the module that uses them. Then, a definition section is created using it as an internal variable (2001). For modules for which no definition section has been created, an interface section and a definition section are created using the external variable as a call argument (2002). Finally, for common variables between modules, the definition part is deleted (2003). Here, a specific example using a program using C language will be given. Note that here, the external link program example shown in FIG. 11 is assumed to be the existing source program shown in FIG. 1 (5) that is the source of the conversion.

[0041] In the above-mentioned determination process, table C contains "ma
in" and "phone_check" are outer joins, and their common variable is "phone", and "main"
is stored as a direct upper module of "phone_check". The upper module “ma”
A definition section is created for the common variable "phone" in "in". And its directly dependent module “p
Create an interface part and a definition part by using the call argument of the "hone_check" module as the common variable. Furthermore, regarding the common variable "phone" between modules stored in table C, its definition part is deleted. Also, "name", "address"
Since "s" is used only in "main", its definition section is created in "main". Finally, "name" and "a" defined in the common area
ddress" and "phone", their definition parts are deleted. Here, the converted program is shown in FIG.

2.4 Convert stamp binding to data binding. The conversion procedure is shown below. Figure 21 is Figure 1
It is an operation flowchart showing the step of converting a stamp combination into a data combination in the "module analysis program" of (4). In the above-described determination process, each component of the structure of the variable having the structure used as an argument is stored in table D as an element variable based on the information stored in table C (2101). Among the variables stored in table D, undetermined element variables are extracted and used as the relevant variables (2102). Here, if the element variable could not be extracted (2103), (21
21), delete the definition part of the original common variable (2110
) Terminate processing. Check that variables with the same name do not exist in all modules that use the variable (
2104). At this time, if a variable with the same name exists, the variable name is changed and stored in table D (2105),
Returning to the process (2104), it is checked again to see if a variable with the same name does not exist. After checking the variables with the same name (2122), from the module related to the variable,
The module at the highest level in the control relationship is searched for in the source program based on the information in table B (2106), and a definition section is created in the highest level module with the variable as an internal variable (2107). Then, define the variable as an argument for related modules other than the top level (210
8). Then, the reference portion of the variable in the related module is rewritten (2109), and the process returns to step (2102).

Here, a specific example of a program using the C language will be given. Note that here, the program example for combining stamps, shown in FIG. 13, is assumed to be the existing source program shown in FIG. 1(5), which is the source of conversion.

[0044] In the above-mentioned determination process, table C contains "ma
in” and “phone_check” are stamp joins, have “a” as their argument, and “main” is “ph
one_check" is stored as a direct upper module. Furthermore, "main" and "addr_p"
ut" is also a stamp combination, and has "b" as its common variable, and "main" is stored as a direct upper module of "addr_put". Here, each component of the structure of the variable "a" is defined as an element variable, "name", "address", "ph".
one” is stored in table D. Here, table D
The contents are shown in FIG. The variables stored in table D are the modules "main" and "phone_che".
Since there is no variable with the same name in "ck", each variable "name" and "addre" stored in table D
Create definition parts for "ss" and "phone", delete the definition part of the common variable "a", and for the reference part,
For example, if "a.name" is specified according to table D, "nam
Rewrite it as "e". A similar operation is performed for the variable "b" which has a structure. The converted program is shown in FIG. 15.

2.5 Convert control binding to data binding. The conversion procedure is shown below. However, processing is performed on the premise that the module for which the user has specified conversion is a control connection.

FIG. 23 is an operational flowchart showing the step of converting control connections into data connections in the "module analysis program" shown in FIG. 1(4). First, one of the arguments of the controlled module is extracted and used as the variable (2301). Here (2302)
, if the argument could not be extracted (2311), the process ends. Next, check whether the variable is used only in judgment statements (2303), and if not (2312)
) Return to the process (2301), and if so, check whether the process after the decision branch is contradictory (2304). Here, if there is no conflict, return to the process (2301), and if there is a conflict, the variable is regarded as a control argument, necessary arguments are found for each procedure, and each procedure is converted into a function (23
05), provide an entrance. Then, the common process is converted into a common function (2306), and the calling side also divides the calling part into each controlled process based on the information of the control variables, and modifies the function calling part (2307).

Here, a specific example of a program using the C language will be given. Note that here, the program example of control coupling, shown in FIG. 24, is assumed to be the existing source program shown in FIG. 1(5), which is the source of the conversion.

Argument “sw” of the controlled module
is extracted as the relevant variable. This argument "sw" is used only in the judgment statement "switch", and since each branching control in the "case" statement is contradictory, it is regarded as a control argument. Then, for each procedure, extract the necessary arguments, that is, the arguments used, use them as arguments, convert the processing after each branch into a function, and provide an entry point. Then, the variables used in each procedure are examined using lexical analysis, etc., and the definitions of the variables are transferred. Then, the common processing is converted into a common function, and the calling side also divides the calling part into each controlled process based on the information of the control variables, and modifies the function calling part. Here, the converted program is shown in FIG. 25.

2.6 Convert data join to outer join. The conversion procedure is shown below.

FIG. 26 is an operation flowchart showing the step of converting a data connection into an external connection in the "module analysis program" shown in FIG. 1(4). In the above judgment process, one argument used in the interface between the module to be converted and the related module is extracted from the information stored in table C (260).
1). If there are no arguments (2602), the process ends (
2610). When the extraction argument is an external variable, check that there is no existing external variable in table A with the same name (2611), create a definition part outside the module, and delete the original definition part. (2605). If there is a variable with the same name in table A, use a unique name (26
04) Check again. Then, for modules that have a common variable, the interface section and reference section of the module that used the variable as a call argument are corrected (2606). When finished, repeat the same operation for other arguments.

Here, a specific example of a program using the C language will be given. Here, the example program for data combination shown in FIG. 15 is assumed to be the existing source program shown in FIG. 1 (5) which is the source of the conversion.

[0052] In the above-mentioned judgment process, table C contains "ma
in” and “phone_check” are data joins,
It has "phone" as its argument, and "main" is stored as a direct upper module of "phone_check". "main" and "phone_c"
The argument "phone" used in the interface with "heck" is extracted, and it is searched based on the information in Table B to see if it is used in any related module. I can't find it, so next I change "phone" to "ma".
In order to treat this as a common variable for "in" and "phone_check", variables with the same name are checked based on the information in table A. Since there is no variable with the same name, "phone" is defined as an external variable. For a module that has a common variable "phone", delete the interface section and definition section that used "phone" as a call argument. Finally, the “main”, “phone_chec”
Modify the ``phone'' reference part of ``k'' to refer to an external variable. When finished, repeat the same operation for other arguments. Here, the converted program is shown in FIG. 27.

2.7 Convert data binding to stamp binding. The conversion procedure is shown below. Figure 28 shows Figure 1.
It is an operation flowchart showing the step of converting a data combination into a stamp combination in the "module analysis program" of (4). In the above judgment process, if there are multiple arguments used in the interface between the module to be converted and the related module from the information stored in table C, the arguments are extracted (2801
). If there is no corresponding interface, the process ends (2810). In some cases (2810), the extracted arguments are synthesized as arguments with structure (28
03). If the argument created by combining here (2804) and a variable with the same name exist in the related module, the name of the argument is changed to be unique (2
805). A definition section is created for the argument thus created, and the original definition section is deleted (2806). The reference part of the manipulated argument is corrected (2807). When finished, repeat the same operation for the other interface sections.

Here, a specific example of a program using the C language will be given. Here, the example program for data combination shown in FIG. 15 is assumed to be the existing source program shown in FIG. 1 (5) which is the source of the conversion.

In the above-mentioned determination process, table C contains "ma
"in" and "addr_put" are data joins, and their arguments are "data_name" and "data_pho".
ne", and "main" is stored as being a directly upper module of "addr_put". Here, the variables “data_name” and “data_p
``hone'' has a structure and gives it a unique name as a variable with a structure, ``a''. Related modules, "main" and "addr_put" contain "a"
”, but if there is a variable called “a”, change “a” to another name. Finally, the “data” in “main” and “addr_put”
_name”, the reference part of “data_phone” is changed to “data_name” and “a.data_name”.
, “data_phone” to “a.data_pho”
Correct it as "ne". When finished, repeat the same operation for the other interface sections. The converted program is shown in FIG. 29.

2.8 Convert outer joins to common joins. The conversion procedure is shown below.

FIG. 30 is an operation flowchart showing the step of converting an external connection into a common connection in the "module analysis program" shown in FIG. 1(4). In the above judgment process, according to the information stored in table C, if there are multiple external variables that are used as common variables between modules (3001), variables that have a structure with those external variables as element variables. (3002). If a variable with the same name exists in the related module (3003), the variable name is changed to be unique (3004). Then, a definition part of the synthesized variable is created, and the definition part of the original element variable is deleted. Then, modify the reference part of the variable manipulated here.

Here, a specific example of a program using the C language will be given. Note that here, the external link program example shown in FIG. 11 is assumed to be the existing source program shown in FIG. 1 (5) that is the source of the conversion.

In the above-mentioned determination process, table C contains "ma
in” and “phone_check” are outer joins, and their common variables are “name”, “address”,
There is "phone" and "main" is "phone_
"check" is stored as a direct upper module of "check". Here, the variables "name" and "address"
, "phone" have a structure, and give a unique name as a variable with structure to "a". Related modules, "main" and "phone_check"
” does not have the name “a”, but if here, “a”
”, replace “a” with another name. Finally, "main" and "phone_chec"
The reference parts of “name” and “phone” in “k” are changed to “
name” to “a.name”, “phone” to “a”
．． ``phone''. The converted program is shown in FIG. 31.

2.9 Convert stamp joins to common joins. The conversion procedure is shown below.

FIG. 32 is an operation flowchart showing the step of converting a stamp combination into a common combination in the "module analysis program" shown in FIG. 1(4). In the above-described determination process, one argument having a structure used in the interface between the module to be converted and the related module is extracted from the information stored in Table C (3201). If there is none (3202), the process ends. In some cases, when using an external variable as an extraction argument, check that there is no existing external variable in table A with the same name (3203), create a definition section outside the module, and replace the original The definition section is deleted (3205). Then, for modules that have a common variable, modify the interface section and reference section of the module that used that variable as a call argument (3206
). If there is a variable with the same name in table A, make it a unique name (3204) and check again. Once processing is complete, repeat the same operation for other arguments.

Here, a specific example of a program using the C language will be given. Note that here, the program example for combining stamps, shown in FIG. 13, is assumed to be the existing source program shown in FIG. 1(5), which is the source of conversion.

[0063] In the above-mentioned determination process, table C contains "ma
in” and “phone_check” are stamp joins, and have a variable “a” with structure as an argument, and “ma
``in'' is stored as being a directly upper module of ``phone_check''. Also, "main" and "
For ``addr_put'', both are stamp combinations, and there is a variable ``b'' with a structure as an argument, and ``ma
``in'' is stored as being a direct upper module of ``addr_put''. First, it is searched based on the information in table B to see if "a" is used in the related module. Since there is nothing else, next change "a" to "m"
ain”, “phone_check”, “addr_
In order to treat it as a common variable for "put", check for variables with the same name from the information in table A. Since there is no variable with the same name here, "a" is defined as an external variable. Common variable “
For a module with "a", delete the interface section and definition section that used "a" as a call argument. Finally, the “main”, “phone_
Modify the ``phone'' reference part of ``check'' to reference an external variable. The same operation is performed for "b" as well. Here, the converted program is shown in FIG. 33.

2.10 Convert data binding to control binding. The conversion procedure is shown below. However, processing is performed on the premise that the module for which the user has specified conversion is data binding.

FIG. 34 is an operation flowchart showing the step of converting a data connection into a control connection in the "module analysis program" shown in FIG. 1(4). First, add branch instructions to multiple modules on the controlled side (3
401), and combine them into one module as a process that is contradictory after branching (3402). Next, the sum of the invocation arguments held by the plurality of modules that are the basis of the resulting composite module is calculated and set as the argument of the composite module (3403). Furthermore, a control argument for selecting processing by branching is set (3404
). Then, the common call modules of the plurality of modules that are the source of the synthesis module are synthesized into the synthesis module as a common processing section (3405). In this way, the sum of the variables in each of the synthesized modules is calculated and set as the variable of the synthesized module (3406). lastly,
The calling section of the calling module is set to match the new synthesis module (3407).

Here, a specific example of a program using the C language will be given. Note that here, the data combination program example shown in FIG. 25 is assumed to be the existing source program shown in FIG. 1 (5) that is the source of the conversion.

First, the module “man” on the controlled side
manager_1” (2502), “manager_2”
(2503), “manager_3” (2504),
“manager_4” (2505), “manage
r_d" (2506), a "switch" statement is added, and each module is synthesized as a contradictory process after the "case" statement. Then, the sum of the arguments each module had at the time of invocation is calculated, and the arguments of the composite module are ``name'' and ``addre''.
ss”, “weight”, “tall”, “value”
Set "e". Furthermore, a control argument "sw" for selecting a process by the "switch" branch is set. Then, the common call module "common_man" (2507) of each original module is incorporated into the synthesis module as a common processing section. In this way, take the sum of the variables in each synthesized module,
Set as a variable in the synthesis module. Finally, change the caller of the calling module to the new composition module name "
``manager'' and the control argument ``sw''. Here, the converted program is shown in FIG. 35.

[0068] These steps of converting the degree of coupling between modules are not always performed one step after the "module analysis program" shown in FIG. 1 (4).
Sometimes it works by combining multiple steps.

Note that this method is not limited to the C language, but can be implemented with any other programming language or specification that has the concept of a module.

[0070]

According to the present invention, the degree of coupling between modules can be increased with a simple operation for an already created program, and the independence of each module can be ensured. This improves the maintainability and reliability of the program itself.

[Brief explanation of the drawing]

FIG. 1 is a configuration diagram of an apparatus implementing the present invention.

FIG. 2 is a diagram showing calling relationships between modules.

FIG. 3 is a diagram conceptually representing a common connection program.

FIG. 4 is a diagram conceptually representing an external join program.

FIG. 5 is a diagram conceptually representing a control connection program.

FIG. 6 is a diagram conceptually representing a program for combining stamps.

FIG. 7 is a diagram conceptually representing a data combination program.

FIG. 8 is an operation flowchart of a step of analyzing a module in the module analysis program of FIG. 1(2).

FIG. 9 is an example of a common connection program in C language.

FIG. 10 is a configuration diagram of a table created as a result of analysis of the program of FIG. 9 in the step of analyzing the module of FIG. 8;

FIG. 11 is an example of an outer join program in C language.

FIG. 12 is a configuration diagram of a table created as a result of analysis of the program in FIG. 11 in the step of analyzing the module in FIG. 8;

FIG. 13 is an example of a program for combining stamps in C language.

FIG. 14 is a configuration diagram of a table created as a result of analysis of the program in FIG. 13 with respect to the module in FIG. 8;

FIG. 15 is an example of a data combination program in C language.

FIG. 16 is a configuration diagram of a table created as a result of analysis of the program in FIG. 15 in the step of analyzing the module in FIG. 8;

FIG. 17 is an operation flowchart showing a step of converting a common bond to an outer bond in the degree-of-coupling conversion program of FIG. 1(3).

FIG. 18 is a table configuration diagram created in the step of converting the degree of coupling between modules in the program of FIG. 9;

FIG. 19 is an operation flowchart showing a step of converting a common bond into a stamp bond in the bond degree conversion program of FIG. 1(3).

FIG. 20 is an operation flowchart showing a step of converting an outer join to a data link in the degree of connectivity conversion program of FIG. 1(3).

FIG. 21 is an operation flowchart showing a step of converting a stamp connection to a data connection in the connection degree conversion program of FIG. 1(3).

22] FIG. 22 is a table configuration diagram created in the step of converting the degree of coupling between modules in the program of FIG. 13. [FIG.

FIG. 23 is an operation flowchart showing a step of converting a control connection into a data connection in the degree of connection conversion program of FIG. 1(3).

FIG. 24 is an example of a control connection program in C language.

FIG. 25 is a program obtained by converting the program of FIG. 24 from control coupling to data coupling in the step of converting the degree of coupling between modules.

FIG. 26 is an operation flowchart showing a step of converting a data connection to an outer connection in the degree of connection conversion program of FIG. 1(3).

27] FIG. 27 is a program obtained by converting the program of FIG. 15 from data binding to external binding in the step of converting the degree of coupling between modules.

FIG. 28 is an operation flowchart showing a step of converting a data bond to a stamp bond in the bond degree conversion program of FIG. 1(3).

FIG. 29 is a program obtained by converting the program of FIG. 15 from data binding to stamp binding in the step of converting the degree of connectivity between modules.

FIG. 30 is an operation flowchart showing a step of converting an outer bond to a common bond in the degree-of-coupling conversion program of FIG. 1(3).

31] FIG. 31 is a program obtained by converting the program of FIG. 11 from external coupling to common coupling in the step of converting the degree of coupling between modules.

FIG. 32 is an operation flowchart showing a step of converting a stamp bond to a common bond in the bond degree conversion program of FIG. 1(3).

FIG. 33 is a program obtained by converting the program of FIG. 11 from stamp combination to common combination in the step of converting the degree of connection between modules.

FIG. 34 is an operation flowchart showing a step of converting a data connection into a control connection in the degree of connection conversion program of FIG. 1(3).

FIG. 35 is a program obtained by converting the program of FIG. 25 from data coupling to control coupling in the step of converting the degree of coupling between modules.

36] FIG. 36 is a program obtained by converting the program of FIG. 11 from external coupling to data coupling in the step of converting the degree of coupling between modules.

Claims (26)

[Claims] 1. An information processing system comprising a storage device for storing a source program made up of a plurality or a single module, and a data processing device for operating the storage device, wherein a module making up the source program is provided. and a step of converting and reconfiguring the source program by manipulating the structure of the module and the structure between the module and other modules related to the module. Software conversion/reconfiguration method. 2. An information processing system that includes a storage device that stores a source program composed of a plurality of modules or a single module, and a data processing device that operates the storage device, wherein all of the components that make up the source program are provided. Analyzing the structure of the module, and manipulating the structure of the module and the structure of other modules related to the module in every module to reduce the relationships among all the modules in the source program. A software conversion/reconfiguration method characterized by comprising the steps of converting/reconfiguring as follows. 3. The software conversion/reconfiguration method according to claim 1, wherein the step of converting/reconfiguring the source program converts the module into components by reducing relationships with other modules. 4. The software conversion method according to claim 1, wherein the step of converting and reconfiguring the source program improves the processing speed of the computer software by closely relating it to other modules. Reconstruction method. 5. A software conversion/reconfiguration method according to claim 1, wherein the target of analysis, conversion/reconfiguration is specification information instead of a source program. [Claim 6] The step of analyzing the structure of a module in claim 1 includes a step of extracting externally defined variables of the module, a step of extracting information about the module, and a degree of coupling between the modules based on the extracted information. A software conversion/reconfiguration method comprising the steps of determining. 7. The step of converting and reconfiguring the source program by manipulating the structure of the module and the structure between the module and other modules related to the module in claim 1 is an external definition of the module. A software conversion/reconfiguration method comprising: a step of decomposing the structure of variables; and a step of correcting logical contradictions between modules caused by the decomposition. 8. The step of converting and reconfiguring the source program by manipulating the structure of the module and the structure between the module and other modules related to the module in claim 1 is an external definition of the module. A software conversion/reconfiguration method comprising: a step of importing a variable as an internal variable of a related module; and a step of correcting a logical contradiction between modules that occurs due to the import. 9. A software conversion system characterized in that the externally defined variable of the module according to claim 8 has a structure.
Reconstruction method. [Claim 10] The step of converting and reconfiguring the source program by manipulating the structure of the module and the structure between the module and other modules related to the module in claim 1 is an interface between the modules. The process consists of a step of decomposing the structure of variables used in the process, a step of removing variables that become unnecessary due to the decomposition, and a step of correcting logical inconsistencies between modules that occur due to this series of operations. Characteristic software conversion/reconfiguration method. 11. An information processing system including a storage device for storing a source program composed of a plurality of modules or a single module, and a data processing device for operating the storage device, wherein In processing logic, the step of modularizing processes that are contradictory after branching, the step of converting the processes that were common processing logic in them into common functions, and correcting the contradictions in logic between modules that occur due to this series of operations. A software conversion/reconfiguration method characterized by comprising steps. 12. The step of converting and reconfiguring the source program by manipulating the structure of the module and the structure between the module and other modules related to the module in claim 1 is an external definition of the module. A software conversion/reconfiguration method characterized by comprising a step of synthesizing a structure of variables, and a step of correcting a logical contradiction between modules that occurs due to the synthesis. 13. The step of converting and reconfiguring the source program by manipulating the structure of the module and the structure between the module and other modules related to the module in claim 1 is an external definition of the module. The step of extracting a common internal variable other than a variable that is passed as an argument between multiple modules to the outside of the module as an externally defined variable between modules, and the logical contradiction between modules that occurs due to this extraction. A software conversion/reconfiguration method comprising the steps of: 14. The software conversion method according to claim 13, wherein the internal variables of the module have a structure.
Reconstruction method. 15. The step of converting and reconfiguring the source program by manipulating the structure of the module and the structure between the module and other modules related to the module in claim 1 is an interface between the modules. It consists of a step of composing the variables used in the module to give it a structure, a step of adding variables that become necessary through the compositing, and a step of correcting logical contradictions between modules that occur due to this series of operations. A software conversion/reconfiguration method characterized by: 16. An information processing system including a storage device for storing a source program composed of a plurality of modules or a single module, and a data processing device for operating the storage device, wherein In processing logic, the step of composing multiple modules as contradictory processes after branching, the step of composing common modules among them as common processing parts of the module after compositing, and the logic between modules generated by this series of operations. A software conversion/reconfiguration method comprising the steps of correcting inconsistencies in the above. 17. A software conversion/reconfiguration method comprising the method according to claim 6 or the method according to claim 7, characterized in that a common connection in the degree of connectivity between modules is converted into an external connection. 18. A software conversion/reconfiguration method comprising the method according to claim 6 or the method according to claim 8, characterized in that common connections of inter-module connectivity are converted into stamp connections. 19. A software conversion/reconfiguration method comprising the method according to claim 6 or the method according to claim 9, characterized in that an external connection of inter-module connectivity is converted into a data connection. 20. A software conversion/reconfiguration method comprising the method according to claim 6 or the method according to claim 10, characterized in that stamp connections of inter-module connectivity are converted into data connections. 21. By using the method of claim 11,
A software conversion/reconfiguration method characterized by converting a control connection of the degree of coupling between modules into a data connection. 22. A software conversion/reconfiguration method comprising the method according to claim 6 or the method according to claim 12, characterized in that an external connection of the degree of connectivity between modules is converted into a common connection. 23. A software conversion/reconfiguration method comprising the method according to claim 6 or the method according to claim 13, characterized in that stamp connections of inter-module connectivity are converted into common connections. 24. A software conversion/reconfiguration method comprising the method according to claim 6 or the method according to claim 14, characterized in that data connections of inter-module connectivity are converted to external connections. 25. A software conversion/reconfiguration method comprising the method according to claim 6 or the method according to claim 15, characterized in that data connections of inter-module connectivity are converted to stamp connections. 26. By using the method of claim 16,
A software conversion/reconfiguration method characterized by converting data connections of inter-module connectivity into control connections.