JP2013156802A - Module dependency extraction device, module dependency extraction method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To precisely extract dependency between modules in an environment with restrictions.SOLUTION: A source code acquisition unit 22 acquires source code from a source code storage unit 21. A target module designation unit 23 receives designation of a first module and a second module which are targets for dependency extraction. An operation condition designation unit 24 receives designation of an operation condition for executing a program. When the acquired source code is analyzed and the program corresponding to the acquired source code is executed by the designated operation condition, a common information extraction unit 251 extracts information which is commonly referable from the first module and the second module as information showing dependency between the first module and the second module, and a presentation unit 26 presents the extracted information.

Description

  The present invention relates to a module dependency relationship extraction device, a module dependency relationship extraction method, and a program.

  In general, the smaller the dependency between the modules that make up the software, the smaller the impact on other modules when modifying or deleting the function corresponding to the module (independence becomes higher), and the maintainability of the software. improves. Patent Documents 1 and 2 describe techniques for quantitatively measuring the degree of dependence between software modules.

  Specifically, Patent Document 1 describes that the degree of dependency is quantified and calculated for each type of dependency relationship for software (program) created in an object-oriented language. Further, Patent Document 2 describes that the dependency between modules is calculated based on the number of accesses to a global variable shared between modules even in a language that does not support object orientation such as C language. Has been.

  In Patent Documents 1 and 2, a program or source code is analyzed on the premise that there is no restriction on the range of data handled by software (program), and the dependence between modules is calculated. The degree of dependence between modules calculated by the methods described in Patent Documents 1 and 2 is effective as a measure of module independence when a new program is developed.

Japanese Patent Laid-Open No. 2000-215045 JP 2010-282441 A

  On the other hand, for example, there are cases where it is desired to port software (program) developed on a personal computer to an embedded device or the like. In this case, due to restrictions on the hardware resources of the embedded device, etc., development may be performed to limit the data handled by the program to be transplanted and delete functions that are not executed under the limitation. In such a case, the module corresponding to the function to be deleted cannot be easily deleted because it can be easily deleted depending on the range of data to be handled, and the program needs to be extensively modified along with the deletion. There are cases.

  Here, it is conceivable to determine whether or not this module can be easily deleted based on the dependency between modules calculated by the methods described in Patent Documents 1 and 2. That is, when the degree of dependence is high, it is judged that the deletion is difficult because the degree of independence is low, and when the degree of dependence is low, it is judged that the deletion is easy because the degree of independence is high. However, in the methods described in Patent Documents 1 and 2, when the data range handled by the program is restricted, the dependency between modules cannot be measured correctly. Therefore, as described above, when performing development to delete a function when porting an existing program to an embedded device or the like, the dependency between modules calculated by the methods described in Patent Documents 1 and 2 is expressed as a module. It was inappropriate to use it as a measure of independence.

  The present invention has been made in view of the above circumstances, and is a module dependency relationship extraction device that can accurately extract the dependency relationship between modules even when the data range handled by the program is limited. It is an object to provide a module dependency relationship extraction method and a program.

In order to achieve the above object, the module dependency extraction device of the present invention provides:
Source code acquisition means for acquiring the source code of the program;
Module designation means for accepting designation of a first module and a second module called from the first module from among the modules constituting the program;
An operation condition specifying means for receiving specification of an operation condition for operating the program;
When the source code is analyzed and the program is operated under the specified operating condition, information that can be commonly referred to from the first module and the second module is referred to as the first module in the first module. Dependency extraction means for extracting information indicating the dependency relationship of the two modules;
Presenting means for presenting information extracted by the dependency relationship extracting means;
It is characterized by providing.

  According to the present invention, the source code is analyzed according to the specified operating condition, and the dependency relationship between the modules is extracted. Therefore, even when the data range handled by the program is restricted, the dependency relationship between modules can be accurately extracted.

It is a figure which shows the physical structure of the module dependence relationship extraction apparatus which concerns on embodiment of this invention. It is a functional block diagram of the module dependence relationship extraction apparatus which concerns on embodiment of this invention. It is a flowchart for demonstrating operation | movement of a dependence relationship extraction process. It is a figure which shows the example of the source code used as analysis object. (A) is a figure which shows the structure of the module designated by the object module designation | designated part. (B) is a figure which shows the operation condition designated by the operation condition designation | designated part. It is a flowchart for demonstrating operation | movement of a common reference information extraction process. It is a figure which shows the example of a common reference information presentation screen. It is a figure which shows the example of the source code in which the erasable code is displayed distinguishing from other parts. It is a flowchart for demonstrating operation | movement of a UDP packet transmission process. It is FIG. (1) which shows a part of source code of a UDP packet communication program. It is FIG. (2) which shows a part of source code of a UDP packet communication program. It is FIG. (The 3) which shows a part of source code of a UDP packet communication program. It is FIG. (4) which shows a part of source code of a UDP packet communication program. It is a figure which shows the structure of the module designated by the object module designation | designated part. FIG. 10 is a diagram (part 1) illustrating an example of source code in which a erasable code is displayed separately from other parts. FIG. 10 is a diagram (part 2) illustrating an example of source code in which a erasable code is displayed separately from other parts. FIG. 10 is a diagram (part 3) illustrating an example of source code in which a erasable code is displayed separately from other parts. FIG. 10 is a diagram (part 4) illustrating an example of a source code in which a erasable code is displayed separately from other parts. FIG. 10 is a diagram (No. 5) illustrating an example of source code in which a erasable code is displayed separately from other parts.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals. Unless otherwise specified, it is assumed that the source code of the program shown in the embodiment of the present invention is written in C language. In addition, the “function” in the embodiment of the present invention refers to a function uniquely defined by the user, and does not include a function such as printf prepared as a standard in C language. In addition, the source code illustrated as appropriate in the following description is given a line number on the left side for easy description.

  The module dependency relationship extraction assistance device 100 according to the embodiment of the present invention is a device that extracts information indicating a dependency relationship between modules designated from within a program.

  When a program developed on a personal computer is ported to an embedded device, the embedded device resources (for example, memory usage) are limited, so development may be performed to delete modules corresponding to specific functions. . In such a case, it is important to show the user (developer) how the module to be deleted depends on other modules in order to support the development work. The module dependence relationship extraction assisting apparatus 100 according to the embodiment of the present invention is suitably used in such a situation.

  As shown in FIG. 1, the module dependency relationship extraction apparatus 100 physically includes a communication unit 11, an operation unit 12, a display unit 13, a storage unit 14, an input / output I / F unit 15, and a control. Unit 16. Each unit is connected to each other via a bus 17.

  The communication unit 11 communicates with an information processing apparatus (not shown) on the network 2 via the communication network 2 and includes a communication interface and the like. For example, the communication unit 11 may receive the source code of the program to be analyzed for the dependency relationship extraction from the information processing apparatuses on the network 2.

  The operation unit 12 is used to input various information to the module dependency relationship extraction apparatus 100, and includes an input device such as a keyboard.

  The display unit 13 outputs various information and includes a display device such as a liquid crystal display.

  The storage unit 14 stores various information, programs, and other applications, and includes an auxiliary storage device such as a hard disk drive.

  The input / output I / F unit 15 is an interface for connecting the input / output device 3. For example, the source code of a program to be analyzed for dependency relation extraction can be taken in from the input / output device 3 such as a CD-ROM drive via the input / output I / F unit 15.

  The control unit 16 performs calculation processing of data and controls the communication unit 11, the operation unit 12, the output unit 13, the storage unit 14, and the input / output I / F unit 15 via the bus 17. A central processing unit (16a), a read only memory (ROM) 16b, a random access memory (RAM) 16c, and the like are provided. Specifically, the arithmetic processing and control processing in the control unit 16 are performed by the CPU 16a executing a control program stored in the ROM 16b while temporarily storing various data using the RAM 16c as a work area. Done.

  As shown in FIG. 2, the module dependency relationship extraction device 100 functionally includes a source code storage unit 21, a source code acquisition unit 22, a target module specification unit 23, an operation condition specification unit 24, and a dependency relationship. An extraction unit 25 and a presentation unit 26 are provided. The control unit 16 shown in FIG. 1 controls the communication unit 11, the operation unit 12, the output unit 13, the storage unit 14, or the input / output I / F unit 15 shown in FIG. It is realized by doing.

  The source code storage unit 21 stores a plurality of source codes. Each source code describes (defines) one or more functions.

  The source code acquisition unit 22 acquires one or more source codes of a program to be analyzed for extracting dependency relationships between modules based on an instruction from the user input via the operation unit 12. Note that the source code acquisition unit 22 may acquire all source codes stored in the source code storage unit 21 as analysis targets. The source code acquisition unit 22 may acquire source code from an external server or the like via the Internet or the like. The source code acquired by the source code acquisition unit 22 is referred to as an acquired source code and will be described below.

  The target module designating unit 23 designates a module to be subject to dependency extraction from among modules constituting a program corresponding to the acquired source code based on an instruction from the user input via the operation unit 12. . Specifically, the target module designating unit 23 designates a dependence source module (first module) and a dependence destination module (second module) called from the first module. When using the module dependency extraction device 100 to support development for deleting a function from a program, it is desirable to designate the module corresponding to the function to be deleted as the second module.

  Note that the module in the present embodiment represents a set of one or more functions. Accordingly, the target module designating unit 23 designates functions belonging to the first module and the second module from the functions defined in the acquisition source code based on an instruction from the user by a function name or the like. To do.

The operation condition designating unit 24 designates input data conditions (operation conditions) for operating the program corresponding to the acquired source code based on an instruction from the user input via the operation unit 12.
In this embodiment, the operating conditions are limited by the destination program due to restrictions on the hardware resources of the embedded device when the existing program created on the personal computer is ported to the embedded device or the like. Indicates the range of input data. For example, when porting an existing program that executes processing according to the available memory capacity to the embedded device using the available memory capacity as input data, the maximum value of this input data is the limit value of the available memory capacity at the destination. It is sufficient to set the operating conditions.

  The dependency relationship extraction unit 25 analyzes the acquired program and extracts information indicating the dependency relationship between the first module and the second module when the program is operated under the specified operation condition. The dependency relationship extraction unit 25 includes a common reference information extraction unit 251, a deletion target specifying unit 252, a deletable resource estimation unit 253, and an inter-module dependency calculation unit 254.

  The common reference information extraction unit 251 analyzes the acquired source code and can refer to information in common from both the first module and the second module when the program is operated under specified operating conditions ( Functions and global variables).

  The deletion target specifying unit 252 specifies the functions and global variables extracted by the common reference information extraction unit 251 that can be deleted together from within the program when the second module is deleted. Specifically, the deletion target specifying unit 252 is a module (function) other than the first module and the second module when the program is operated under the specified operating condition among the extracted functions and global variables. Those that are not referred to from are identified as objects that can be deleted.

  The deletable resource estimation unit 253 estimates the amount of hardware resource reduction when the function and global variable identified as deletable by the deletion target specifying unit 252 are deleted from the program.

  The inter-module dependence calculation unit 254 determines the first module based on the function and global variable extracted by the common reference information extraction unit 251 based on the function and global variable that the deletion target specifying unit 252 determines not to delete. An inter-module dependency indicating the degree of dependency of the second module is calculated.

(Dependency extraction process)
Subsequently, the operation of the dependency relationship extraction process for extracting the dependency relationship between the modules constituting the program executed by the module dependency relationship extracting apparatus 100 will be described in detail with specific examples as appropriate. The user inputs an instruction for starting the dependency relationship extraction process via the operation unit 12 of the module dependency relationship extraction apparatus 100. In response to this instruction, the module dependency relationship extracting apparatus 100 executes the dependency relationship extracting process shown in the flowchart of FIG.

  When the dependency relationship extraction processing is executed, first, the user operates the operation unit 12 of the module dependency relationship extraction device 100 to specify the source code of the program to be analyzed. In response to this specification, the source code acquisition unit 22 acquires the specified source code (acquired source code) from the source code storage unit 21 (step S101). For example, the following description will be made assuming that the source code shown in FIG. 4 has been acquired.

  Returning to FIG. 3, when the acquisition of the source code is completed, the user operates the operation unit 12, and the first module and the first module that are the dependency sources from which the dependency is extracted from the acquired source code Designates the second module to be called from. The target module designating unit accepts this designation, and identifies the first module and the second module based on the accepted content (step S102).

  For example, as shown in FIG. 5A, from the acquisition source code shown in FIG. 4, the function “mod1_func0 ()” as the first module, and the functions “mod2_func1 ()” and “mod2_func2 ()” as the second modules. , “Mod2_func3 ()”, “mod2_func4 ()”, “mod2_func5 ()”, and “mod2_func6 ()” are designated as follows.

  Returning to FIG. 3, when the designation of the first module and the second module is completed, the user operates the operation unit 12 to designate (input) an operating condition for causing the program corresponding to the acquired source code to be executed. ) The operating condition designating unit 24 accepts this designation, and acquires the operating condition based on the accepted content (step S103).

  For example, as shown in FIG. 5B, the value of the variable “val” handled in the acquisition source code shown in FIG. 4 is arbitrary, and the value of the variable “val2” is less than 100. The following description assumes that the conditions are specified.

  Returning to FIG. 3, when the specification of the operation condition is completed, the common reference information extraction unit 251 executes the program of the first module and the second module when the program corresponding to the acquired source code is executed under the specified operation condition. A common reference information extraction process for extracting information that can be commonly referred to from both is executed (step S104). The common reference information extraction process will be described in detail with reference to the flowchart of FIG.

  When the common reference information extraction process is started, first, the common reference information extraction unit 251 analyzes the acquired source code, and executes the first when the program corresponding to the acquired source code is executed under the specified operating condition. Functions and global variables that may be commonly referenced from both the module and the second module are extracted (step S1041).

  For example, when the program corresponding to the acquisition source code shown in FIG. 4 is executed under the operation condition “val2 <100” specified in FIG. 5B, it is described in the 16th and 24th lines of the acquisition source code. The functions “mod2_func3 ()” and “mod2_func6 ()” are not executed. Accordingly, the functions “mod2_func3 ()” and “mod2_func6 ()” are not referred to from the first module (function “mod1_func0 ()”), and these functions are excluded from the extraction target. In addition, since the process on the 12th line of the acquisition source code may be executed even under the specified operation condition, the function “mod2_func1 ()” and the global variable “g_val1” are issued from both the first module and the second module. It can be seen that " Thereafter, the obtained source code is similarly analyzed, and finally the functions “mod2_func1 ()”, “mod2_func2 ()”, “mod2_func4 ()”, “mod2_func5 ()”, and the global variable “g_val1” are step S1041. It is extracted by processing.

Returning to FIG. 6, subsequently, the common reference information extraction unit 251 analyzes the acquired source code, and executes the function extracted in step S <b> 1041 when the program corresponding to the acquired source code is executed under the specified operating condition. It is determined whether there is another function (subroutine) that may be referred to from (step S1042).
For example, in the above-described example, whether or not another function is referred to for each of the functions “mod2_func1 ()”, “mod2_func2 ()”, “mod2_func4 ()”, and “mod2_func5 ()” extracted in step S1041. Is determined. Here, the following description will be given assuming that such a function is not detected.

  Returning to FIG. 6, when it is determined that there is another function (subroutine) (step S1042; Yes), the common reference information extraction unit 251 analyzes the part of the source code in which the function (subroutine) is defined. Then, a function and a global variable that can be referred to from this function are extracted under the specified operating condition (step S1043).

  Hereinafter, the common reference information extraction unit 251 determines whether there is a function (subroutine) that may be referred to from the function extracted in step S1043 under the specified operating condition. In addition, the process of extracting functions and global variables that can be referred to from the subroutine is repeated.

  On the other hand, when it is determined that there is no function (subroutine) (step S1042; No), there are no more functions and global variables to be extracted, and the common reference information extraction process ends.

  Returning to FIG. 3, when the common reference information extraction process is completed, the presentation unit 26 displays (presents) the information (function and global variable) extracted by the common reference information extraction process on the display unit 13 (step S105).

  In the above example, as shown in FIG. 7A, the extracted functions “mod2_func1 ()”, “mod2_func2 ()”, “mod2_func4 ()”, “mod2_func5 ()” and the global variable “g_val1” A common reference information presentation screen in which names are displayed as a list is displayed on the display unit 13.

  Returning to FIG. 3, when there is an instruction request to display a deleteable code from the user via the operation unit 12, the deletion target specifying unit 252 is extracted by the common reference information extraction process (step S <b> 104). Among functions and global variables, when a program is executed under specified operating conditions, functions and global variables that are not referenced by other than the first module and second module are specified as functions and global variables that can be deleted. (Step S106).

  In the above example, the common reference information is extracted in the modules other than the first module and the second module (function “mod4_func ()”) from the description of the 32rd to 35th lines in the acquisition source code shown in FIG. It can be seen that the function “mod2_func2 ()” extracted in the process (step S104) is referenced. Therefore, the function “mod2_func2 ()” is excluded from the objects that can be deleted, and finally the functions “mod2_func1 ()”, “mod2_func4 ()”, “mod2_func5 ()”, and the global variable “g_val1” are deleted. Identified as possible.

  Returning to FIG. 3, subsequently, the presentation unit 26 can distinguish the part in which the erasable function and the global variable specified in step S <b> 106 are described in the acquisition source code from other parts as the erasable code. A screen to be displayed is created and displayed on the display unit 13 (step S107).

  In the above-described example, as shown in FIG. 8, the functions “mod2_func1 ()”, “mod2_func4 ()”, “mod2_func5 ()” that are identified as deletable, and the global variable “g_val1” are described. The acquired source code in which the parts of the line 12, the twelfth line, the twentieth line, and the twenty-second line are surrounded by a dotted line as a erasable part is displayed.

  Returning to FIG. 3, when there is a request to display a hardware resource that can be reduced from the user via the operation unit 12, the resource estimation unit 253 displays the portion displayed as the erasable code in step S <b> 107. A reduction amount of hardware resources (for example, storage capacity (ROM capacity) and memory usage (RAM capacity)) when deleted is estimated (step S108). Then, the presentation unit 26 displays (presents) the estimated hardware resource reduction amount on the display unit 13 (step S109).

  For example, if the capacity is ROM capacity, the resource estimation unit 253 may compile only the portion displayed as the erasable code and estimate the size of the generated binary code. If the RAM capacity is reached, the resource estimation unit 253 estimates the RAM capacity by predicting the memory allocated to the global variable by referring to the declaration part in the source code of the global variable identified as the erasable code. That's fine.

  In the above example, to store the ROM capacity for the size of the binary code obtained by compiling the functions “mod2_func1 ()”, “mod2_func4 ()”, and “mod2_func5 ()”, and the global variable “g_val1” The RAM capacity required for this is the amount of hardware resource reduction when the erasable code is deleted. Note that the amount of RAM capacity to be reduced originally needs to be evaluated for OS resources, the capacity required for tasks and interrupt contexts, etc., but since this embodiment does not delete tasks, it is included in the evaluation. Suppose there is nothing.

  Subsequently, when there is an inter-module dependency display instruction request from the user via the operation unit 12, the inter-module dependency calculation unit 254 determines the degree of dependency of the second module on the first module. The inter-module dependency shown is calculated (step S110). Specifically, the inter-module dependency calculation unit 254 pays attention to the functions and global variables that cannot be deleted in step S106 among the functions and global variables extracted in the common reference information extraction process (step S104). The inter-module dependency is calculated.

  For example, the more functions and global variables that are not to be deleted, the more difficult it is to delete the second module, and it is considered that the second module depends on the first module. Therefore, for example, the inter-module dependency calculation unit 254 may calculate the number of functions and global variables that are not to be deleted as the inter-module dependency. In this case, in the above-described example, since only the function “mod2_func2 ()” is not a deletion target among the extracted functions and global variables, the dependency is calculated as 1.

  Alternatively, since it is considered that the function that is not the deletion target has a return value or the more the number of arguments, the inter-module dependency calculation unit 254 determines that “the function that is not the deletion target”. The total number of arguments of each function that was not to be deleted * 2 + the number of functions that have a return value among the functions that were not to be deleted + the number of global variables that were not to be deleted " The inter-module dependency may be calculated using an equation.

  Subsequently, the presentation unit 26 displays (presents) the calculated inter-module dependency on the display unit 13 (step S111). Thus, the dependency relationship extraction process ends.

(Example of dependency extraction processing using a specific program)
Next, the above-described dependency extraction process will be described for a more specific program (a program for UDP packet communication incorporated in a communication device having a communication function based on IPv6 (Internet Protocol Version 6)).

  First, an outline of packet transmission processing (UDP packet transmission processing) by a UDP packet communication program (UDP packet communication program) will be described with reference to the flowchart shown in FIG. The UDP packet transmission process is a process performed when the control unit of the communication apparatus executes a UDP packet communication program.

  When the UDP packet transmission program is executed, the control unit of the communication apparatus sets (generates) a link local address from its own MAC address (step S201).

  Subsequently, the control unit of the communication device transmits a neighbor request to the local network, and searches whether there is no duplication in the set link local address (step S202). As a result of the search, when it is determined that there are duplicate link local addresses (step S203; Yes), it is found that a node having the same address exists on the network, and the control unit of the communication device invalidates the link local address. (Step S204).

  As a result of the search, when it is determined that there is no duplicate link local address (step S203; No), or when the invalid setting of the duplicate link local address is completed by the process of step S204, the control unit of the communication device A router solicitation message including the set link local address as a transmission source address is transmitted to the router (step S205).

  Subsequently, the control unit of the communication apparatus determines whether a new prefix is set in the router advertisement received as a response from the router that transmitted the router solicitation message (step S206).

  If it is determined that a new prefix has been set (step S206; Yes), the control unit of the communication apparatus sets (generates) an Ipv6 global address using this prefix (step S207).

  Subsequently, the control unit of the communication device sends a neighbor request to the inside of the network, and searches whether there is no duplication in the set Ipv6 global address (step S208). As a result of the search, when it is determined that there is an overlapping link local address (step S209; Yes), it can be seen that a node having the same Ipv6 global address exists on the network, and the control unit of the communication device determines the Ipv6 global address. Is set to invalid (step S210).

  As a result of the search, when it is determined that there is no duplicate Ipv6 global address (step S209; No), or when the invalid setting of the Ipv6 global address is completed by the processing of step S210, the control unit of the communication device sets The UDP packet is transmitted to the transmission destination using the Ipv6 global address (step S211).

  On the other hand, if it is determined that a new prefix has not been set (step S206; No), the control unit of the communication device uses the Ipv6 global address already set from the existing prefix as a destination for the UDP packet. Transmit (step S211). Thus, the UDP packet transmission process ends.

Subsequently, source codes SC1 to SC4 corresponding to the above-described UDP packet communication program are shown in FIGS. The source code SC1 shown in FIG. 10 describes a function “main ()” that is executed first in the UDP packet communication program. The function “com_init ()” called from the function “main ()” on the seventh line of the source code SC1 executes a process (neighbor search at start-up) corresponding to step S201 to step S210 of the UDP packet transmission process described above. Is a function of In addition, the function “send_udp ()” on the 12th line is a function for executing a process (UDP packet transmission) corresponding to step S211 of the UDP packet transmission process.
Note that the function “icmp6_input ()” that performs processing when a UDP packet is received by the function “start_task ()” on the sixth line in order to execute the reception process in a task different from the UDP packet transmission process. It is executed as a separate task.

  In addition, in the 3rd to 28th lines of the source code SC2 shown in FIG. 11, a function “com_init ()” for performing activation proximity search is described (defined). Further, the 30th to 49th lines of the source code SC2 describe a function “router_com ()” that is a subroutine of the function “com_init ()” and performs communication with the router.

  In addition, the 3rd to 27th lines of the source code SC3 shown in FIG. 12 describe (define) a function “icmp6_input ()” that performs processing when a UDP packet is received. As described above, this function “icmp6_input ()” is executed in a task different from the UDP packet transmission process. It is assumed that when the function “icmp6_input ()” is called, the received UDP packet is stored in the global variable “in_buf” indicating the reception buffer. The function “icmp6_input ()” calls various functions for executing necessary processing according to the type of the received UDP packet.

  Further, in the 4th to 8th lines, the 10th to 15th lines, the 17th to 29th lines, and the 31st to 35th lines of the source code SC4 shown in FIG. 13, a function “send_ns_dad ()” called from another function, “Send_rs ()”, “send_na ()”, and “send_echo_repl ()” are described (defined).

  Subsequently, when porting the above-described UDP packet communication program to an embedded device, it is necessary to perform “development of a function for searching for duplicate addresses on the assumption that addresses are not duplicated in the network” In order to support the development work, a case will be described in which the dependency extraction processing for the UDP packet communication program described above is executed.

  In this case, first, in step S101 (designation of source code), source codes SC1 to SC4 shown in FIGS. 10 to 13 are extracted.

  Further, in step S102 (designation of the module), the processing is performed to support the development for deleting the function for performing the duplicate search. Therefore, the functions “send_ns_dad ()”, “rcv_na_dad”, “detach_addr ()” regarding the duplicate search are performed. Is designated as the second module. In addition, the function “com_init ()” that calls these functions is designated as the first module. That is, as shown in FIG. 14A, the first module and the second module are designated.

  In step S103 (designation of operating conditions), it is assumed that “arbitrary” that does not designate any operating conditions is set.

  Subsequently, step S104 (common reference information extraction processing) is executed, and functions and global variables that can be commonly referred to are extracted from the first module and the second module. From the description of the 10th line, the 12th line, the 13th line, the 23rd line, and the 26th line of the source code SC2 shown in FIG. 11, under the specified operating condition, the function “com_init ( ) ”, It can be seen that the functions“ send_ns_dad () ”,“ rcv_na_dad () ”, and“ detach_addr () ”belonging to the second module can be referred to. Therefore, these functions are first extracted as commonly referenced functions. Subsequently, from the description of the fourth to eighth lines of the source code SC4 shown in FIG. 13, the extracted function “send_ns_dad ()” refers to the functions “make_ns_dad_packet ()”, “icmp6_output”, and the global variable “out_buf”. Since these are understood, these are also extracted. Therefore, the functions “send_ns_dad ()”, “rcv_na_dad ()”, “detach_addr ()”, “make_ns_dad_packet ()”, “icmp6_output ()” and the global variable “out_buf” are finally obtained by the common reference information extraction process. And are extracted. Then, in step S105 (display of common referenceable information), a common reference information presentation screen as shown in FIG.

  Subsequently, step S106 (identification of deletion target) is performed. Among the extracted functions, the function “icmp6_output ()” is the module 1 (function “com_init ()”) and module 2 (function “ Because it can be seen from modules other than send_ns_dad (), rcv_na_dad, detach_addr ()) (function "send_rs ()", function "send_na ()" and function "send_echo_repl ()") Excluded from deletion. Similarly, the extracted global variable “out_buf” is obtained from modules (function “send_rs ()” and function “send_na ()”) other than modules 1 and 2 from the description on lines 12 and 20 of the source code SC4. Since it is understood that can be referred to, it is excluded from the deletion target. Therefore, the functions “send_ns_dad ()”, “rcv_na_dad ()”, “detach_addr ()”, and “make_ns_dad_packet ()” are finally specified as deletion targets.

  Subsequently, in step S107 (deletion target code display), a part in which the function and the global variable specified as the deletion target are described or defined in the source code is set as a deleteable part. As shown in the figure, the display is surrounded by a dotted line.

  Subsequently, in step S110 (calculation of inter-module dependency), among the extracted functions and global variables, the function “icmp6_output ()” and the global variable “out_buf” are excluded from the deletion target as described above. Yes. Therefore, when the inter-module dependency is the number of functions / global variables that are not to be deleted, the inter-module dependency is calculated as 2, and the calculated inter-module dependency is calculated in step S111 (display of inter-module dependency). The degree is displayed.

  Note that the function “icmp6_output ()” has one argument and no return value (void type). Therefore, the inter-module dependency is expressed as “the number of functions that are not to be deleted + the total number of arguments of each function that is not to be deleted * 2 + the number of functions that have a return value among the functions that are not to be deleted”. When the calculation formula of “+ number of global variables not to be deleted” is calculated, the inter-module dependency is calculated as “1 + 1 * 2 + 0 + 1 = 4”, and is calculated in step S111 (display of inter-module dependency). The dependency between modules is displayed.

  In the above example (transmission of duplicate search), no operation condition is specified in the process of step S103 (designation of operation condition). On the other hand, when receiving a duplicate search, “icmp6_input ()” is designated for the first module and “send_na ()” is designated for the second module in step 102 (designation of the module). A possible value of the variable ns_type may be designated as “NS_AR” or “NS_NUD”. Note that this operating condition means that “no processing is performed even if a duplicate check transmitted by another communication device is received”. At this time, according to the processing of the flowchart shown in FIG. 6, “make_na_dad_packet ()” on the 20th line in FIG. 19 is a function that can be deleted. In the duplicate search reception process, the designation of the second module may be “all modules that refer to the variable ns_type”.

  Subsequently, when porting the UDP packet communication program to an embedded device, it is necessary to perform "development that eliminates the function related to router communication on the assumption that it will be used in an environment that does not use a router", in order to support the development work. Next, a description will be given of a case where the dependency extraction process for the above-described UDP packet communication program is executed. In addition, about the same process as the description of the dependence relationship extraction process performed when supporting the development which deletes the function to search repeatedly, description is abbreviate | omitted suitably.

  In this case, in step S102 (designation of the module), the processing is performed to support the development for deleting the router communication function, and therefore the functions “router_com ()” and “proc_ra ()” related to the router communication are the second module. Specified as In addition, functions “com_init ()” and “icmp6_input ()” that call these functions are designated as the first module. That is, as shown in FIG. 14B, the first module and the second module are designated.

  Subsequently, step S104 (common reference information extraction process) is executed. From the description of the 16th line of the source code SC2 shown in FIG. 11, the function “router_com ()” belonging to the second module can be referred to from the function “com_init ()” belonging to the first module under the specified operating conditions. It can be seen that it is. Further, from the description of the 13th line of the source code SC3 shown in FIG. 12, the function “proc_ra ()” belonging to the second module is changed from the function “icmp6_input ()” belonging to the first module under the designated operating condition. It can be seen that it can be referred to. Therefore, these functions “router_com ()” and “proc_ra ()” are first extracted as commonly referenced functions. Furthermore, since the extracted function “proc_ra ()” refers to the global variable “in_buf” from the description on the 13th line of the source code SC3, the global variable “in_buf” is also extracted. Subsequently, from the descriptions of the 35th, 36th, and 42th lines of the source code SC2 shown in FIG. 11, the extracted function “router_com ()” has the functions “send_rs ()”, “proc_rs_reply ()”, and the global variable “retry_cnt”. These are also subject to extraction. Furthermore, from the description of the 12th and 13th lines of the source code SC4 shown in FIG. 13, the extracted function “send_rs ()” refers to the functions “make_rs_packet ()”, “icmp6_output ()” and the global variable “out_buf”. These are also extracted. Therefore, finally, the functions `` router_com () '', `` proc_ra () '', `` send_rs () '', `` proc_rs_reply () '', `` make_rs_packet () '', `` icmp6_output () '' The global variables “in_buf”, “retry_cnt”, and “out_buf” are extracted. In step S105 (display of common information), a common reference information presentation screen as shown in FIG. 7C is displayed.

  Subsequently, step S106 (identification of deletion target) is performed. Among the extracted functions, the function “icmp6_output ()” is module 1 (functions “com_init ()”, “icmp6_input ()”) from the description on the seventh, 28th and 34th lines of the source code SC4 shown in FIG. And modules 2 (functions “router_com ()”, “proc_ra ()”) other than modules (function “send_ns_dad ()”, function “send_na ()”, and function “send_echo_repl ()”) Since it is understood, it is excluded from the deletion target. Similarly, the extracted global variable “out_buf” is obtained from modules (function “send_ns_dad ()” and function “send_na ()”) other than modules 1 and 2 from the description on the 6th and 20th lines of the source code SC4. Since it is understood that can be referred to, it is excluded from the deletion target. Similarly, the extracted global variable “in_buf” can be referred to from modules other than module 1 and module 2 (function “get_dst_addr ()”, etc.) from the description on the 18th line of the source code SC3 shown in FIG. Therefore, it is excluded from the deletion target. Therefore, finally, the functions “router_com ()”, “proc_ra ()”, “send_rs ()”, “proc_rs_reply ()”, “make_rs_packet ()” and the global variable “retry_cnt” are specified as deletion targets. The

  Subsequently, in step S107 (display of the deletion target code), the parts where these functions and global variables are described or defined in the source codes SC1 to SC4 are shown as the erasable parts in FIGS. 17 to 19. As shown, it is surrounded by a dotted line.

  Subsequently, in step S110 (calculation of inter-module dependency), as described above, among the extracted functions and global variables, the function “icmp6_output ()” and the global variables “out_buf” and “in_buf” are to be deleted. It is excluded from. Therefore, when the inter-module dependency is the number of functions / global variables not to be deleted, the inter-module dependency is calculated as 3, and the calculated inter-module dependency is calculated in step S111 (display of inter-module dependency). The degree is displayed.

  Note that the function “icmp6_output ()” has one argument and no return value (void type). Therefore, the inter-module dependency is expressed as “the number of functions that are not to be deleted + the total number of arguments of each function that is not to be deleted * 2 + the number of functions that have a return value among the functions that are not to be deleted”. When the calculation formula of “+ number of global variables not to be deleted” is calculated, the inter-module dependency is calculated as “1 + 1 * 2 + 0 + 2 = 5”, and is calculated in step S111 (display of inter-module dependency). The dependency between modules is displayed.

  As described above, according to the present embodiment, the source code is analyzed based on the restriction (operation condition) of the designated data, and information that is commonly referred to among the modules is extracted. Therefore, even when the data range handled by the program is restricted, the dependency relationship between modules can be accurately extracted.

  In addition, in order to port existing software (program) to an embedded device, development is generally performed to delete functions so as to meet the hardware resource constraints of the embedded device. In such a case, using the module dependency extraction device 100 according to the present embodiment, this restriction is designated as an operation condition, and the module corresponding to the function to be deleted is extracted as a module (second module) for extracting the dependency. If the dependency extraction process is performed by designating, information related to the function to be deleted can be presented to the user. Therefore, it is possible to efficiently support a user who performs development to delete such a function.

  In the present embodiment, a function and a global variable that can be commonly referred to by the first module and the second module are presented to the user under designated operating conditions. Therefore, the user can easily confirm what information the first module and the second module are connected to, and therefore supports development in which the second module is deleted. It becomes possible.

  Also, in the present embodiment, the functions and global variables that can be deleted are identified from the functions and global variables extracted as common reference information based on the operating conditions, and are displayed separately from other parts of the source code. . Therefore, by confirming this display, the user can easily know which part of the source code should be deleted when developing to delete the function, and support the user's development work. Is possible.

  Also, in this embodiment, when the displayed deletable part is actually deleted, the amount of hardware resources that can be reduced is estimated and displayed, so that meaningful information is presented to the user and the user's development work is supported. It becomes possible to do.

  Moreover, in this embodiment, since the inter-module dependence between the designated modules is calculated and displayed, it is possible to present meaningful information to the user and support the user's development work.

  In addition, this invention is not limited to the said embodiment, Of course, the various change in the part which does not deviate from the summary of this invention is possible.

  For example, in the above-described embodiment, functions and global variables that are commonly referred to from the modules are extracted and displayed, or the source code portion in which the functions and global variables that can be deleted are displayed. However, only the function or only the global variable may be extracted and displayed, or only the function or only the global variable may be displayed as a deletion target.

  Moreover, in the said embodiment, as shown in FIG. 8 etc., although the part which can be deleted in a source code was displayed by the surrounding of a dotted line, you may display a character color and a font differently from another part. In short, any display form can be adopted as long as the erasable part can be displayed separately from other parts in the source code.

  In the above embodiment, the source file described in the C language has been mainly described as an example. However, the present invention also applies to a source file described in another program language such as JAVA (registered trademark) or BASIC. Of course, is applicable. In that case, of course, it is necessary to analyze the source code by a method according to the grammar of each language and perform processing such as extraction of functions and global variables.

  In addition, for example, by applying an operation program that defines the operation of the module-existing relationship extraction apparatus 100 according to the present invention to an existing personal computer, an information terminal device, etc. It is also possible to function as the extraction device 100.

  Further, the distribution method of such a program is arbitrary. For example, the program can be read by a computer such as a CD-ROM (Compact Disk Read-Only Memory), a DVD (Digital Versatile Disk), an MO (Magneto Optical Disk), or a memory card. It may be distributed by storing in a recording medium, or distributed via a communication network such as the Internet.

100 Module Dependency Extraction Device 21 Source Code Storage Unit 22 Source Code Acquisition Unit 23 Target Module Specification Unit 24 Operation Condition Specification Unit 25 Dependency Extraction Unit 251 Common Reference Information Extraction Unit 252 Deletion Target Specification Unit 253 Deletable Resource Estimation Unit 254 Module Interdependency calculation unit 26 Presentation unit

Claims (7)

Source code acquisition means for acquiring the source code of the program;
Module designation means for accepting designation of a first module and a second module called from the first module from among the modules constituting the program;
An operation condition specifying means for receiving specification of an operation condition for operating the program;
When the source code is analyzed and the program is operated under the specified operating conditions, information that can be referred to in common from the first module and the second module is referred to as the first module and the second module. Dependency extraction means for extracting information indicating the dependency relationship between the two modules;
Presenting means for presenting information extracted by the dependency relationship extracting means;
A module dependency relationship extracting apparatus comprising: The dependency extraction unit extracts a function and / or a global variable that can be commonly referred to from the first module and the second module when the program is operated under the specified operation condition from the source code. To
The module dependence relationship extracting apparatus according to claim 1, wherein Among the functions and / or global variables extracted by the dependency relationship extraction means, functions and / or global variables that are not referenced by other than the first module and the second module in the program can be deleted. It further includes a deletion target specifying means for specifying,
The presenting means displays a part in which the function and / or global variable specified by the deletion target specifying means is described or defined in the source code separately from other parts in the source code.
The module dependence relationship extracting device according to claim 2, wherein A resource estimation unit that estimates an amount of hardware resources to be reduced when the deletable portion displayed by the presenting unit is deleted from the source code;
The presenting means presents an amount of hardware resources estimated by the resource estimating means;
The module dependence relationship extracting device according to claim 3. Of the functions and / or global variables extracted by the extraction means, the second module for the first module based on the functions and / or global variables not specified by the deletion target specifying means as deletion targets. Further comprising a dependency calculation means for calculating the dependency of
The presenting means presents the dependency degree calculated by the dependency degree calculating means.
5. The module dependency relationship extraction device according to claim 3 or 4, Get the source code of the program
Accepting designation of the first module and the second module called from the first module from among the modules constituting the program,
Accepting specification of operating conditions for operating the program,
When the source code is analyzed and the program is operated under the specified operating conditions, information that can be referred to in common from the first module and the second module is referred to as the first module and the second module. Extracted as information indicating the dependency relationship between the two modules,
Presenting the extracted information;
A module dependency extraction method characterized by that. Computer
Source code acquisition means for acquiring the source code of the program,
Module designation means for accepting designation of the first module and the second module called from the first module from among the modules constituting the program;
An operation condition specifying means for receiving specification of an operation condition for operating the program;
When the source code is analyzed and the program is operated under the specified operating conditions, information that can be referred to in common from the first module and the second module is referred to as the first module and the second module. Dependency extraction means for extracting as information indicating the dependency relationship between the two modules;
Presenting means for presenting information extracted by the dependency relationship extracting means;
Program to function as.

Images