WO2020070817A1 - ソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラム - Google Patents

ソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラム

Info

Publication number
WO2020070817A1
WO2020070817A1 PCT/JP2018/036996 JP2018036996W WO2020070817A1 WO 2020070817 A1 WO2020070817 A1 WO 2020070817A1 JP 2018036996 W JP2018036996 W JP 2018036996W WO 2020070817 A1 WO2020070817 A1 WO 2020070817A1
Authority
WO
WIPO (PCT)
Prior art keywords
analysis
dependency
software
function
dynamic
Prior art date
Application number
PCT/JP2018/036996
Other languages
English (en)
French (fr)
Inventor
泰史 東
利大 小林
祐希 檜皮
Original Assignee
三菱電機株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三菱電機株式会社 filed Critical 三菱電機株式会社
Priority to US17/268,840 priority Critical patent/US11630662B2/en
Priority to EP18936141.3A priority patent/EP3862873A4/en
Priority to JP2020550997A priority patent/JP7046217B2/ja
Priority to PCT/JP2018/036996 priority patent/WO2020070817A1/ja
Publication of WO2020070817A1 publication Critical patent/WO2020070817A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/43—Checking; Contextual analysis
    • G06F8/433—Dependency analysis; Data or control flow analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3612—Software analysis for verifying properties of programs by runtime analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/74—Reverse engineering; Extracting design information from source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/75—Structural analysis for program understanding

Definitions

  • the present invention relates to a software analysis device, a software analysis method, and a software analysis program, and more particularly, to a software analysis device, a software analysis method, and a software analysis program for analyzing dependency between software objects.
  • Patent Literature 1 discloses a syntax analysis unit for causing a computer to execute a syntax analysis of a source code, and a plurality of variables distinguished for each description position in a source code from a syntax analysis result by the computer.
  • a software structure visualization program that includes a variable dependency analysis unit for deriving a dependency relationship between the software and the software. This allows a designer or a verifier to understand the software structure and the processing outline from the viewpoint of variable dependency.
  • Patent Literature 2 discloses a source code processing unit that processes a source code into a log-acquirable program, and a test execution that executes a program processed by the source code processing unit in a test case related to a function that a user focuses on and acquires a log.
  • an object structure extracting means for extracting an object structure by connecting combinations of objects having a high object size.
  • Patent Literature 1 uses a static syntax analysis result of a source code, it analyzes dependency between software components that have a dependency by a pointer variable or the like via an address. Can not do it.
  • Patent Document 2 uses not only static analysis of source code but also dynamic analysis of executing a program in a test case and acquiring a log. All are analyzed by static analysis, and the results of dynamic analysis are only used to show the importance of the dependency. Therefore, it is not possible to analyze a dependency relationship between software components having a dependency relationship by a pointer variable or the like via an address.
  • the present invention has been made to solve the above-described problem, and has a dependency between software components obtained by static analysis and a software component obtained by dynamic analysis.
  • An object of the present invention is to analyze the dependencies between the components of the software more comprehensively and more accurately than the prior art based on the dependencies.
  • One embodiment of the present invention provides a first analysis unit that statically analyzes the structure of software source code and analyzes a dependency between software objects, and a first analysis unit that executes a program indicated by the source code and executes an operation of the object.
  • a second analysis unit that acquires information 1 and analyzes a dependency between objects based on the first information, and based on an analysis result of the first analysis unit and an analysis result of the second analysis unit.
  • a software analysis device for analyzing a dependency between objects.
  • Another aspect of the present invention relates to a first analysis step of statically analyzing the structure of software source code and analyzing dependencies between software objects, and an operation of the object by executing a program indicated by the source code.
  • a second analysis step of acquiring first information and analyzing a dependency between objects based on the first information; an analysis result of the first analysis step; and an analysis result of the second analysis step. Analyzing the dependencies between the two.
  • Another embodiment of the present invention provides a software analysis program for causing a computer to execute the above software analysis method.
  • a software analysis device capable of analyzing the dependencies between components of software more comprehensively and more accurately than the conventional technology are obtained.
  • FIG. 1 is a block diagram illustrating a configuration of an analysis device according to Embodiment 1 of the present invention.
  • 5 is a flowchart illustrating a flow of an operation of the analysis device according to the first embodiment of the present invention.
  • 3 is a flowchart illustrating a detailed flow of a static analysis step illustrated in FIG. 2.
  • FIG. 3 is a diagram illustrating an example of a source code. It is a figure showing an example of a static analysis result database.
  • FIG. 4 is a diagram illustrating an example of a static dependency database.
  • 3 is a flowchart illustrating a detailed flow of a dynamic analysis step illustrated in FIG. 2.
  • FIG. 4 is a diagram illustrating an example of a correction code.
  • FIG. 3 is a diagram illustrating an example of a dynamic dependency analysis stack.
  • FIG. 4 is a diagram illustrating an example of a dynamic dependency database.
  • FIG. 3 is a flowchart illustrating a detailed flow of steps of analyzing a comprehensive dependency relationship illustrated in FIG. 2. It is a figure showing an example of an analysis result.
  • FIG. 9 is a block diagram illustrating a configuration of an analysis device according to Embodiment 2 of the present invention. 13 is a flowchart illustrating a flow of a dynamic analysis according to the second embodiment.
  • FIG. 16 is a flowchart illustrating a detailed flow of steps for generating a log in FIG. 15.
  • FIG. 4 is a diagram illustrating an example of a message log. It is a flowchart which shows the detailed flow of the step which analyzes a dynamic dependency.
  • FIG. 4 is a diagram illustrating an example of a dynamic dependency database.
  • FIG. 13 is a block diagram illustrating a configuration of an analysis device according to Embodiment 3 of the present invention.
  • 17 is a flowchart illustrating a flow of a dynamic analysis according to the third embodiment.
  • FIG. 3 is a diagram illustrating an example of a source code.
  • FIG. 3 is a diagram illustrating a list of addresses of a shared memory. It is a figure showing an example of a function execution log.
  • FIG. 4 is a diagram illustrating an example of a shared memory access log. It is a flowchart which shows the detailed flow of the step which analyzes a dynamic dependency.
  • FIG. 4 is a diagram illustrating an example of a shared memory access record.
  • FIG. 4 is a diagram illustrating an example of a dynamic dependency database.
  • FIG. 14 is a block diagram illustrating a configuration of an analysis device according to a fourth embodiment of the present invention. 20 is a flowchart illustrating a flow of a dynamic analysis according to the fourth embodiment.
  • FIG. 9 is a diagram illustrating an example of an operation log acquired during the execution of a program. It is a flowchart which shows the detailed flow of the step which analyzes a dynamic dependency.
  • FIG. 3 is a diagram illustrating an example of a dynamic dependency analysis stack.
  • FIG. 6 is a diagram illustrating an example of a call source unknown function stack.
  • FIG. 4 is a diagram illustrating an example of a dynamic dependency database.
  • FIG. 13 is a block diagram illustrating a configuration of an analyzer according to Embodiment 5 of the present invention. It is a figure showing an example of an operation log. 33 is a flowchart showing a detailed flow of a step of analyzing a dynamic dependency in the fifth embodiment.
  • FIG. 16 is a block diagram illustrating a configuration of an analysis device according to a sixth embodiment of the present invention. It is a figure showing an example of an operation log.
  • FIG. 3 is a diagram illustrating an example of a dynamic dependency analysis stack.
  • FIG. 33 is a flowchart showing a detailed flow of a step of analyzing a dynamic dependency in the sixth embodiment.
  • FIG. 4 is a diagram illustrating an example of a dynamic dependency database.
  • FIG. 3 is a diagram illustrating an example of a source code.
  • FIG. 4 is a diagram illustrating an example of a static dependency database. It is a flowchart which shows the detailed flow of the step which analyzes comprehensive dependency. It is a figure showing an example of the analysis result after having completed the step of analyzing comprehensive dependency.
  • FIG. 15 is a block diagram illustrating a configuration of an analysis device according to Embodiment 7 of the present invention.
  • FIG. 4 is a diagram illustrating an example of a dynamic dependency database.
  • FIG. 15 is a block diagram illustrating a configuration of an analysis device according to Embodiment 8 of the present invention. 15 is a flowchart illustrating a flow of an operation of the analysis device according to the eighth embodiment of the present invention.
  • FIG. 3 is a diagram illustrating an example of a source code. It is a figure showing an example of a static analysis result database.
  • FIG. 4 is a diagram illustrating an example of a dynamic dependency database.
  • 53 is a flowchart illustrating a detailed flow of a step of analyzing a dependency of a function in the function table illustrated in FIG. 52.
  • FIG. 21 is a block diagram illustrating a configuration of an analysis device according to Embodiment 9 of the present invention.
  • FIG. 9 is a diagram illustrating an example of an operation log obtained by executing an execution program by giving specific input data in a specific environment.
  • FIG. 13 is a diagram illustrating an example of an operation log obtained by executing an execution program in another environment or by giving other input data.
  • FIG. 60B is a diagram illustrating a dynamic dependency obtained based on the operation log in FIG. 60A.
  • FIG. 60B is a diagram showing a dynamic dependency obtained based on the operation log in FIG. 60B.
  • FIG. 61B is a diagram showing a dynamic dependency obtained by combining the dynamic dependency of FIG. 61a and the dynamic dependency of FIG. 61b.
  • FIG. 1 is a block diagram showing a configuration of an analyzer 100 according to Embodiment 1 of the present invention.
  • the analysis device 100 includes an input unit 1, a static analysis unit 2, a static analysis result database (DB) 3, a static dependency analysis unit 4, and a static dependency database (DB) 5.
  • DB static analysis result database
  • DB static dependency database
  • the input unit 1 reads the source code 20 that can be executed as a program and inputs the source code 20 to the analysis device 100.
  • the input source code 20 is selected, for example, by a user's file specification.
  • the source code is described in, for example, an object-oriented language.
  • the static analysis unit 2 performs a static structure analysis of the source code 20 and outputs an analysis result.
  • the static structure analysis refers to a technique for analyzing the syntax and structure of a source code without executing a program.
  • the static analysis result output from the static analysis unit 2 includes dependencies between software components (objects) such as class references, function calls, object calls, and header file references (also called call relationships or called relationships). Contains information about
  • an object is a set of functions and data (for example, variables and constants).
  • the static analysis result database 3 stores the static analysis results output from the static analysis unit 2.
  • the static dependency analysis unit 4 analyzes the static analysis results stored in the static analysis result database 3, arranges the dependencies between the software components, and stores them in the static dependency database 5.
  • the analysis device 100 further includes a code processing unit 6, a compiling unit 7, an execution unit 8, a dynamic analysis unit 9, and a dynamic analysis result database (DB) 10.
  • DB dynamic analysis result database
  • the source code 20 input to the input unit 1 is transmitted not only to the static analysis unit 2 but also to the code processing unit 6 for performing dynamic analysis.
  • the code processing unit 6 processes the source code 20 to create a log-acquirable correction code.
  • the compiling section 7 compiles the correction code. That is, the compiling unit 7 converts the correction code into an executable program in an executable format such as a machine language.
  • the execution unit 8 executes an execution program.
  • the dynamic analysis unit 9 monitors the processing of the execution program, generates logs such as an execution log and an access log, and stores the logs in the dynamic analysis result database 10.
  • the analysis device 100 further includes a dynamic dependency analysis unit 11 and a dynamic dependency database (DB) 12.
  • the dynamic dependency analysis unit 11 analyzes dependencies between software components from information stored in the dynamic analysis result database 10 and stores the information in the dynamic dependency database 12.
  • the analysis device 100 further includes a comprehensive dependency analysis unit 13 and an output unit 15.
  • the comprehensive dependency analysis unit 13 combines the static dependency stored in the static dependency database 5 and the dynamic dependency stored in the dynamic dependency database 12 to obtain a comprehensive
  • the analysis result 14 indicating the dependencies is output.
  • the output unit 15 outputs the analysis result 14 to the outside of the analysis device 100.
  • the static analysis result database 3, the static dependency database 5, the dynamic analysis result database 10, and the dynamic dependency database 12 are media for recording various information.
  • Each of these databases is realized, for example, by a semiconductor memory device such as a ROM, a flash memory, and an SSD, a disk device such as a hard disk, and other storage devices alone or by appropriately combining them.
  • the analysis device 100 is realized by software.
  • the relationship analysis unit 13 and the output unit 15 are realized by a program.
  • a program is stored in the storage device, and is called and executed by a general-purpose processor such as a CPU or an MPU.
  • FIG. 2 is a flowchart showing the flow of the operation of the analysis device 100.
  • the analysis device 100 reads the source code 20 via the input unit 1 (S101).
  • the analysis device 100 performs a static analysis on the source code 20 and analyzes a static dependency (S102).
  • the analysis device 100 performs a dynamic analysis on the source code 20 to analyze a dynamic dependency (S103).
  • the analysis device 100 analyzes the total dependency by combining the static dependency obtained in step S102 and the dynamic dependency obtained in step S103 (S104).
  • the analysis device 100 outputs the analysis result 14 obtained in step S104 from the output unit 15 (S105). Note that the execution order of step S102 and step S103 may be reversed, and step S103 may be executed before step S102.
  • FIG. 3 is a flowchart showing a detailed flow of the static analysis step S102 shown in FIG.
  • the static analysis unit 2 performs a static structure analysis of the source code 20 (S110).
  • the static analysis result output from the static analysis unit 2 is stored in the static analysis result database 3 (S111).
  • FIG. 4A is a diagram showing an example of the source code 20.
  • FIG. 4B is a diagram illustrating an example of the static analysis result database 3.
  • the syntax, structure, and the like of the source code 20 are analyzed without executing the source code 20 (statically), and a static analysis result as illustrated in FIG. 4B is obtained.
  • FIG. 4B is a function list that enumerates the functions described in the source code 20, and includes information about a call destination function that the enumerated function calls. 4B, the functions included in the source code 20 are listed. The function called by the function shown in the "function" column is shown in the "call destination function" column of FIG. 4b.
  • FIG. 1 indicates that the test1, function2, and test3 functions are called in the main function in the source code 20.
  • the func function is called from the test3 function.
  • the static dependency analysis unit 4 analyzes the static analysis result stored in the static analysis result database 3 (S112), and sorts out the dependencies between the software components. Then, it is stored in the static dependency database 5 (S113).
  • FIG. 4C is a diagram illustrating an example of the static dependency database 5. For example, in FIG. The line 1 indicates that the main function depends on the test1 function. Therefore, in FIG. Looking at row 1, it can be seen that if a change occurs in the test1 function, the effect of the change also affects the main function.
  • FIG. 5 is a flowchart showing a detailed flow of the dynamic analysis step S103 shown in FIG.
  • the code processing unit 6 processes the source code 20 so that a log can be obtained, and creates a correction code 21 as shown in FIG. 6 (S120).
  • the correction code 21 inserts a function [function name] _IN (for example, func_IN) at the beginning of a function described in the source code 20 and a function [function name] _OUT (for example, func_OUT) at the end of the function. Is inserted.
  • the compiling unit 7 compiles the modified code 21 and converts it into an executable program in an executable format (S121).
  • the execution unit 8 executes an execution program.
  • a test case is given to the execution program.
  • the test case is input data for realizing a specific function of the program.
  • the test case may be externally input by a user or a developer.
  • the test case may be stored in a storage device (not shown) such as a flash memory, an HDD, or an SSD provided in the analysis device 100 in advance.
  • the dynamic analysis unit 9 monitors the processing of the execution program and generates logs such as an execution log and an access log (S122).
  • FIG. 7 is a flowchart showing a detailed flow of step S122 for generating a log.
  • step S122 for generating a log first, the dynamic analysis unit 9 determines whether the execution of the execution program has been completed (S130). When it is determined that the execution of the execution program has not been completed, the dynamic analysis unit 9 determines whether the [function name] _IN function or the [function name] of the correction code 21 (actually, the execution program after compiling the correction code 21) is used. It is monitored whether the _OUT function has been executed (S131). If neither has been executed, the process returns to step S130.
  • step S131 When the [function name] _IN function is executed in step S131, the [function name] is recorded in the “function name” column and the IN is recorded in the “state” column of the operation log 22 as shown in FIG. 8 (S132). .
  • the main_IN function since the main_IN function was executed first (execution order 1), “main” is recorded in the “function name” column of the operation log 22, and IN is recorded in the “state” column. After recording, the process returns to step S130.
  • step S131 If the [function name] _OUT function is executed in step S131, the function name is recorded in the “function name” column and OUT is recorded in the “state” column of the operation log 22 (S133). After recording, the process returns to step S130.
  • step S130 By repeating the above steps S130 to S133, the operation log 22 as shown in FIG. 8 is generated.
  • step S122 for generating a log is ended, and the process proceeds to step S123 shown in FIG.
  • the operation log 22 generated in step S122 is stored in the dynamic analysis result database 10 (S123).
  • the dynamic dependency analysis unit 11 analyzes the dynamic dependency between software components from information such as the operation log 22 stored in the dynamic analysis result database 10 (S124).
  • FIG. 9 is a flowchart showing a detailed flow of step S124 for analyzing a dynamic dependency.
  • the dynamic dependency analysis unit 11 checks the contents of the “state” column in the execution order 1 of the operation log 22 (see FIG. 8) (S140, S141). When it is determined that IN is recorded in the “state” column of the operation log 22, the dynamic dependency analysis unit 11 stores the function in the dynamic dependency analysis stack 23 (hereinafter, referred to as “first stack”). It is determined whether it is stored (S142). In the example shown in FIG. 8, IN is recorded in the “state” column of the execution order 1, and therefore, it is determined whether the function is stored in the first stack 23 or not.
  • the stack such as the first stack is realized by using a volatile memory such as an SRAM or a DRAM for temporarily storing various information.
  • FIG. 10 is a diagram showing an example of the first stack 23.
  • no function is stored in the first stack 23 (see the row above the row of execution order 1 in FIG. 10).
  • the function in the current execution order of the operation log 22 is registered (pushed or pushed) in the first stack 23 (S144).
  • the function executed in the execution order 1 is a main function (see FIG. 8). Therefore, the main function is pushed in the execution order 1 of the first stack 23 shown in FIG.
  • the first stack 23 is in the state shown in the row of the execution order 1 in FIG.
  • step S142 when a function is stored in the first stack 23 in step S142, the dynamic dependency analysis unit 11 uses the function stored in the first stack 23 as a dependency source, The function in the current execution order of the operation log 22 is registered in the dynamic dependency relationship as a dependency (S143). As shown in FIG. 9, step S144 is also executed after step S143.
  • step S144 the dynamic dependency analysis unit 11 determines whether the execution order of the operation log 22 is the last (S147). In the last case, the step S124 for analyzing the dynamic dependency is ended, and the process proceeds to the step S125 shown in FIG. If it is not the last, the execution order is incremented (S148), and the process returns to step S141.
  • step S141 it is determined whether a function is stored in the first stack 23 (S145).
  • step S145 the dynamic dependency analysis unit 11 removes (pops) the function from the first stack 23 (S146). If no function is stored in the first stack 23 in step S145, the process proceeds to step S147. After the execution of step S146, the process proceeds to step S147.
  • step S147 the execution order is incremented to the last execution order, and after it is determined as Yes in step S147, all functions are popped from the first stack 23 (see the line of execution order 12 in FIG. 10). ) And the dynamic dependency as shown in FIG. Then, the process proceeds to step S125 shown in FIG. 5, and the dynamic dependency as shown in FIG. 11 is stored in the dynamic dependency database 12.
  • FIG. 12 is a flowchart showing a detailed flow of step S104 for analyzing the comprehensive dependency shown in FIG.
  • step S104 a dependency obtained by integrating the information stored in the static dependency database 5 and the information stored in the dynamic dependency database 12 is obtained.
  • the comprehensive dependency analysis unit 13 stores all the dependencies stored in the static dependency database 5 as shown in FIG. 4C in the analysis result 14 (S150).
  • the comprehensive dependency analysis unit 13 checks the No. of the dynamic dependency database 12 as shown in FIG.
  • the dependency stored in one row is acquired (S151).
  • the first row stores a dependency relationship with the main function as a dependency source and the test1 function as a dependency destination.
  • the comprehensive dependency analysis unit 13 determines whether or not the obtained dependency exists in the analysis result 14 (S152). If it is determined that the dependency does not exist, the comprehensive dependency analysis unit 13 stores the obtained dependency in the analysis result 14 (S153), and proceeds to the next step S154. If it is determined in step S152 that the acquired dependency exists in the analysis result 14, the process also proceeds to step S154.
  • step S154 the comprehensive dependency analysis unit 13 determines whether or not the dependencies of all rows in the dynamic dependency database 12 have been confirmed. If the dependencies of all the rows have not been checked, the comprehensive dependency analysis unit 13 acquires the dependency stored in the next row of the dynamic dependency database 12 (S155). Thereafter, the process returns to step S152.
  • step S104 for analyzing the overall dependency is completed, and the process proceeds to step S105 shown in FIG.
  • FIG. 13 is a diagram showing an example of the analysis result 14 after step S104 for analyzing the overall dependency is completed.
  • the analysis result 14 of FIG. A row 4 dependency has been added.
  • the static analysis it cannot be analyzed that the func function, which is the address destination of the function pointer pf, is called from the test2 function, but it can be analyzed by the dynamic analysis. Relationships have been added.
  • the analysis device 100 includes the static analysis unit 2 that statically analyzes the structure of the software source code 20 and the static dependency unit that analyzes the dependency between the software objects based on the static analysis result. It includes a relationship analysis unit 4 and a dynamic dependency analysis unit 11 that executes a program indicated by the source code 20 to acquire an operation log 22, and analyzes a dependency between objects based on the operation log 22. The analysis device 100 analyzes the dependency between objects based on the analysis result of the static dependency analysis unit 4 and the analysis result of the dynamic dependency analysis unit 11.
  • the analysis device 100 can analyze the dependency between the functions via the pointer reference, which cannot be analyzed by the static analysis, by using the analysis result by the dynamic dependency analysis unit 11. As described above, by combining the dynamic analysis and the static analysis, the analysis apparatus 100 can analyze the dependency between the components of the software more comprehensively than the conventional technology.
  • FIG. FIG. 14 is a block diagram showing a configuration of an analyzer 200 according to Embodiment 2 of the present invention.
  • the analyzer 200 does not include the code processing unit 6.
  • the functions or operations of the dynamic analysis unit 209, the dynamic analysis result database 210, and the dynamic dependency analysis unit 211 of the analysis device 200 are different from those of the first embodiment.
  • the dynamic analysis of the source code 20 is performed by analyzing message passing transmitted and received between tasks.
  • Message passing is one of the communication methods between objects, and is one of means for sharing information between tasks in a software program in which a plurality of tasks are executed in parallel.
  • FIG. 15 is a flowchart showing the flow of the dynamic analysis according to the second embodiment. Compared to the flowchart of FIG. 5 of the first embodiment, FIG. 15 does not include a step of creating a correction code and a step of storing a dynamic dependency in a dynamic dependency database. The operation of storing the dynamic dependency in the dynamic dependency database is included in step S224 described later in the second embodiment.
  • FIG. 16 is a flowchart showing a detailed flow of step S222 for generating the log in FIG.
  • the dynamic analysis unit 209 determines whether the execution of the execution program has been completed (S230). If it is determined that the execution of the execution program has not been completed, the dynamic analysis unit 209 monitors whether the task has received or transmitted a message (S231). If neither reception nor transmission has been performed, the process returns to step S230.
  • step S231 If it is determined in step S231 that the task has transmitted the message, the dynamic analysis unit 209 transmits the context ID of the transmitted message, the message content, and the message to the message log 222 as illustrated in FIG.
  • step S230 By repeating the above steps S230 to S233, a message log 222 as shown in FIG. 17 is generated.
  • step S222 for generating a log is ended, and the process proceeds to step S223 shown in FIG.
  • the message log 222 generated in step S222 is stored in the dynamic analysis result database 210 (S223).
  • the dynamic dependency analysis unit 211 analyzes the dynamic dependency between the software components from information such as the message log 222 stored in the dynamic analysis result database 210 (S224).
  • FIG. 18 is a flowchart showing a detailed flow of step S224 for analyzing a dynamic dependency.
  • the dynamic dependency analysis unit 211 determines whether or not all the messages in the message log 222 stored in the dynamic analysis result database 210 have been analyzed (S240). If not completed, the dynamic dependency analysis unit 211 selects one unanalyzed message and obtains a record in the “Receive Task” column and a record in the “Transmit Task” column identified by the context ID ( S241).
  • the dynamic dependency analysis unit 211 checks whether or not a dependency having the acquired reception task as a dependency source and a transmission task as a destination is stored in the dynamic dependency database 212 ( S242). If stored, the process returns to step S240. If it is not stored, the dependency on the acquired receiving task as the dependency source and the transmission task as the dependency destination is stored in the dynamic dependency database 212 (S243).
  • step S240 when it is determined that the analysis has been completed for all the messages, the step S224 of analyzing the dynamic dependency is ended. In this way, a dynamic dependency database 212 as shown in FIG. 19 is obtained.
  • the dynamic dependency analysis unit 211 generates an analysis result indicating that there is a dependency between the task that transmitted the message and the task that received the message.
  • the dynamic dependency analysis unit 211 performs a dynamic analysis based on the analysis result, and the analysis device 200 determines the analysis result of the static dependency analysis unit 4, the analysis result of the dynamic dependency analysis unit 211, Analyze dependencies between tasks based on.
  • the analysis device 200 can analyze the dependency between functions via message passing that cannot be analyzed by static analysis. As described above, by combining the dynamic analysis and the static analysis, the analysis device 200 can analyze the dependency between the components of the software more comprehensively than the conventional technology.
  • FIG. FIG. 20 is a block diagram showing a configuration of an analyzer 300 according to Embodiment 3 of the present invention.
  • the functions or operations of the dynamic analyzer 309, the dynamic analysis result database 310, and the dynamic dependency analyzer 311 of the analyzer 300 are the same as those of the first embodiment. It is different from the dynamic analysis unit 9, the dynamic analysis result database 10, and the dynamic dependency analysis unit 11.
  • the analysis device 300 analyzes the operation between objects that exchange data via the shared memory.
  • the shared memory is configured by a volatile memory such as an SRAM or a DRAM for temporarily storing various information.
  • FIG. 21 is a flowchart showing the flow of the dynamic analysis according to the third embodiment. The flow of the dynamic analysis will be described with reference to FIGS.
  • FIG. 22 is a diagram illustrating an example of the source code 320.
  • a shared memory is used.
  • the structure Point is declared globally, and the entity is declared in the main function.
  • an address is passed as an argument of the PrintPoint function.
  • a process of reading the value of the passed address is performed.
  • FIG. 23 is a diagram showing an address list 321 of the shared memory used in the source code 320.
  • the execution unit 8 executes the execution program.
  • the dynamic analysis unit 309 monitors the processing of the execution program and generates a function execution log 322 as shown in FIG. 24 and a shared memory access log 323 as shown in FIG. 25 (S322). .
  • the function execution log 322 records the start time and end time of the function processing.
  • the main function was executed from time 00:00 to time 00:05
  • the PrintPoint function was executed from time 00:05 to time 00:20.
  • the access destination address and the access time are recorded in the shared memory access log 323.
  • the dynamic analysis unit 309 analyzes an address secured when the shared memory is declared, and obtains an access destination address and an access time.
  • the dynamic analysis unit 309 records the access destination address and the access time when the shared memory is accessed in the shared memory access log 323. In the example shown in FIG. 25, it can be seen that the times when the address 0x0000 was accessed were 00:01 and 00:06.
  • the generated function execution log 322 and shared memory access log 323 are stored in the dynamic analysis result database 310 (S323).
  • the dynamic dependency analysis unit 311 analyzes a dynamic dependency between software components from the function execution log 322 and the shared memory access log 323 stored in the dynamic analysis result database 310 (S324).
  • FIG. 26 is a flowchart showing a detailed flow of step S324 for analyzing a dynamic dependency.
  • the dynamic dependency analysis unit 311 acquires an access time from the shared memory access log 323 (S340). For example, in the example shown in FIG. 25, the access time 00:01 is acquired. The other access time is obtained after the subsequent loop, but the obtained time (for example, 00:01) is not obtained.
  • the dynamic dependency relationship analysis unit 311 acquires from the function execution log 322 the function executed at the access time acquired in step S340 (S341).
  • the acquired access time was 00:01.
  • the function executed at the access time 00:01 is the main function. Therefore, the dynamic dependency analysis unit 311 acquires the main function from the function execution log 322.
  • the dynamic dependency analysis unit 311 records the function acquired in step S341 in the shared memory access record 324 as shown in FIG. 27 as the function that accessed the shared memory address at the access time (S342). ).
  • the dynamic dependency analysis unit 311 determines whether or not all access times of the shared memory access log 323 have been acquired (S343). If it is determined that it has not been acquired, the process returns to step S340. If it is determined that it has been acquired, the process proceeds to step S344. When all the access times of the shared memory access log 323 have been acquired, the shared memory access record 324 as shown in FIG. 27 has been completed.
  • the dynamic dependency analysis unit 311 selects one unconfirmed one of the shared memory addresses recorded in the shared memory access record 324 (S344).
  • the dynamic dependency relationship analysis unit 311 checks the shared memory access record 324 and determines whether or not the selected shared memory address has been accessed from a plurality of functions (S345).
  • step S344 when the shared memory address 0x0000 is selected in step S344, it can be determined that the selected shared memory address 0x0000 has been accessed from a plurality of functions of the main function and the PrintPoint function.
  • step S345 If it is determined in step S345 that there has been access from a plurality of functions, all the accessed functions are combined with each other as a dependency source and a dependency destination and stored in the dynamic dependency database 312 (S346).
  • the functions accessing the shared memory address 0x0000 are the main function and the PrintPoint function. Therefore, in the dynamic dependency relationship database 312, the dependency No. with the PrintPoint function as the dependency source and the main function as the dependency destination. 1 and the dependency No. 1 with the main function as the dependency source and the PrintPoint function as the destination. 2 is stored. Thus, a dynamic dependency database 312 as shown in FIG. 28 is obtained.
  • the analysis device 300 utilizes a shared memory.
  • the dynamic dependency analysis unit 311 analyzes dependencies between functions based on the address of the shared memory accessed by the program indicated by the source code 320 and the access time.
  • the analysis device 300 can analyze the dependency between functions via the shared memory, which cannot be analyzed by the static analysis. As described above, by combining the dynamic analysis and the static analysis, the analysis apparatus 300 can analyze the dependency between the components of the software more comprehensively than the related art.
  • FIG. FIG. 29 is a block diagram showing a configuration of an analyzer 400 according to Embodiment 4 of the present invention.
  • the analysis device 400 further includes a dependency source complementing unit 411 in addition to the configuration of the analysis device 100 of the first embodiment. Even when the operation log (see FIG. 8) is acquired during the execution of the program, the dependency source complementing unit 411 can analyze the dependency when transitioning from the callee function to the caller function.
  • FIG. 30 is a flowchart showing the flow of the dynamic analysis according to the fourth embodiment.
  • the flowchart of FIG. 30 is the same as the flowchart of FIG. 5 of the first embodiment except for step S424 for analyzing the dynamic dependency.
  • FIG. 31 is a diagram illustrating an example of the operation log 422 acquired during the execution of the program.
  • the operation log 422 records function names and states after execution order 4.
  • the function names and states in the execution order 1 to 3 are not recorded.
  • FIG. 32 is a flowchart showing a detailed flow of step S424 for analyzing a dynamic dependency.
  • the dependency source complementing unit 411 determines whether IN is recorded in the “status” column of the execution order 1 of the operation log 422 (S140, S141). If it is determined that IN has been recorded, the process proceeds to step S142, but the flow after step S142 is the same as the flow of the first embodiment shown in FIG.
  • the dependency source complementing unit 411 determines whether a function is stored in the dynamic dependency analysis stack (first stack) 423 illustrated in FIG. 33 ( S145). If a function is stored in the first stack 423, the function is popped from the first stack 423 (S146).
  • the dependency source complementing unit 411 determines whether the first stack 423 is empty (S440). If it is determined that the function is empty, the dependency source complementing unit 411 pushes the function popped in step S146 onto a caller unknown function stack 424 (hereinafter, referred to as “second stack”) (S441).
  • second stack a caller unknown function stack 424
  • FIG. 34 is a diagram illustrating an example of the second stack. After step S441, the process proceeds to step S147 (see FIG. 9) described in the first embodiment.
  • step S145 If it is determined in step S145 that the function is not stored in the first stack 423, the dependency source complementing unit 411 determines whether the function is stored in the second stack (S442). If it is determined that the function is stored in the second stack, the dependency source complementing unit 411 sets the function in the current execution order of the operation log 422 as the dependency source and sets the function registered in the second stack as the dependency destination. Is registered as a dynamic dependency (S443). After registration, the process proceeds to step S147.
  • the test2 function is popped from the first stack 423 (FIG. 33), and the function in the first stack 423 disappears. That is, the caller of the test2 function is unknown. Therefore, the test2 function is registered in the caller unknown function stack (second stack) 424 (S441). It can be seen that the calling function of the test2 function was the main function when the state of the main function became OUT in the execution order 12 (see FIG. 31). Therefore, the dependent function is registered in the dynamic dependency relationship as the main function and the dependent function as the test2 function (S443). The same applies to the test3 function.
  • the dynamic dependency database 412 as shown in FIG. 35 is obtained.
  • the dependency source complementing unit 411 indicates the transition from the call destination function to the call source function.
  • the dependency between the functions is complemented based on the information of the operation log 422.
  • the analysis apparatus 400 can analyze the calling function even when the program is executed in the middle of the dynamic analysis, and can analyze the dependencies between the components of the software more comprehensively than in the related art. can do.
  • FIG. FIG. 36 is a block diagram showing a configuration of an analyzer 500 according to Embodiment 5 of the present invention.
  • the analysis device 500 further includes a task designation unit 511 in addition to the configuration of the analysis device 100 according to the first embodiment.
  • the flow of the operation of the analysis device 500 is the same as the flow shown in the flowchart of FIG. 2 of the first embodiment, but the step of analyzing the dynamic dependency in the dynamic analysis step (S103 of FIG. 2) (FIG. 5 (S124) is different.
  • FIG. 37 is a diagram showing the operation log 522.
  • the operation log 522 is created by the dynamic analysis unit 509 and stored in the dynamic analysis result database 510.
  • the operation log 522 further includes a “task” column.
  • a task that executes the function described in the “function name” column is recorded.
  • the interrupt functions described in the execution orders 5 and 6 of the operation log 522 are an example of interrupt processing executed by the interrupt task Interrupt.
  • FIG. 38 is a flowchart showing a detailed flow of steps for analyzing a dynamic dependency in the fifth embodiment.
  • the user specifies the exclusion task 530 (see FIG. 36).
  • the specified task is excluded from the analysis target.
  • the user inputs the exclusion task 530 to the analysis device 500 using an input device (not shown) such as a mouse, a keyboard, a touch panel, a button, and a microphone for voice input.
  • the exclusion task 530 may be selected from the operation log 522 or may be set in advance.
  • the task designation unit 511 first reads the input exclusion task 530 (S539). Next, the “status” column and the “task” column in the execution order 1 of the operation log 522 (see FIG. 37) are checked (S540). If the task recorded in the “task” column does not correspond to the excluded task 530, the process proceeds to step S141 (S541). Steps S141 to S148 are the same as the steps of the first embodiment shown in FIG.
  • step S541 If it is determined in step S541 that the task recorded in the “task” column corresponds to the excluded task 530, the analysis of the dynamic dependency is omitted, and the process proceeds to step S147.
  • the user designates the Interrupt task as the excluded task 530.
  • the execution orders 5 and 6 of the operation log 522 shown in FIG. 37 are excluded from the analysis targets. Therefore, the dependency between the test2 function and the interrupt function is not output.
  • the analyzing apparatus 500 further includes the task specifying unit 511 that receives an input of the excluded task 530 that specifies the task to be analyzed.
  • the task specifying unit 511 does not analyze the dependency between the functions related to the task specified by the excluded task 530, but analyzes the dependency between the functions related to other tasks.
  • FIG. 39 is a block diagram showing a configuration of an analyzer 600 according to Embodiment 6 of the present invention.
  • the analysis device 600 further includes an influence complementing unit 611 in addition to the configuration of the analysis device 100 of the first embodiment.
  • the flow of the operation of the analysis apparatus 600 is the same as the flow shown in the flowchart of FIG. 2 of the first embodiment, but the step of analyzing the dynamic dependency in the dynamic analysis step (S103 of FIG. 2) (FIG. 5 (S124) is different.
  • the operation of the analysis device 600 will be described using an operation log 622 shown in FIG. 40 and a dynamic dependency analysis stack (first stack) 623 shown in FIG.
  • FIG. 42 is a flowchart showing a detailed flow of steps for analyzing a dynamic dependency in the sixth embodiment. Compared with the flowchart of the first embodiment shown in FIG. 9, steps S640 and S641 are added to the flowchart of FIG.
  • the impact complementing unit 611 determines whether or not IN is recorded in the “state” column of the execution order 1 of the operation log 622 (S140, S141). If it is determined that IN has not been recorded, the process proceeds to step S145, but the flow of steps S145 to S148 is the same as the flow of the first embodiment shown in FIG.
  • step S141 If it is determined in step S141 that IN is recorded, the dynamic dependency analysis unit 11 determines whether a function is stored in the first stack 623 (S142). If it is determined that it is not stored, the process proceeds to step S144.
  • the influence complementer 611 determines whether the function dependency in the current execution order is registered as a dynamic dependency ( S640). More specifically, the influence complementing unit 611 sets the function stored in the first stack 623 as the dependency source and the function dependency with the function in the current execution order of the operation log 622 as the dependency destination as the dynamic dependency. It is determined whether or not it has been registered.
  • the influence complementer 611 increments the dependency strength value for the function dependency (S641).
  • the dependency strength value is a value indicating the strength of the dependency between two functions. The larger the dependency strength value, the stronger the dependency strength between functions.
  • the initial value of the dependent intensity value is, for example, 0. After incrementing the dependency intensity value, the process proceeds to step S144.
  • step S640 If it is determined in step S640 that the function dependency in the current execution order is not registered in the dynamic dependency, the influence complementer 611 registers the function dependency in the current execution order in the dynamic dependency. (S143). After the registration, the process proceeds to step S144.
  • FIG. 46 is a flowchart showing the detailed flow of the step of analyzing the overall dependency. Compared to the flowchart of the first embodiment shown in FIG. 12, step S653 is added to the flowchart of FIG.
  • the comprehensive dependency analyzing unit 613 stores all the dependencies stored in the static dependency database 5 in the analysis result 614 (S150).
  • the comprehensive dependency analysis unit 613 checks the No. of the dynamic dependency database 612 as shown in FIG. The dependency stored in one row is acquired (S151).
  • the comprehensive dependency analysis unit 613 determines whether or not the obtained dependency exists in the analysis result 614 (S152). If it is determined that the dependency does not exist, the comprehensive dependency analysis unit 613 stores the obtained dependency in the analysis result 614 (S153), and proceeds to the next step S154.
  • step S152 If it is determined in step S152 that the acquired dynamic dependency is present in the analysis result 614, the dependency strength value of the obtained dependency is stored in the analysis result (S653). After storing, the process proceeds to step S154.
  • Steps S154 and S155 are the same as those in the first embodiment, and a description thereof will not be repeated.
  • FIG. 47 is a diagram illustrating an example of the analysis result 614 after the step of analyzing the overall dependency is completed.
  • the analysis apparatus 600 can obtain the analysis result 614 to which the dependency intensity value is assigned. This makes it possible to obtain a dependency on which the weighting index is loaded. Therefore, when the software is changed, the influence range of the change can be efficiently confirmed, and the dependency between the components of the software can be analyzed with high accuracy.
  • FIG. FIG. 48 is a block diagram showing a configuration of an analyzer 700 according to Embodiment 7 of the present invention.
  • the analysis device 700 is the same as the analysis device 100 of the first embodiment, except for the operation of the comprehensive dependency analysis unit 713 and the contents of the analysis result 714.
  • FIG. 50 is a flowchart showing the detailed flow of the step of analyzing the overall dependency.
  • the comprehensive dependency analysis unit 713 stores all the dependencies stored in the static dependency database 5 in the analysis result 714 (S150).
  • the comprehensive dependency analysis unit 713 determines the No. of the dynamic dependency database 12 as shown in FIG. The dependency stored in one row is acquired (S151).
  • the comprehensive dependency analysis unit 713 determines whether or not the obtained dependency exists in the analysis result 714 (S152).
  • step S152 If it is determined that the dependency exists, the comprehensive dependency analysis unit 713 increments the acquired importance value of the dependency and stores the result in the analysis result 714 (S753). After the storage, the process proceeds to the next step S154. If it is determined in step S152 that the acquired dependency does not exist in the analysis result 714, the process also proceeds to step S154.
  • the importance value of the dependency is a value indicating the importance of the dependency.
  • a higher importance value means that the dependency is more important for the program.
  • the initial value of the importance value is, for example, 0.
  • Steps S154 and S155 are the same as those in the first embodiment, and a description thereof will not be repeated.
  • FIG. 51 is a diagram showing an example of the analysis result 714 after completing the step of analyzing the overall dependency.
  • the analysis device 700 can obtain the analysis result 714 to which the importance value is assigned. This makes it possible to obtain a dependency on which the weighting index is loaded. Therefore, when the software is changed, the influence range of the change can be efficiently confirmed, and the dependency between the components of the software can be analyzed with high accuracy.
  • FIG. FIG. 52 is a block diagram showing a configuration of an analyzer 800 according to Embodiment 8 of the present invention.
  • the analyzer 800 includes a function table analyzer 816 and a function table dependency database (DB) 817 in addition to the configuration of the analyzer 100 of the first embodiment.
  • a source code 820 in FIG. 52 is an example of a source code including a function table.
  • FIG. 53 is a flowchart showing a flow of the operation of the analyzing apparatus 800.
  • the analyzing apparatus 800 further includes a step S806 of analyzing the dependency of the function in the function table in addition to the operation of the first embodiment shown in FIG.
  • FIG. 54 is a diagram illustrating an example of the source code 820.
  • the source code 820 includes a description of a function table.
  • the function table is an example of the “collective data group” of the present disclosure.
  • FIG. 55 is a diagram illustrating an example of the static analysis result database 803 generated in step S102.
  • the static analysis result database 803 includes a function list 8031 as shown in FIG. 4B of the first embodiment and a character string array 8032 indicating a character string array in the source code 820.
  • a plurality of character string arrays 8032 may be described in the source code 820, and the static analysis result database 803 may include a plurality of character string arrays 8032.
  • FIG. 56 is a diagram illustrating an example of the dynamic dependency database 12 that stores the result obtained in step S103. Note that the execution order of step S102 and step S103 may be reversed, and step S103 may be executed before step S102.
  • the static analysis result database 803 and the dynamic dependency database 12 are also input to the function table analysis unit 816.
  • the function table analysis unit 816 analyzes the dependencies of the functions in the function table (S806).
  • FIG. 57 is a flowchart showing a detailed flow of step S806 for analyzing the dependency of a function in the function table shown in FIG.
  • the function table analysis unit 816 determines whether or not the dependency destination function in the dynamic dependency relationship database 12 matches any of the character strings registered in the character string array 8032 in the static analysis result database 803. A determination is made (S807). If they match, the process proceeds to the next step S808. If they do not match, the process ends the step S806 (see FIG. 53) of analyzing the dependency of the function in the function table.
  • the test1 function in the dynamic dependency database 12 matches the character string registered in the character string array 8032, so that the process proceeds to step S808.
  • the function table analysis unit 816 determines whether the character string registered in the set array element number among the character strings in the character string array 8032 is in the function list 8031 (S809). If the character string registered in the set array element number is not in the function list 8031, the step S806 (see FIG. 53) of analyzing the dependency of the function in the function table is ended.
  • the function table analysis unit 816 determines that the character string in the character string The dependency with the dependency source function of the dynamic dependency database 12 as the dependency source is stored in the function table dependency database 817 (S810). Steps S809 and S810 are performed for all array element numbers in the character string array 8032 of the static analysis result database 803 (S811, S812).
  • FIG. 58a is a diagram showing an example of the function table dependency database 817 after step S806 for analyzing the dependency of functions in the function table is completed.
  • the function table dependency database 817 indicates a dependency including a called function that was not executed at the specific execution of the source code 820 but may be executed depending on the return value of the random function.
  • the function registered in the function table testTable is executed using the return value of the rand function, which is a random function, in the main function. .
  • the test1 function is executed. Therefore, when the static analysis result database 803 shown in FIG. 55 is checked, it is found that the character string array 8032 including the test1 function also includes the test2 to test4 functions. Therefore, it can be understood that the test2 to test4 functions can be executed instead of the test1 function depending on the return value of the random function. In such a case, even when the contents of the test2 to 4 functions are changed, the influence on the main function should be considered.
  • the analyzer 800 of the eighth embodiment it is possible to analyze the dependency between the test2 to 4 functions and the main function as described above.
  • FIG. 58b is a diagram showing another example of the function table dependency database 817 after the step S806 of analyzing the dependency of the function in the function table is completed.
  • an "impact degree” column is added in addition to the "dependency source” column and the "dependency destination” column of FIG. 58a.
  • the count result may be stored in the function table dependency database 817 as impact degree calculation information.
  • the influence degree X is calculated using the above N1 and N2. Is calculated by Expression (1).
  • the degree of influence X indicates a ratio value equally allocated to the dependency according to the number of functions in the function table.
  • step S804 of analyzing the overall dependencies is executed.
  • step S804 as shown in FIG. 59, the information stored in the static dependency database 5, the information stored in the dynamic dependency database 12, the information stored in the function table dependency database 817, Is obtained, and an analysis result 814 obtained by integrating is obtained.
  • the analysis apparatus 800 determines all the functions in the function table. An analysis result indicating that there is a dependency between the function and the other function is generated.
  • the dependency relationship by the function table via the pointer could not be analyzed by static analysis.
  • the dependencies on the function table can be analyzed, but the dependencies on the unexecuted functions cannot be analyzed.
  • the analysis device 800 can analyze the dependency on other functions registered in the function table.
  • FIG. FIG. 60 is a block diagram showing a configuration of an analysis system 1000 according to Embodiment 9 of the present invention.
  • the analysis system 1000 includes an analysis device 900 and an external device 950.
  • the analysis function of the present invention does not need to be realized by only the components in one device as in the analysis device 100 (see FIG. 1) of the first embodiment, but is realized by the cooperation of a plurality of devices. You may.
  • the source code 20 is input not only to the analysis device 900 but also to the external device 950.
  • the external device 950 includes an input unit 951 that reads the source code 20. Further, the external device 950 includes a code processing unit 6, a compiling unit 7, an execution unit 8, a dynamic analysis unit 9, and a dynamic analysis result database 10 similar to those of the analysis device 100 according to the first embodiment. .
  • the external device 950 further includes an output unit 952 that outputs data stored in the dynamic analysis result database 10.
  • the external device 950 creates the modification code shown in FIG. 5 at step S120, compiles the modification code and converts it into an execution program, step S122, generates a log, and stores the log in the dynamic analysis result database 10. Step S123 is performed.
  • the data stored in the dynamic analysis result database 10 is output to the analysis device 900 via the output unit 952.
  • the data output from the output unit 952 of the external device 950 is input to the second input unit 916 of the analysis device 900.
  • the analyzer 900 differs from the analyzer 100 of the first embodiment in that it does not include the code processing unit 6, the compiling unit 7, the execution unit 8, the dynamic analysis unit 9, and the dynamic analysis result database 10. This is because the functions realized by these components are realized by the external device 950. Except for these components, the analysis device 900 includes the same components as the analysis device 100 of the first embodiment.
  • the components that realize the analysis function of the present invention may be realized by a plurality of devices. This allows, for example, a computer with a high processing capacity to be in charge of dynamic analysis with a high processing load.
  • a static analysis result database 3 a dynamic analysis result database 10 a static dependency database 5
  • a dynamic dependency database 5 a database such as 5 may be stored in a storage device external to the analysis device 900.
  • Such an external storage device may be, for example, an external server that can communicate with the analysis device 900 and the external device 950 via a network.
  • Modification 1 In the above first to ninth embodiments, an example has been described in which a program is executed only once as dynamic analysis. However, the present invention is not limited to this, and dynamic analysis may be performed in which a program is executed a plurality of times to merge or accumulate operation logs.
  • FIG. 61a is a diagram showing the operation log 22a obtained by executing the execution program by giving specific input data in a specific environment in step S122 (see FIG. 5) by the execution unit 8 (see FIG. 1). .
  • FIG. 61b is a diagram showing an operation log 22b obtained by executing the execution program in another environment or by giving other input data. As shown in FIGS. 61A and 61B, different operation logs are output when the same program passes through different execution paths.
  • the operation logs 22a and 22b are stored in the dynamic analysis result database 10.
  • the step S124 (see FIG. 9) for analyzing the dynamic dependency based on the operation log 22a is performed, the dynamic dependency 14a as shown in FIG. 62a is obtained.
  • the step S124 of analyzing the dynamic dependency based on the operation log 22b is performed, the dynamic dependency 14b as shown in FIG. 62B is obtained.
  • a dynamic dependency 14c as shown in FIG. 62C is obtained.
  • the analysis device that outputs the analysis result from the output unit 15 may include a display unit that displays the analysis result to the user.
  • the display unit may display not only the final comprehensive dependency analysis result but also a static structural analysis result, a static dependency analysis result, a dynamic analysis result, and a dynamic dependency analysis result.
  • the display unit is, for example, a liquid crystal display, an organic EL display, or a projector.
  • the user can grasp the dependency between the functions by checking the analysis result displayed on the display unit. For example, when the function of the dependence destination is changed, the software development can be performed efficiently and with high accuracy by checking the function of the dependence source displayed on the display unit.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

従来技術より網羅的かつ高精度にソフトウェアの構成要素間の依存関係を解析することができるソフトウェア解析装置を提供する。ソフトウェア解析装置１００は、ソフトウェアのソースコードの構造を静的に解析し、ソフトウェアのオブジェクト間の依存関係を解析する第１解析部４と、ソースコードが示すプログラムを実行してオブジェクトの動作に関する第１情報を取得し、第１情報に基づいてオブジェクト間の依存関係を解析する第２解析部１１と、を備え、第１解析部４の解析結果と、第２解析部１１の解析結果と、に基づいて、オブジェクト間の依存関係を解析する。

Description

ソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラム
　本発明は、ソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラムに関し、特に、ソフトウェアのオブジェクト間の依存関係を解析するためのソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラムに関する。
　近年、製品の多機能化に伴い、ソフトウェア開発の規模および複雑度が増加している。また、多種多様な要望に迅速に対応するため、新規にソフトウェアを開発するより、既存のソフトウェアを流用して開発を行うことが主流となっている。ソフトウェア、特に既存のソフトウェアを変更した場合に影響が及ぶ範囲を把握するために、ソフトウェアのオブジェクト等の構成要素間の依存関係を解析する必要がある。
　特許文献１は、コンピュータにソースコードの構文解析を実行させるための構文解析部と、コンピュータに構文解析部による構文解析結果から、ソースコード中の記述位置毎に区別された複数の変数について、変数間の依存関係を導出させるための変数依存関係解析部と、を備えるソフトウェアの構造可視化プログラムを開示する。これにより、設計者や検証者がソフトウェアの構造や処理概要を、変数依存関係の観点から理解することができる。
　特許文献２は、ソースコードをログ取得可能なプログラムに加工するソースコード加工手段と、ソースコード加工手段により加工されたプログラムについてユーザが着目する機能に関するテストケースで実行し、ログを取得するテスト実行手段と、テスト実行手段により取得されたログを解析し、オブジェクトの一覧と該オブジェクト間の関係を収集するログ解析手段と、ログ解析手段により収集されたオブジェクト間の関係をもとに、重要度の高いオブジェクトの組み合わせをつなぎあわせてオブジェクト構造を抽出するオブジェクト構造抽出手段と、を備えるオブジェクト図表示装置を開示する。これにより、オブジェクト指向言語で記述されたソースコードの視覚化に際して、包含関係や関連を含むクラス間の関係情報でユーザに必要な情報を表示するとともに、実際にプログラムを実行した場合のクラス間関係を明確化することで、ユーザのソフトウェア開発を効果的に支援することができる。
特開２０１３－１５６７８６号公報 国際公開第２０１８／９６６３２号
　しかしながら、特許文献１に開示された発明は、ソースコードの静的な構文解析結果を用いているため、アドレスを介するポインタ変数等によって依存関係を有することになるソフトウェア構成要素間の依存関係を解析することができない。
　特許文献２に開示された発明は、ソースコードの静的解析のみならず、プログラムをテストケースで実行し、ログを取得する動的解析を用いるものであるが、ソフトウェア構成要素間の依存関係は静的解析で全て解析されており、動的解析の結果は、依存関係の重要度を示すことに使用されているに過ぎない。したがって、アドレスを介するポインタ変数等によって依存関係を有することになるソフトウェア構成要素間の依存関係を解析することができない。
　本発明は、上記のような課題を解決するためになされたものであり、静的解析によって得られたソフトウェアの構成要素間の依存関係と、動的解析によって得られたソフトウェアの構成要素間の依存関係と、に基づいて、従来技術より網羅的かつ高精度にソフトウェアの構成要素間の依存関係を解析することを目的する。
　本発明の一態様は、ソフトウェアのソースコードの構造を静的に解析し、ソフトウェアのオブジェクト間の依存関係を解析する第１解析部と、ソースコードが示すプログラムを実行してオブジェクトの動作に関する第１情報を取得し、第１情報に基づいてオブジェクト間の依存関係を解析する第２解析部と、を備え、第１解析部の解析結果と、第２解析部の解析結果と、に基づいて、オブジェクト間の依存関係を解析するソフトウェア解析装置を提供する。
　本発明の他の態様は、ソフトウェアのソースコードの構造を静的に解析し、ソフトウェアのオブジェクト間の依存関係を解析する第１解析ステップと、ソースコードが示すプログラムを実行してオブジェクトの動作に関する第１情報を取得し、第１情報に基づいてオブジェクト間の依存関係を解析する第２解析ステップと、第１解析ステップの解析結果と、第２解析ステップの解析結果と、に基づいて、オブジェクト間の依存関係を解析するステップと、を含むソフトウェア解析方法を提供する。
　本発明の更に他の態様は、上記のソフトウェア解析方法をコンピュータに実行させるためのソフトウェア解析プログラムを提供する。
　本発明により、従来技術より網羅的かつ高精度にソフトウェアの構成要素間の依存関係を解析することができるソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラムを得る。
本発明の実施の形態１に係る解析装置の構成を示すブロック図である。 本発明の実施の形態１に係る解析装置の動作の流れを示すフローチャートである。 図２に示した静的解析ステップの詳細な流れを示すフローチャートである。 ソースコードの一例を示す図である。 静的解析結果データベースの一例を示す図である。 静的依存関係データベースの一例を示す図である。 図２に示した動的解析ステップの詳細な流れを示すフローチャートである。 修正コードの一例を示す図である。 ログを生成するステップの詳細な流れを示すフローチャートである。 動作ログの一例を示す図である。 動的依存関係を解析するステップの詳細な流れを示すフローチャートである。 動的依存関係解析スタックの一例を示す図である。 動的依存関係データベースの一例を示す図である。 図２に示した総合的な依存関係を解析するステップの詳細な流れを示すフローチャートである。 解析結果の一例を示す図である。 本発明の実施の形態２に係る解析装置の構成を示すブロック図である。 実施の形態２における動的解析の流れを示すフローチャートである。 図１５のログを生成するステップの詳細な流れを示すフローチャートである。 メッセージログの一例を示す図である。 動的依存関係を解析するステップの詳細な流れを示すフローチャートである。 動的依存関係データベースの一例を示す図である。 本発明の実施の形態３に係る解析装置の構成を示すブロック図である。 実施の形態３における動的解析の流れを示すフローチャートである。 ソースコードの一例を示す図である。 共有メモリのアドレス一覧を示す図である。 関数実行ログの一例を示す図である。 共有メモリアクセスログの一例を示す図である。 動的依存関係を解析するステップの詳細な流れを示すフローチャートである。 共有メモリアクセス記録の一例を示す図である。 動的依存関係データベースの一例を示す図である。 本発明の実施の形態４に係る解析装置の構成を示すブロック図である。 実施の形態４における動的解析の流れを示すフローチャートである。 プログラムの実行の途中から取得された動作ログの一例を示す図である。 動的依存関係を解析するステップの詳細な流れを示すフローチャートである。 動的依存関係解析スタックの一例を示す図である。 呼出し元不明関数スタックの一例を示す図である。 動的依存関係データベースの一例を示す図である。 本発明の実施の形態５に係る解析装置の構成を示すブロック図である。 動作ログの一例を示す図である。 実施の形態５における動的依存関係を解析するステップの詳細な流れを示すフローチャートである。 本発明の実施の形態６に係る解析装置の構成を示すブロック図である。 動作ログの一例を示す図である。 動的依存関係解析スタックの一例を示す図である。 実施の形態６における動的依存関係を解析するステップの詳細な流れを示すフローチャートである。 動的依存関係データベースの一例を示す図である。 ソースコードの一例を示す図である。 静的依存関係データベースの一例を示す図である。 総合的な依存関係を解析するステップの詳細な流れを示すフローチャートである。 総合的な依存関係を解析するステップを終えた後の解析結果の一例を示す図である。 本発明の実施の形態７に係る解析装置の構成を示すブロック図である。 動的依存関係データベースの一例を示す図である。 総合的な依存関係を解析するステップの詳細な流れを示すフローチャートである。 解析結果の一例を示す図である。 本発明の実施の形態８に係る解析装置の構成を示すブロック図である。 本発明の実施の形態８に係る解析装置の動作の流れを示すフローチャートである。 ソースコードの一例を示す図である。 静的解析結果データベースの一例を示す図である。 動的依存関係データベースの一例を示す図である。 図５２に示した関数テーブル内の関数の依存関係を解析するステップの詳細な流れを示すフローチャートである。 関数テーブル依存関係データベースの一例を示す図である。 関数テーブル依存関係データベースの他の例を示す図である。 解析結果の一例を示す図である。 本発明の実施の形態９に係る解析装置の構成を示すブロック図である。 特定の環境で特定の入力データを与えて実行プログラムを実行して得られた動作ログの一例を示す図である。 他の環境でまたは他の入力データを与えて実行プログラムを実行することにより得られた動作ログの一例を示す図である。 図６０ａの動作ログに基づいて得られる動的依存関係を示す図である。 図６０ｂの動作ログに基づいて得られる動的依存関係を示す図である。 図６１ａの動的依存関係と図６１ｂの動的依存関係とを組み合わせることによって得られる動的依存関係を示す図である。
　以下、本発明の実施の形態に係る解析装置について、図面を参照して説明する。各実施の形態において、同一の構成には同一の符号を付して、重複説明を省略する。
実施の形態１．
［１．構成］
　図１は、本発明の実施の形態１に係る解析装置１００の構成を示すブロック図である。解析装置１００は、入力部１、静的解析部２、静的解析結果データベース（ＤＢ）３、静的依存関係解析部４および静的依存関係データベース（ＤＢ）５を備える。
　入力部１は、プログラムとして実行可能なソースコード２０を読み込み、解析装置１００に入力する。入力されるソースコード２０は、例えばユーザのファイル指定によって選択される。ソースコードは、例えばオブジェクト指向言語で記載される。
　静的解析部２は、ソースコード２０の静的構造解析を行い、解析結果を出力する。ここで、静的構造解析とは、プログラムを実行することなく、ソースコードの構文および構造等を解析する技術を指す。静的解析部２から出力された静的解析結果には、クラス参照、関数呼出し、オブジェクト呼出し、ヘッダーファイル参照等のソフトウェア構成要素（オブジェクト）間の依存関係（呼出し関係または被呼出し関係とも呼ばれる）に関する情報が含まれる。ここで、オブジェクトとは、関数およびデータ（例えば変数および定数）の集合である。
　静的解析結果データベース３には、静的解析部２から出力された静的解析結果が格納される。
　静的依存関係解析部４は、静的解析結果データベース３に格納された静的解析結果を解析して、ソフトウェア構成要素間の依存関係を整理して静的依存関係データベース５に格納する。
　解析装置１００は、コード加工部６、コンパイル部７、実行部８、動的解析部９および動的解析結果データベース（ＤＢ）１０を更に備える。
　入力部１に入力されたソースコード２０は、静的解析部２にだけでなく、動的解析を行うために、コード加工部６にも送信される。コード加工部６は、ソースコード２０を加工して、ログ取得可能な修正コードを作成する。
　コンパイル部７は、修正コードをコンパイルする。すなわち、コンパイル部７は、修正コードを機械語等の実行可能な形式の実行プログラムに変換する。
　実行部８は、実行プログラムを実行する。この際、動的解析部９は、実行プログラムの処理を監視して実行ログ、アクセスログ等のログを生成し、動的解析結果データベース１０に格納する。
　解析装置１００は、動的依存関係解析部１１および動的依存関係データベース（ＤＢ）１２を更に備える。動的依存関係解析部１１は、動的解析結果データベース１０に格納された情報から、ソフトウェア構成要素間の依存関係を解析して動的依存関係データベース１２に格納する。
　解析装置１００は、総合的依存関係解析部１３および出力部１５を更に備える。総合的依存関係解析部１３は、静的依存関係データベース５に格納された静的依存関係と、動的依存関係データベース１２に格納された動的依存関係を組み合わせて、ソフトウェア構成要素間の総合的な依存関係を示す解析結果１４を出力する。出力部１５は、解析結果１４を解析装置１００の外部へ出力する。
　静的解析結果データベース３、静的依存関係データベース５、動的解析結果データベース１０および動的依存関係データベース１２は、種々の情報を記録する媒体である。これらのデータベースは、それぞれ、例えば、ＲＯＭ、フラッシュメモリ、ＳＳＤ等の半導体メモリ装置、ハードディスク等のディスク装置、その他の記憶デバイス単独でまたはそれらを適宜組み合わせて実現される。
　解析装置１００は、ソフトウェアによって実現される。例えば、解析装置１００の静的解析部２、静的依存関係解析部４、コード加工部６、コンパイル部７、実行部８、動的解析部９、動的依存関係解析部１１、総合的依存関係解析部１３および出力部１５は、プログラムによって実現される。このようなプログラムは、上記の記憶デバイス内に格納され、ＣＰＵまたはＭＰＵのような汎用プロセッサによって呼び出されて実行される。
［２．動作］
　図２は、解析装置１００の動作の流れを示すフローチャートである。まず、解析装置１００は、入力部１を介して、ソースコード２０を読み込む（Ｓ１０１）。次に、解析装置１００は、ソースコード２０に静的解析を実行し、静的依存関係を解析する（Ｓ１０２）。次に、解析装置１００は、ソースコード２０に動的解析を実行し、動的依存関係を解析する（Ｓ１０３）。解析装置１００は、ステップＳ１０２で得られた静的依存関係と、ステップＳ１０３で得られた動的依存関係を組み合わせて、総合的な依存関係を解析する（Ｓ１０４）。最後に、解析装置１００は、ステップＳ１０４で得られた解析結果１４を出力部１５から出力する（Ｓ１０５）。なお、ステップＳ１０２とステップＳ１０３の実行順は逆であってもよく、ステップＳ１０２の前にステップＳ１０３が実行されてもよい。
［２－１．静的解析］
　図３は、図２に示した静的解析ステップＳ１０２の詳細な流れを示すフローチャートである。まず、静的解析部２は、ソースコード２０の静的構造解析を行う（Ｓ１１０）。次に、静的解析結果データベース３に、静的解析部２から出力された静的解析結果が格納される（Ｓ１１１）。
　図４ａは、ソースコード２０の一例を示す図である。図４ｂは、静的解析結果データベース３の一例を示す図である。ステップＳ１１０の静的構造解析では、ソースコード２０を実行せずに（静的に）、ソースコード２０の構文、構造等が解析され、図４ｂのような静的解析結果を得る。図４ｂは、ソースコード２０に記載された関数を列挙する関数一覧であり、列挙された関数が呼び出している呼出し先関数についての情報を含む。図４ｂの「関数」列には、ソースコード２０に含まれる関数が列挙されている。図４ｂの「呼出し先関数」列には、「関数」列に示された関数が呼び出している関数が示されている。
　例えば、図４ｂのＮｏ．１の行は、ソースコード２０において、ｍａｉｎ関数内でｔｅｓｔ１関数、ｔｅｓｔ２関数およびｔｅｓｔ３関数が呼び出されることを示している。次にＮｏ．５の行を見ると、ｔｅｓｔ３関数からｆｕｎｃ関数が呼び出されていることがわかる。
　しかしながら、静的解析によるソフトウェア構成要素間の依存関係解析には限界がある。例えば、図４ａに示したソースコードでは、ｔｅｓｔ１関数においてｆｕｎｃ関数のアドレスが関数ポインタｐｆに代入され、ｔｅｓｔ２関数において関数ポインタｐｆが呼び出されている。しかし、図４ｂの静的解析結果データベース３に示されているように、静的解析ではｔｅｓｔ２関数から関数ポインタｐｆのアドレス先であるｆｕｎｃ関数が呼び出されたことは解析できていない。関数ポインタｐｆのアドレス先であるｆｕｎｃ関数がｔｅｓｔ２関数から呼び出されたことは、後述の動的解析によって解析される。
　図３に戻り、ステップＳ１１１の後、静的依存関係解析部４は、静的解析結果データベース３に格納された静的解析結果を解析して（Ｓ１１２）、ソフトウェア構成要素間の依存関係を整理して静的依存関係データベース５に格納する（Ｓ１１３）。図４ｃは、静的依存関係データベース５の一例を示す図である。例えば図４ｃのＮｏ．１の行は、ｍａｉｎ関数がｔｅｓｔ１関数に依存していることを示している。したがって、図４ｃのＮｏ．１の行を見ると、ｔｅｓｔ１関数に変更が生じた場合、その変更の影響がｍａｉｎ関数にも及ぶことがわかる。
［２－２．動的解析］
　図５は、図２に示した動的解析ステップＳ１０３の詳細な流れを示すフローチャートである。まず、コード加工部６は、ソースコード２０をログ取得可能に加工して、図６に示すような修正コード２１を作成する（Ｓ１２０）。修正コード２１は、例えばソースコード２０に記載されている関数の先頭に［関数名］＿ＩＮ（例えば、ｆｕｎｃ＿ＩＮ）という関数を挿入し、関数の末尾に［関数名］＿ＯＵＴ（例えば、ｆｕｎｃ＿ＯＵＴ）という関数を挿入したものである。
　次に、コンパイル部７は、修正コード２１をコンパイルし、実行可能な形式の実行プログラムに変換する（Ｓ１２１）。実行部８は、実行プログラムを実行する。実行の際、例えば、実行プログラムにテストケースが与えられる。ここで、テストケースとは、プログラムの特定の機能を実現するための入力データである。テストケースは、ユーザや開発者によって外部から入力されてもよい。あるいは、テストケースは、解析装置１００に備えられたフラッシュメモリ、ＨＤＤ、ＳＳＤ等の記憶装置（図示せず）の中に予め格納されていてもよい。実行プログラムの実行の際、動的解析部９は、実行プログラムの処理を監視して実行ログ、アクセスログ等のログを生成する（Ｓ１２２）。
　図７は、ログを生成するステップＳ１２２の詳細な流れを示すフローチャートである。ログを生成するステップＳ１２２では、まず、動的解析部９が、実行プログラムの実行が終了したか否かを判定する（Ｓ１３０）。実行プログラムの実行が終了していないと判定した場合、動的解析部９は、修正コード２１（実際は、修正コード２１をコンパイルした後の実行プログラム）の［関数名］＿ＩＮ関数または［関数名］＿ＯＵＴ関数が実行されたか否かを監視する（Ｓ１３１）。いずれも実行されていない場合は、ステップＳ１３０に戻る。
　ステップＳ１３１において［関数名］＿ＩＮ関数が実行された場合は、図８に示すような動作ログ２２の「関数名」欄に［関数名］を、「状態」欄にＩＮを記録する（Ｓ１３２）。例えば、図８に示す例では、最初（実行順１）にｍａｉｎ＿ＩＮ関数が実行されたため、動作ログ２２の「関数名」欄にｍａｉｎと記録され、「状態」欄にＩＮと記録されている。記録した後、ステップＳ１３０に戻る。
　ステップＳ１３１において［関数名］＿ＯＵＴ関数が実行された場合は、動作ログ２２の「関数名」欄に［関数名］を、「状態」欄にＯＵＴを記録する（Ｓ１３３）。記録した後、ステップＳ１３０に戻る。
　以上のステップＳ１３０～Ｓ１３３を繰り返すことにより、図８に示すような動作ログ２２が生成される。ステップＳ１３０において実行プログラムの終了を検知した場合は、ログを生成するステップＳ１２２を終え、図５に示したステップＳ１２３に進む。
　図５に戻り、ステップＳ１２２で生成された動作ログ２２は、動的解析結果データベース１０に格納される（Ｓ１２３）。動的依存関係解析部１１は、動的解析結果データベース１０に格納された動作ログ２２等の情報から、ソフトウェア構成要素間の動的依存関係を解析する（Ｓ１２４）。
　図９は、動的依存関係を解析するステップＳ１２４の詳細な流れを示すフローチャートである。まず、動的依存関係解析部１１は、動作ログ２２（図８参照）の実行順１の「状態」欄の内容を確認する（Ｓ１４０、Ｓ１４１）。動作ログ２２の「状態」欄にＩＮが記録されていると判定した場合、動的依存関係解析部１１は、動的依存関係解析スタック２３（以下、「第１スタック」という。）に関数が格納されているか否かを判定する（Ｓ１４２）。図８に示した例では、実行順１の「状態」欄にはＩＮが記録されているため、第１スタック２３に関数が格納されているか否かを判定することになる。
　第１スタック等のスタックは、例えば種々の情報を一時的に記憶するＳＲＡＭ、ＤＲＡＭ等の揮発性メモリを用いて実現される。
　図１０は、第１スタック２３の一例を示す図である。実行順１についてのステップＳ１４２の時点では、第１スタック２３には関数が格納されていない（図１０の実行順１の行の上の行を参照）。ステップＳ１４２において、第１スタック２３に関数が格納されていない場合、動作ログ２２の現在の実行順の関数を第１スタック２３に登録（プッシュ、ｐｕｓｈ）する（Ｓ１４４）。図示の例では、実行順１で実行される関数はｍａｉｎ関数である（図８参照）。したがって、図１０に示す第１スタック２３の実行順１に、ｍａｉｎ関数をプッシュする。このようにして、第１スタック２３は、図１０の実行順１の行に示した状態となる。
　図９のフローチャートの説明に戻ると、ステップＳ１４２において、第１スタック２３に関数が格納されている場合、動的依存関係解析部１１は、第１スタック２３に格納された関数を依存元とし、動作ログ２２の現在の実行順の関数を依存先として、動的依存関係に登録する（Ｓ１４３）。図９に示すように、ステップＳ１４３の次にも、ステップＳ１４４が実行される。
　ステップＳ１４４の次に、動的依存関係解析部１１は、動作ログ２２の実行順が最後であるか否かを判定する（Ｓ１４７）。最後である場合は、動的依存関係を解析するステップＳ１２４を終えて、図５に示すステップＳ１２５に進む。最後でない場合は、実行順をインクリメントし（Ｓ１４８）、ステップＳ１４１に戻る。
　以上では、動作ログ２２の「状態」欄にＩＮが記録されている場合、すなわち、ステップＳ１４１の判定結果がＹｅｓである場合について説明した。次に、動作ログ２２の「状態」欄にＩＮが記録されていない場合、すなわち、ステップＳ１４１の判定結果がＮｏである場合について説明する。この場合、動作ログ２２の「状態」欄にＯＵＴが記録されていることになる。この場合、ステップＳ１４２と同様に、第１スタック２３に関数が格納されているか否かを判定する（Ｓ１４５）。
　ステップＳ１４５において、第１スタック２３に関数が格納されている場合、動的依存関係解析部１１は、第１スタック２３から関数を除外（ポップ、ｐｏｐ）する（Ｓ１４６）。ステップＳ１４５において、第１スタック２３に関数が格納されていない場合、ステップＳ１４７に進む。ステップＳ１４６が実行された後も、ステップＳ１４７に進む。
　このようにして、最後の実行順まで実行順がインクリメントされ、ステップＳ１４７においてＹｅｓと判定された後は、第１スタック２３からは全ての関数がポップされ（図１０の実行順１２の行を参照）、図１１に示したような動的依存関係が得られている。そして図５に示すステップＳ１２５に進み、図１１に示したような動的依存関係が、動的依存関係データベース１２に格納される。
［２－３．総合的依存関係解析］
　図１２は、図２に示した総合的な依存関係を解析するステップＳ１０４の詳細な流れを示すフローチャートである。ステップＳ１０４では、静的依存関係データベース５に格納された情報と、動的依存関係データベース１２に格納された情報と、を統合した依存関係が得られる。まず、総合的依存関係解析部１３は、図４ｃに示すような静的依存関係データベース５に格納されている全ての依存関係を解析結果１４に格納する（Ｓ１５０）。
　次に、総合的依存関係解析部１３は、図１１に示すような動的依存関係データベース１２のＮｏ．１の行に格納された依存関係を取得する（Ｓ１５１）。図１１に示す例では、動的依存関係データベース１２のＮｏ．１の行には、ｍａｉｎ関数を依存元とし、ｔｅｓｔ１関数を依存先とする依存関係が格納されている。
　次に、総合的依存関係解析部１３は、取得した依存関係が解析結果１４の中に存在するか否かを判定する（Ｓ１５２）。存在しないと判定した場合、総合的依存関係解析部１３は、取得した依存関係を解析結果１４に格納し（Ｓ１５３）、次のステップＳ１５４に進む。ステップＳ１５２において、取得した依存関係が解析結果１４の中に存在すると判定した場合も、ステップＳ１５４に進む。
　ステップＳ１５４では、総合的依存関係解析部１３は、動的依存関係データベース１２の全ての行の依存関係を確認したか否かを判定する。全ての行の依存関係を確認し終えていない場合、総合的依存関係解析部１３は、動的依存関係データベース１２の次の行に格納された依存関係を取得する（Ｓ１５５）。その後、ステップＳ１５２に戻る。
　ステップＳ１５４において、動的依存関係データベース１２の全ての行の依存関係を確認したと判定した場合には、総合的な依存関係を解析するステップＳ１０４を終え、図２に示したステップＳ１０５に進む。
　図１３は、総合的な依存関係を解析するステップＳ１０４を終えた後の解析結果１４の一例を示す図である。図４ｃに示した静的依存関係データベース５と比較すると、図１３の解析結果１４には、Ｎｏ．４の行の依存関係が追加されている。静的解析ではｔｅｓｔ２関数から関数ポインタｐｆのアドレス先であるｆｕｎｃ関数が呼び出されたことは解析できないが、動的解析によって解析できるため、解析結果１４には静的依存関係データベース５にはない依存関係が追加されている。
［３．効果等］
　以上のように、解析装置１００は、ソフトウェアのソースコード２０の構造を静的に解析する静的解析部２と、静的解析結果に基づいてソフトウェアのオブジェクト間の依存関係を解析する静的依存関係解析部４と、ソースコード２０が示すプログラムを実行して動作ログ２２を取得し、動作ログ２２に基づいてオブジェクト間の依存関係を解析する動的依存関係解析部１１と、を備える。解析装置１００は、静的依存関係解析部４の解析結果と、動的依存関係解析部１１の解析結果と、に基づいて、オブジェクト間の依存関係を解析する。
　解析装置１００は、動的依存関係解析部１１による解析結果を用いることにより、静的解析では解析できなかったポインタ参照を介した関数間の依存関係を解析することができる。このように、解析装置１００は、動的解析と静的解析とを組み合わせることにより、従来技術より網羅的にソフトウェアの構成要素間の依存関係を解析することができる。
実施の形態２．
　図１４は、本発明の実施の形態２に係る解析装置２００の構成を示すブロック図である。実施の形態１の解析装置１００と比較すると、解析装置２００にはコード加工部６が備えられていない。また、解析装置２００の動的解析部２０９、動的解析結果データベース２１０および動的依存関係解析部２１１のそれぞれの機能または動作が、実施の形態１の場合と異なる。
　実施の形態２では、ソースコード２０の動的解析は、タスク間で送受信されるメッセージパッシングを解析することによって行われる。メッセージパッシングは、オブジェクト間の通信方式の１つであり、複数のタスクが並列に実行されるソフトウェアプログラムにおいて、タスク間で情報を共有するための手段の１つである。
　解析装置２００の動作の流れは、実施の形態１の図２のフローチャートが示す流れと同様であるが、動的解析ステップ（図２のＳ１０３）の中身のみが異なる。図１５は、実施の形態２における動的解析の流れを示すフローチャートである。実施の形態１の図５のフローチャートと比較すると、図１５には、修正コードを作成するステップと、動的依存関係を動的依存関係データベースに格納するステップがない。動的依存関係を動的依存関係データベースに格納する動作は、実施の形態２では、後述のステップＳ２２４に含まれている。
　図１６は、図１５のログを生成するステップＳ２２２の詳細な流れを示すフローチャートである。まず、動的解析部２０９が、実行プログラムの実行が終了したか否かを判定する（Ｓ２３０）。実行プログラムの実行が終了していないと判定した場合、動的解析部２０９は、タスクがメッセージを受信または送信したか否かを監視する（Ｓ２３１）。受信も送信もしていない場合は、ステップＳ２３０に戻る。
　ステップＳ２３１においてタスクがメッセージを送信したことを認めた場合、動的解析部２０９は、図１７に示すようなメッセージログ２２２に、送信されたメッセージのコンテキストＩＤと、メッセージ内容と、メッセージを送信したタスクと、を記録する（Ｓ２３２）。例えば、タスクＡがコンテキストＩＤ＝０ｘ０００１で識別されるメッセージを送信した場合、図１７のメッセージログ２２２の最上行に示すように、「コンテキストＩＤ」欄と、「メッセージ内容」欄と、「送信タスク」欄に図示のような値が記録される。記録した後、ステップＳ２３０に戻る。
　ステップＳ２３１においてタスクがメッセージを受信したと判定した場合、動的解析部２０９は、メッセージログ２２２に、メッセージを受信したタスクを記録する（Ｓ２３３）。例えば、タスクＡがコンテキストＩＤ＝０ｘ０００１で識別されるメッセージを送信した先の例において、タスクＸがこのメッセージを受信した場合、動的解析部２０９は、図１７のメッセージログ２２２の最上行に示すように、「受信タスク」欄にタスクＸと記録する。記録した後、ステップＳ２３０に戻る。
　以上のステップＳ２３０～Ｓ２３３を繰り返すことにより、図１７に示すようなメッセージログ２２２が生成される。ステップＳ２３０において実行プログラムの終了を検知した場合は、ログを生成するステップＳ２２２を終え、図１５に示したステップＳ２２３に進む。
　ステップＳ２２２で生成されたメッセージログ２２２は、動的解析結果データベース２１０に格納される（Ｓ２２３）。動的依存関係解析部２１１は、動的解析結果データベース２１０に格納されたメッセージログ２２２等の情報から、ソフトウェア構成要素間の動的依存関係を解析する（Ｓ２２４）。
　図１８は、動的依存関係を解析するステップＳ２２４の詳細な流れを示すフローチャートである。まず、動的依存関係解析部２１１は、動的解析結果データベース２１０に格納されたメッセージログ２２２の全てのメッセージについて解析を終えたか否かを判定する（Ｓ２４０）。終えていない場合、動的依存関係解析部２１１は、未解析のメッセージを１つ選択し、そのコンテキストＩＤで識別される「受信タスク」欄の記録と「送信タスク」欄の記録を取得する（Ｓ２４１）。
　次に、動的依存関係解析部２１１は、取得した受信タスクを依存元とし、かつ、送信タスクを依存先とする依存関係が動的依存関係データベース２１２に格納されているか否かを確認する（Ｓ２４２）。格納されている場合は、ステップＳ２４０に戻る。格納されていない場合は、取得した受信タスクを依存元とし、かつ、送信タスクを依存先とする依存関係を、動的依存関係データベース２１２に格納する（Ｓ２４３）。
　Ｓ２４０において、全てのメッセージについて解析を終えたと判定した場合、動的依存関係を解析するステップＳ２２４を終える。このようにして、図１９に示したような動的依存関係データベース２１２が得られる。
　以上のように、解析装置２００において、動的依存関係解析部２１１は、メッセージを送信したタスクと、前記メッセージを受信したタスクと、の間に依存関係があることを示す解析結果を生成する。動的依存関係解析部２１１は、この解析結果に基づいて動的解析を行い、解析装置２００は、静的依存関係解析部４の解析結果と、動的依存関係解析部２１１の解析結果と、に基づいて、タスク間の依存関係を解析する。
　あるタスクから発信されたメッセージパッシングが、どのタスクで受信されて処理されるかは、プログラムを実行して動作させなければ把握できず、ソースコードの構造を静的に解析しただけではわからない。解析装置２００は、動的依存関係解析部２１１による解析結果を用いることにより、静的解析では解析できなかったメッセージパッシングを介した関数間の依存関係を解析することができる。このように、解析装置２００は、動的解析と静的解析とを組み合わせることにより、従来技術より網羅的にソフトウェアの構成要素間の依存関係を解析することができる。
実施の形態３．
　図２０は、本発明の実施の形態３に係る解析装置３００の構成を示すブロック図である。実施の形態１の解析装置１００と比較すると、解析装置３００の動的解析部３０９、動的解析結果データベース３１０および動的依存関係解析部３１１のそれぞれの機能または動作が、実施の形態１の動的解析部９、動的解析結果データベース１０および動的依存関係解析部１１と異なる。
　実施の形態３では、解析装置３００は、共有メモリを介してデータの受け渡しを行うオブジェクト間の動作を解析する。共有メモリは、例えば種々の情報を一時的に記憶するＳＲＡＭ、ＤＲＡＭ等の揮発性メモリで構成される。
　解析装置３００の動作の流れは、実施の形態１の図２のフローチャートが示す流れと同様であるが、動的解析ステップ（図２のＳ１０３）の中身のみが異なる。図２１は、実施の形態３における動的解析の流れを示すフローチャートである。図２０および図２１を参照して、動的解析の流れを説明する。
　まず、コンパイル部７は、ソースコード３２０をコンパイルし、実行可能な形式の実行プログラムに変換する（Ｓ３２１）。図２２は、ソースコード３２０の一例を示す図である。ソースコード３２０内では、共有メモリが利用されている。ソースコード３２０では、構造体Ｐｏｉｎｔがグローバルに宣言され、ｍａｉｎ関数内で実体が宣言されている。ｍａｉｎ関数内からＰｒｉｎｔＰｏｉｎｔ関数が実行される際に、ＰｒｉｎｔＰｏｉｎｔ関数の引数としてアドレスが渡されている。ＰｒｉｎｔＰｏｉｎｔ関数では、渡されたアドレス先の値を読み込む処理が行われている。図２３は、ソースコード３２０内で利用されている共有メモリのアドレス一覧３２１を示す図である。
　次に、実行部８は、実行プログラムを実行する。この際、動的解析部３０９は、実行プログラムの処理を監視して、図２４に示すような関数実行ログ３２２と、図２５に示すような共有メモリアクセスログ３２３と、を生成する（Ｓ３２２）。
　関数実行ログ３２２には、関数処理の開始時刻と終了時刻が記録される。図２４に示す例では、ｍａｉｎ関数が時刻００：００から時刻００：０５まで実行され、ＰｒｉｎｔＰｏｉｎｔ関数が時刻００：０５から時刻００：２０まで実行されたことがわかる。
　共有メモリアクセスログ３２３には、アクセス先アドレスとアクセス時刻が記録される。動的解析部３０９は、共有メモリが宣言された際に確保されるアドレスを解析してアクセス先アドレスとアクセス時刻とを取得する。動的解析部３０９は、共有メモリにアクセスがあった際のアクセス先アドレスおよびアクセス時刻を共有メモリアクセスログ３２３に記録する。図２５に示す例では、アドレス０ｘ００００にアクセスがあった時刻は、００：０１および００：０６であったことがわかる。
　図２１に戻り、生成された関数実行ログ３２２および共有メモリアクセスログ３２３は、動的解析結果データベース３１０に格納される（Ｓ３２３）。動的依存関係解析部３１１は、動的解析結果データベース３１０に格納された関数実行ログ３２２および共有メモリアクセスログ３２３から、ソフトウェア構成要素間の動的依存関係を解析する（Ｓ３２４）。
　図２６は、動的依存関係を解析するステップＳ３２４の詳細な流れを示すフローチャートである。まず、動的依存関係解析部３１１は、共有メモリアクセスログ３２３からアクセス時刻を取得する（Ｓ３４０）。例えば、図２５に示した例において、アクセス時刻００：０１を取得する。他のアクセス時刻は、後のループの後に取得されるが、その際、取得済みの時刻（例えば００：０１）は取得しない。
　図２６に戻り、動的依存関係解析部３１１は、ステップＳ３４０で取得したアクセス時刻に実行されていた関数を、関数実行ログ３２２から取得する（Ｓ３４１）。先の例では、取得したアクセス時刻は００：０１であった。図２４を参照すると、アクセス時刻００：０１において実行されていた関数は、ｍａｉｎ関数である。したがって、動的依存関係解析部３１１は、関数実行ログ３２２からｍａｉｎ関数を取得する。
　次に、動的依存関係解析部３１１は、ステップＳ３４１で取得した関数を、アクセス時刻に共有メモリアドレスにアクセスしていた関数として、図２７に示すような共有メモリアクセス記録３２４に記録する（Ｓ３４２）。
　次に、動的依存関係解析部３１１は、共有メモリアクセスログ３２３の全てのアクセス時刻を取得したか否かを判定する（Ｓ３４３）。取得していないと判定した場合は、ステップＳ３４０に戻る。取得したと判定した場合は、ステップＳ３４４に進む。共有メモリアクセスログ３２３の全てのアクセス時刻を取得した場合、図２７に示すような共有メモリアクセス記録３２４が完成したことになる。
　次に、動的依存関係解析部３１１は、共有メモリアクセス記録３２４に記録された共有メモリアドレスのうち、未確認の１つを選択する（Ｓ３４４）。動的依存関係解析部３１１は、共有メモリアクセス記録３２４を確認し、選択された共有メモリアドレスに複数の関数からアクセスがあったか否かを判定する（Ｓ３４５）。
　例えば、図２７に示した例において、ステップＳ３４４で共有メモリアドレス０ｘ００００を選択した場合、選択した共有メモリアドレス０ｘ００００にはｍａｉｎ関数およびＰｒｉｎｔＰｏｉｎｔ関数の複数の関数からアクセスがあったと判定できる。
　ステップＳ３４５において複数の関数からアクセスがあったと判定した場合、アクセスした全ての関数を互いに依存元および依存先として組み合わせて、動的依存関係データベース３１２に格納する（Ｓ３４６）。先述の例では、共有メモリアドレス０ｘ００００にアクセスした関数は、ｍａｉｎ関数およびＰｒｉｎｔＰｏｉｎｔ関数であった。したがって、動的依存関係データベース３１２には、ＰｒｉｎｔＰｏｉｎｔ関数を依存元とし、ｍａｉｎ関数を依存先とする依存関係Ｎｏ．１と、ｍａｉｎ関数を依存元とし、ＰｒｉｎｔＰｏｉｎｔ関数を依存先とする依存関係Ｎｏ．２とが格納される。このようにして、図２８に示したような動的依存関係データベース３１２が得られる。
　以上のように、解析装置３００は、共有メモリを利用する。動的依存関係解析部３１１は、ソースコード３２０が示すプログラムがアクセスした共有メモリのアドレスと、アクセスした時刻と、に基づいて、関数間の依存関係を解析する。
　従来、関数呼出しによってアドレス渡しをした先の関数で共有メモリの値が書き換えられた場合、静的解析ではアドレスを介した依存関係を解析できなかった。解析装置３００は、静的解析では解析できなかった共有メモリを介した関数間の依存関係を解析することができる。このように、解析装置３００は、動的解析と静的解析とを組み合わせることにより、従来技術より網羅的にソフトウェアの構成要素間の依存関係を解析することができる。
実施の形態４．
　図２９は、本発明の実施の形態４に係る解析装置４００の構成を示すブロック図である。解析装置４００は、実施の形態１の解析装置１００の構成に加えて、依存元補完部４１１を更に備える。依存元補完部４１１は、動作ログ（図８参照）がプログラム実行の途中から取得された場合であっても、呼出し先関数から呼出し元関数に遷移する際に依存関係を解析することができる。
　解析装置４００の動作の流れは、実施の形態１の図２のフローチャートが示す流れと同様であるが、動的解析ステップ（図２のＳ１０３）の中身のみが異なる。図３０は、実施の形態４における動的解析の流れを示すフローチャートである。図３０のフローチャートも、動的依存関係を解析するステップＳ４２４以外は実施の形態１の図５のフローチャートと同様である。
　しかしながら、ログを生成するステップＳ１２２がプログラムの途中から実行されているため、動作ログがプログラム実行の途中から取得されている。図３１は、プログラムの実行の途中から取得された動作ログ４２２の一例を示す図である。動作ログ４２２には、実行順４以降の関数名と状態が記録されている。実行順１～３の関数名と状態は記録されていない。
　図３２は、動的依存関係を解析するステップＳ４２４の詳細な流れを示すフローチャートである。依存元補完部４１１は、動作ログ４２２の実行順１の「状態」欄にＩＮが記録されているか否かを判定する（Ｓ１４０、Ｓ１４１）。ＩＮが記録されていると判定した場合、ステップＳ１４２へ進むが、ステップＳ１４２以降の流れは図９に示した実施の形態１の流れと同様であるため、説明を省略する。
　ステップＳ１４１においてＩＮが記録されていないと判定した場合、依存元補完部４１１は、図３３に示す動的依存関係解析スタック（第１スタック）４２３に関数が格納されているか否かを判定する（Ｓ１４５）。第１スタック４２３に関数が格納されている場合、第１スタック４２３から関数をポップする（Ｓ１４６）。
　ポップした後、依存元補完部４１１は、第１スタック４２３が空になったか否かを判定する（Ｓ４４０）。空になったと判定した場合、依存元補完部４１１は、ステップＳ１４６でポップされた関数を、呼出し元不明関数スタック４２４（以下、「第２スタック」という。）にプッシュする（Ｓ４４１）。図３４は、第２スタックの一例を示す図である。ステップＳ４４１の後、実施の形態１で述べたステップＳ１４７（図９参照）に進む。
　ステップＳ１４５において第１スタック４２３に関数が格納されていないと判定した場合、依存元補完部４１１は、第２スタックに関数が格納されているか否かを判定する（Ｓ４４２）。第２スタックに関数が格納されていると判定した場合、依存元補完部４１１は、動作ログ４２２の現在の実行順の関数を依存元とし、第２スタックに登録されている関数を依存先として、動的依存関係に登録する（Ｓ４４３）。登録後、ステップＳ１４７に進む。
　このような実施の形態４の特徴を図示の例を用いて説明する。図示の例では、プログラムの途中から動作ログ４２２（図３１参照）を取得したため、ｔｅｓｔ２関数の開始処理より前のプログラム動作が不明となっている。そのため、実行順７でｔｅｓｔ２関数の状態がＯＵＴとなった際に（図３１参照）、第１スタック４２３（図３３）からｔｅｓｔ２関数がポップされ、第１スタック４２３内の関数がなくなってしまう。すなわち、ｔｅｓｔ２関数の呼出し元が不明である。そこで、ｔｅｓｔ２関数を呼出し元不明関数スタック（第２スタック）４２４に登録する（Ｓ４４１）。ｔｅｓｔ２関数の呼出し関数がｍａｉｎ関数であったことがわかるのは、実行順１２でｍａｉｎ関数の状態がＯＵＴとなった（図３１参照）時である。そこで、依存元関数をｍａｉｎ関数、依存先関数をｔｅｓｔ２関数として動的依存関係に登録する（Ｓ４４３）。ｔｅｓｔ３関数についても同様である。
　以上のようにして、図３５に示すような動的依存関係データベース４１２が得られる。
　上記のように、解析装置４００において、依存元補完部４１１は、関数の実行順を示す動作ログ４２２をプログラムの実行途中から取得した場合、呼出し先の関数から呼出し元の関数への遷移を示す動作ログ４２２の情報に基づいて、関数間の依存関係を補完する。
　これにより、解析装置４００は、動的解析においてプログラムが途中から実行された場合においても、呼出し元の関数を解析することができ、従来技術より網羅的にソフトウェアの構成要素間の依存関係を解析することができる。
実施の形態５．
　図３６は、本発明の実施の形態５に係る解析装置５００の構成を示すブロック図である。解析装置５００は、実施の形態１の解析装置１００の構成に加えて、タスク指定部５１１を更に備える。
　解析装置５００の動作の流れは、実施の形態１の図２のフローチャートが示す流れと同様であるが、動的解析ステップ（図２のＳ１０３）の中の動的依存関係を解析するステップ（図５のＳ１２４）のみが異なる。
　図３７は、動作ログ５２２を示す図である。動作ログ５２２は、動的解析部５０９によって作成され、動的解析結果データベース５１０に格納される。図８に示した実施の形態１の動作ログ２２と比較すると、動作ログ５２２には、「タスク」欄が更に設けられている。「タスク」欄には、「関数名」欄に記載された関数を実行するタスクが記録される。動作ログ５２２の実行順５および６に記載されたｉｎｔｅｒｒｕｐｔ関数は、割り込みタスクＩｎｔｅｒｒｕｐｔによって実行された割り込み処理の一例である。
　図３８は、実施の形態５における動的依存関係を解析するステップの詳細な流れを示すフローチャートである。実施の形態５では、ユーザが、除外タスク５３０（図３６参照）を指定する。指定されたタスクは、解析対象から除外される。ユーザは、マウス、キーボード、タッチパネル、ボタン、音声入力のためのマイク等の入力装置（図示せず）を用いて、解析装置５００に除外タスク５３０を入力する。除外タスク５３０は、動作ログ５２２の中から選択されてもよいし、予め設定されていてもよい。
　タスク指定部５１１は、まず、入力された除外タスク５３０を読み込む（Ｓ５３９）。次に、動作ログ５２２（図３７参照）の実行順１の「状態」欄と「タスク」欄とを確認する（Ｓ５４０）。「タスク」欄に記録されたタスクが除外タスク５３０に該当しない場合、ステップＳ１４１に進む（Ｓ５４１）。ステップＳ１４１～Ｓ１４８は、図９に示した実施の形態１のステップと同様であるため、説明を省略する。
　ステップＳ５４１において「タスク」欄に記録されたタスクが除外タスク５３０に該当すると判定した場合、動的依存関係の解析を省略してステップＳ１４７に進む。
　例えば、ユーザが割り込み処理についての依存関係解析を除外したいと考えた場合、ユーザは、除外タスク５３０としてＩｎｔｅｒｒｕｐｔタスクを指定する。これにより、図３７に示した動作ログ５２２の実行順５および６は解析対象から除外される。したがって、ｔｅｓｔ２関数とｉｎｔｅｒｒｕｐｔ関数との間の依存関係は出力されない。
　以上のように、解析装置５００は、解析対象のタスクを指定する除外タスク５３０の入力を受け付けるタスク指定部５１１を更に備える。タスク指定部５１１は、除外タスク５３０で指定されたタスクに関する関数間の依存関係は解析せず、それ以外のタスクに関する関数間の依存関係を解析する。これにより、本来は依存関係がない割込み関数についての解析を除外することができ、動的解析処理において解析装置５００に加えられる負荷を低減させることができる。また、ユーザがソフトウェア変更時の影響を確認する工数を削減することができる。
実施の形態６．
　図３９は、本発明の実施の形態６に係る解析装置６００の構成を示すブロック図である。解析装置６００は、実施の形態１の解析装置１００の構成に加えて、影響度補完部６１１を更に備える。
　解析装置６００の動作の流れは、実施の形態１の図２のフローチャートが示す流れと同様であるが、動的解析ステップ（図２のＳ１０３）の中の動的依存関係を解析するステップ（図５のＳ１２４）のみが異なる。解析装置６００の動作を、図４０に示した動作ログ６２２と、図４１に示した動的依存関係解析スタック（第１スタック）６２３と、を用いて説明する。
　図４２は、実施の形態６における動的依存関係を解析するステップの詳細な流れを示すフローチャートである。図９に示した実施の形態１のフローチャートと比較すると、図４２のフローチャートには、ステップＳ６４０およびステップＳ６４１が追加されている。
　影響度補完部６１１は、動作ログ６２２の実行順１の「状態」欄にＩＮが記録されているか否かを判定する（Ｓ１４０、Ｓ１４１）。ＩＮが記録されていないと判定した場合、ステップＳ１４５へ進むが、ステップＳ１４５～Ｓ１４８の流れは図９に示した実施の形態１の流れと同様であるため、説明を省略する。
　ステップＳ１４１においてＩＮが記録されていると判定した場合、動的依存関係解析部１１は、第１スタック６２３に関数が格納されているか否かを判定する（Ｓ１４２）。格納されていないと判定した場合、ステップＳ１４４に進む。
　ステップＳ１４２において第１スタック６２３に関数が格納されていると判定した場合、影響度補完部６１１は、現在の実行順の関数依存関係が動的依存関係に登録されているか否かを判定する（Ｓ６４０）。具体的には、影響度補完部６１１は、第１スタック６２３に格納された関数を依存元とし、動作ログ６２２の現在の実行順の関数を依存先とした関数依存関係が動的依存関係に登録されているか否かを判定する。
　現在の実行順の関数依存関係が動的依存関係に登録されていると判定した場合、影響度補完部６１１は、その関数依存関係についての依存強度値をインクリメントする（Ｓ６４１）。依存強度値は、２つの関数間の依存の強度を示す値である。依存強度値が大きいほど関数間の依存強度が強いことを意味する。依存強度値の初期値は例えば０である。依存強度値をインクリメントした後、ステップＳ１４４に進む。
　ステップＳ６４０において、現在の実行順の関数依存関係が動的依存関係に登録されていないと判定した場合、影響度補完部６１１は、現在の実行順の関数依存関係を動的依存関係に登録する（Ｓ１４３）。登録した後、ステップＳ１４４に進む。
　図４２に示した各ステップを行うことにより、図４３に示したような動的依存関係が得られ、動的依存関係データベース６１２に格納される。
　次に、総合的依存関係解析部６１３（図３９参照）の動作について説明する。図４４に示すようなソースコード６２０に静的解析（図３参照）を行うと、図４５に示すような静的依存関係が静的依存関係データベース５に格納される。また、ソースコード６２０に動的解析を行うと、図４３に示したような動的依存関係が動的依存関係データベース６１２に格納される。
　図４６は、総合的な依存関係を解析するステップの詳細な流れを示すフローチャートである。図１２に示した実施の形態１のフローチャートと比較すると、図４６のフローチャートには、ステップＳ６５３が追加されている。
　総合的な依存関係を解析するステップでは、総合的依存関係解析部６１３は、静的依存関係データベース５に格納されている全ての依存関係を解析結果６１４に格納する（Ｓ１５０）。次に、総合的依存関係解析部６１３は、図４３に示すような動的依存関係データベース６１２のＮｏ．１の行に格納された依存関係を取得する（Ｓ１５１）。次に、総合的依存関係解析部６１３は、取得した依存関係が解析結果６１４の中に存在するか否かを判定する（Ｓ１５２）。存在しないと判定した場合、総合的依存関係解析部６１３は、取得した依存関係を解析結果６１４に格納し（Ｓ１５３）、次のステップＳ１５４に進む。
　ステップＳ１５２において、取得した動的依存関係が解析結果６１４の中に存在すると判定した場合、取得した依存関係の依存強度値を解析結果に格納する（Ｓ６５３）。格納した後、ステップＳ１５４に進む。
　ステップＳ１５４およびステップＳ１５５は実施の形態１と同様であるため、説明を省略する。
　図４７は、総合的な依存関係を解析するステップを終えた後の解析結果６１４の一例を示す図である。
　以上のように、解析装置６００では、依存強度値が付与された解析結果６１４を得ることができる。これにより、重み付けの指標が負荷された依存関係を得ることができる。したがって、ソフトウェアを変更した場合に効率的に変更の影響範囲を確認することができ、高精度にソフトウェアの構成要素間の依存関係を解析することができる。
実施の形態７．
　図４８は、本発明の実施の形態７に係る解析装置７００の構成を示すブロック図である。解析装置７００は、総合的依存関係解析部７１３の動作と解析結果７１４の内容を除き、実施の形態１の解析装置１００と同様である。
　実施の形態６と同様のソースコード６２０（図４４参照）を解析する例について説明する。ソースコード６２０に静的解析（図３参照）を行うと、実施の形態６と同様に図４５に示したような静的依存関係が静的依存関係データベース５に格納される。また、ソースコード６２０に動的解析を行うと、図４９に示すような動的依存関係が動的依存関係データベース１２に格納される。
　図５０は、総合的な依存関係を解析するステップの詳細な流れを示すフローチャートである。まず、総合的依存関係解析部７１３は、静的依存関係データベース５に格納されている全ての依存関係を解析結果７１４に格納する（Ｓ１５０）。次に、総合的依存関係解析部７１３は、図４９に示すような動的依存関係データベース１２のＮｏ．１の行に格納された依存関係を取得する（Ｓ１５１）。次に、総合的依存関係解析部７１３は、取得した依存関係が解析結果７１４の中に存在するか否かを判定する（Ｓ１５２）。
　存在すると判定した場合、総合的依存関係解析部７１３は、取得した依存関係の重要度値をインクリメントし、その結果を解析結果７１４に格納する（Ｓ７５３）。格納した後、次のステップＳ１５４に進む。ステップＳ１５２において、取得した依存関係が解析結果７１４の中に存在しないと判定した場合も、ステップＳ１５４に進む。
　依存関係の重要度値は、その依存関係の重要度を示す値である。重要度値が大きいほどその依存関係がプログラムにとって重要であることを意味する。重要度値の初期値は例えば０である。
　ステップＳ１５４およびステップＳ１５５は実施の形態１と同様であるため、説明を省略する。
　図５１は、総合的な依存関係を解析するステップを終えた後の解析結果７１４の一例を示す図である。
　以上のように、解析装置７００では、重要度値が付与された解析結果７１４を得ることができる。これにより、重み付けの指標が負荷された依存関係を得ることができる。したがって、ソフトウェアを変更した場合に効率的に変更の影響範囲を確認することができ、高精度にソフトウェアの構成要素間の依存関係を解析することができる。
実施の形態８．
　図５２は、本発明の実施の形態８に係る解析装置８００の構成を示すブロック図である。解析装置８００は、実施の形態１の解析装置１００の構成に加えて、関数テーブル解析部８１６と、関数テーブル依存関係データベース（ＤＢ）８１７とを備える。図５２のソースコード８２０は、関数テーブルが含まれたソースコードの一例である。
　図５３は、解析装置８００の動作の流れを示すフローチャートである。解析装置８００は、図２に示した実施の形態１の動作に加えて、関数テーブル内の関数の依存関係を解析するステップＳ８０６を更に含む。
　まず、解析装置８００は、入力部１を介して、ソースコード８２０を読み込む（Ｓ１０１）。図５４は、ソースコード８２０の一例を示す図である。ソースコード８２０には、関数テーブルの記載が含まれている。関数テーブルは、本開示の「一括データ群」の一例である。
　次に、図５３に示すように、解析装置８００は、ソースコード８２０に静的解析を実行し、静的依存関係を解析する（Ｓ１０２）。図５５は、ステップＳ１０２中において生成される静的解析結果データベース８０３の一例を示す図である。静的解析結果データベース８０３には、実施の形態１の図４ｂに示したような関数一覧８０３１と、ソースコード８２０内の文字列配列を示す文字列配列８０３２と、が含まれる。ソースコード８２０には複数の文字列配列８０３２が記載されている場合があり、静的解析結果データベース８０３には、複数の文字列配列８０３２が含まれてもよい。
　図５３に戻り、静的依存関係を解析するステップＳ１０２の後、解析装置８００は、ソースコード２０に動的解析を実行し、動的依存関係を解析する（Ｓ１０３）。図５６は、ステップＳ１０３において得られた結果を格納する動的依存関係データベース１２の一例を示す図である。なお、ステップＳ１０２とステップＳ１０３の実行順は逆であってもよく、ステップＳ１０２の前にステップＳ１０３が実行されてもよい。
　図５２に示したように、静的解析結果データベース８０３および動的依存関係データベース１２は、関数テーブル解析部８１６にも入力される。関数テーブル解析部８１６は、図５３に示すように、ステップＳ１０２およびステップＳ１０３の後、関数テーブル内の関数の依存関係を解析する（Ｓ８０６）。
　図５７は、図５３に示した関数テーブル内の関数の依存関係を解析するステップＳ８０６の詳細な流れを示すフローチャートである。まず、関数テーブル解析部８１６は、動的依存関係データベース１２内の依存先関数が、静的解析結果データベース８０３内の文字列配列８０３２に登録された文字列のいずれかに一致するか否かを判定する（Ｓ８０７）。一致する場合は次のステップＳ８０８に進み、一致しない場合は関数テーブル内の関数の依存関係を解析するステップＳ８０６（図５３参照）を終える。図５５および図５６に示した例では、動的依存関係データベース１２内のｔｅｓｔ１関数が文字列配列８０３２に登録された文字列に一致するため、ステップＳ８０８に進むことになる。
　次に、静的解析結果データベース８０３の文字列配列８０３２の配列要素番号に１を設定し、文字列配列８０３２の配列要素番号１について確認する（Ｓ８０８）。
　次に、関数テーブル解析部８１６は、文字列配列８０３２の文字列のうち設定された配列要素番号に登録された文字列が、関数一覧８０３１の中にあるか否かを判定する（Ｓ８０９）。設定された配列要素番号に登録された文字列が関数一覧８０３１の中にない場合、関数テーブル内の関数の依存関係を解析するステップＳ８０６（図５３参照）を終える。
　文字列配列８０３２の文字列のうち設定された配列要素番号に登録された文字列が関数一覧８０３１の中にある場合は、関数テーブル解析部８１６は、当該文字列配列８０３２の文字列を依存先とし、動的依存関係データベース１２の依存元関数を依存元とした依存関係を関数テーブル依存関係データベース８１７に格納する（Ｓ８１０）。ステップＳ８０９およびＳ８１０を、静的解析結果データベース８０３の文字列配列８０３２の全ての配列要素番号について行う（Ｓ８１１、Ｓ８１２）。
　図５８ａは、関数テーブル内の関数の依存関係を解析するステップＳ８０６を終えた後の関数テーブル依存関係データベース８１７の一例を示す図である。関数テーブル依存関係データベース８１７が示しているのは、ソースコード８２０の特定の実行時には実行されなかったが、ランダム関数の戻り値によっては実行され得る呼出し先関数を含めた依存関係である。
　すなわち、図５４に示したようなソースコード８２０をコンパイルして実行すると、ｍａｉｎ関数内で、ランダム関数であるｒａｎｄ関数の戻り値を使って、関数テーブルｔｅｓｔＴａｂｌｅ内に登録された関数が実行される。図５６に示した動的依存関係解析の結果では、ｔｅｓｔ１関数が実行されている。そこで、図５５に示した静的解析結果データベース８０３を確認すると、ｔｅｓｔ１関数を含む文字列配列８０３２には、ｔｅｓｔ２～４関数も含まれていることがわかる。したがって、ランダム関数の戻り値によっては、ｔｅｓｔ１関数の代わりにｔｅｓｔ２～４関数が実行され得ることがわかる。このような場合、ｔｅｓｔ２～４関数の内容が変更された場合にも、ｍａｉｎ関数への影響を考慮すべきである。実施の形態８の解析装置８００を用いると、以上のようにｔｅｓｔ２～４関数とｍａｉｎ関数との依存関係をも解析することができる。
　図５８ｂは、関数テーブル内の関数の依存関係を解析するステップＳ８０６を終えた後の関数テーブル依存関係データベース８１７の他の例を示す図である。図５８ｂの表には、図５８ａの「依存元」欄および「依存先」欄に加えて、「影響度」欄が追加されている。
　影響度は、関数テーブル解析部８１６によって、例えば関数テーブル内の関数の依存関係を解析するステップＳ８０６の中で算出される。例えば、関数テーブル解析部８１６は、図５７に示したステップＳ８０７において、動的依存関係データベース１２内の依存先関数が、静的解析結果データベース８０３内の文字列配列８０３２に登録された文字列のいずれかに一致すると判定した場合、当該文字列配列８０３２に登録されている文字列の数（Ｎ１）をカウントする。図５５に示した例では、Ｎ１＝４である。カウント結果は、影響度算出情報として関数テーブル依存関係データベース８１７に格納されてもよい。
　次に、関数テーブル解析部８１６は、当該文字列配列８０３２に登録されている文字列のうち、動的依存関係データベース１２内の依存先関数に記録されているものの数（Ｎ２）をカウントする。図５５および図５６に示した例では、Ｎ２＝１である。カウント結果は、影響度算出情報として関数テーブル依存関係データベース８１７に格納されてもよい。
　文字列配列８０３２に登録されている文字列のうち、動的依存関係データベース１２内の依存先関数に記録されているものについては、関数テーブル依存関係データベース８１７の影響度を１とする。図５８ｂでは、ｔｅｓｔ１関数についての影響度が１となっている。ｔｅｓｔ１関数は、実際の動的解析において実行されているため、ｍａｉｎ関数との依存関係が強いと考えられるからである。
　文字列配列８０３２に登録されている文字列のうち、動的依存関係データベース１２内の依存先関数に記録されているもの以外については、影響度Ｘは、上記のＮ１およびＮ２を用いて、次の式（１）によって算出される。
Figure JPOXMLDOC01-appb-M000001
　図５５および図５６に示した例では、Ｎ１＝４、Ｎ２＝１であるから、図５８ｂでは、ｔｅｓｔ２関数、ｔｅｓｔ３関数およびｔｅｓｔ４関数についての影響度Ｘは、式（１）より０．２５となる。影響度Ｘは、関数テーブルの中の関数の数に応じて、依存関係に均等に割り付けられた割合値を示している。
　関数テーブル内の関数の依存関係を解析するステップＳ８０６を終えた後、総合的な依存関係を解析するステップＳ８０４が実行される。ステップＳ８０４では、図５９に示すように、静的依存関係データベース５に格納された情報と、動的依存関係データベース１２に格納された情報と、関数テーブル依存関係データベース８１７に格納された情報と、を統合した解析結果８１４が得られる。
　以上のように、解析装置８００は、動的依存関係解析部１１の解析結果において他の関数と依存関係を有するとされた関数が、ソフトウェアの関数テーブルに含まれる場合、関数テーブル内の全ての関数と当該他の関数との間に依存関係があることを示す解析結果を生成する。
　従来技術では、ポインタを介する関数テーブルによる依存関係は、静的解析によっては解析できなかった。また、従来の動的解析では、関数テーブルへの依存関係のうち実行された関数への依存関係は解析できるものの、未実行の関数への依存関係は解析できなかった。これに対して、解析装置８００は、プログラムが関数テーブルに登録されている一部の関数を実行した場合、関数テーブルに登録されている他の関数に対する依存関係を解析することができる。これにより、ソフトウェアを変更した場合に効率的に変更の影響範囲を確認することができ、高精度にソフトウェアの構成要素間の依存関係を解析することができる。
実施の形態９．
　図６０は、本発明の実施の形態９に係る解析システム１０００の構成を示すブロック図である。解析システム１０００は、解析装置９００と、外部装置９５０とを含む。本発明の解析機能は、実施の形態１の解析装置１００（図１参照）のように１つの装置内の構成要素のみで実現される必要はなく、複数の装置が協働することによって実現されてもよい。
　実施の形態９では、ソースコード２０は、解析装置９００にだけでなく、外部装置９５０にも入力される。外部装置９５０は、ソースコード２０を読み込む入力部９５１を備える。さらに、外部装置９５０は、実施の形態１の解析装置１００と同様のコード加工部６と、コンパイル部７と、実行部８と、動的解析部９と、動的解析結果データベース１０とを備える。外部装置９５０は、動的解析結果データベース１０に格納されたデータを出力する出力部９５２を更に備える。
　外部装置９５０は、図５に示す修正コードを作成するステップＳ１２０と、修正コードをコンパイルして実行プログラムに変換するステップＳ１２１と、ログ生成ステップＳ１２２と、ログを動的解析結果データベース１０に格納するステップＳ１２３とを行う。動的解析結果データベース１０に格納されたデータは、出力部９５２を介して解析装置９００に出力される。
　外部装置９５０の出力部９５２から出力されたデータは、解析装置９００の第２入力部９１６に入力される。
　解析装置９００は、実施の形態１の解析装置１００と異なり、コード加工部６、コンパイル部７、実行部８、動的解析部９、および動的解析結果データベース１０を備えていない。これらの構成要素が実現していた機能は、外部装置９５０によって実現されるからである。これらの構成要素以外については、解析装置９００は、実施の形態１の解析装置１００と同様の構成要素を備える。
　このように、本発明の解析機能を実現する構成要素は、複数の装置によって実現されてもよい。これにより、例えば、処理能力の高いコンピュータに、処理負荷の高い動的解析を担当させることができる。
　また、上記の様に動的解析を行う部分を担当する装置を設けるだけでなく、例えば、静的解析結果データベース３、動的解析結果データベース１０、静的依存関係データベース５および動的依存関係データベース５等のデータベースが、解析装置９００の外部の記憶装置に格納されてもよい。このような外部の記憶装置は、例えばネットワークを介して解析装置９００および外部装置９５０と通信可能な外部サーバであってもよい。
変形例１．
　以上の実施の形態１～９では、動的解析として、プログラムを一度だけ実行する例について説明した。しかしながら、本発明はこれに限定されず、プログラムを複数回実行して動作ログを併合または蓄積する動的解析が行われてもよい。
　図６１ａは、実行部８（図１参照）によって、ステップＳ１２２（図５参照）において特定の環境で特定の入力データを与えて実行プログラムを実行して得られた動作ログ２２ａを示す図である。図６１ｂは、他の環境でまたは他の入力データを与えて実行プログラムを実行することにより得られた動作ログ２２ｂを示す図である。図６１ａおよび図６１ｂに示すように、同じプログラムであっても、異なる実行パスを経由した場合、異なる動作ログが出力される。
　動作ログ２２ａおよび２２ｂは、動的解析結果データベース１０に格納される。動作ログ２２ａに基づいて動的依存関係を解析するステップＳ１２４（図９参照）を行うと、図６２ａに示すような動的依存関係１４ａが得られる。一方、動作ログ２２ｂに基づいて動的依存関係を解析するステップＳ１２４を行うと、図６２ｂに示すような動的依存関係１４ｂが得られる。動的依存関係１４ａと動的依存関係１４ｂとを併せることにより、図６２ｃに示すような動的依存関係１４ｃが得られる。
　このようにして、様々な実行パスを経由してプログラムを解析することができ、精度の高い解析を実現することができる。
変形例２．
　以上の実施の形態１～９では、出力部１５から解析結果を出力する解析装置について説明した。解析結果を出力する代わりに、本発明の解析装置は、解析結果をユーザに表示する表示部を備えてもよい。表示部には、最終的な総合的依存関係解析の結果だけでなく、静的構造解析結果、静的依存関係解析結果、動的解析結果および動的依存関係解析結果が表示されてもよい。表示部は、例えば液晶ディスプレイ、有機ＥＬディスプレイ、プロジェクタである。これにより、ユーザは、表示部に表示された解析結果を確認することにより、関数間の依存関係を把握することができる。例えば、依存先の関数を変更した場合、表示部に表示された依存元の関数を確認することにより、効率良くかつ高精度にソフトウェア開発を行うことができる。
　本明細書では、本発明の実施の形態および変形例を説明した。しかしながら、上記の説明は本発明の例示である。上記の実施の形態および変形例には、本発明の範囲を逸脱することなく種々の改良や変形を加えることができる。また、各実施の形態および変形例は、適宜組み合わせることができる。
　１　入力部、２　静的解析部、３　静的解析結果データベース、４　静的依存関係解析部、５　静的依存関係データベース、５　動的依存関係データベース、６　コード加工部、７　コンパイル部、８　実行部、９　動的解析部、１０　動的解析結果データベース、１１　動的依存関係解析部、１２　動的依存関係データベース、１３　総合的依存関係解析部、１４　解析結果、１５　出力部、２０　ソースコード、２１　修正コード、２２　動作ログ、２３　動的依存関係解析スタック（第１スタック）、１００　解析装置。

Claims (15)

  1. 　ソフトウェアのソースコードの構造を静的に解析し、前記ソフトウェアのオブジェクト間の依存関係を解析する第１解析部と、
    　前記ソースコードが示すプログラムを実行して前記オブジェクトの動作に関する第１情報を取得し、前記第１情報に基づいて前記オブジェクト間の依存関係を解析する第２解析部と、を備え、
    　前記第１解析部の解析結果と、前記第２解析部の解析結果と、に基づいて、前記オブジェクト間の依存関係を解析するソフトウェア解析装置。
  2. 　前記第２解析部が取得する前記第１情報は、前記オブジェクトの実行順を示す第２情報を含む、請求項１に記載のソフトウェア解析装置。
  3. 　前記第２解析部は、他のオブジェクトを呼び出すオブジェクトと、呼び出される前記他のオブジェクトと、の間に依存関係があることを示す解析結果を生成する、請求項１または２のいずれかに記載のソフトウェア解析装置。
  4. 　前記第２解析部は、メッセージを送信したオブジェクトと、前記メッセージを受信したオブジェクトと、の間に依存関係があることを示す解析結果を生成する、請求項１～３のいずれかに記載のソフトウェア解析装置。
  5. 　前記ソフトウェア解析装置は、共有メモリを更に備え、
    　前記第２解析部は、前記ソースコードが示すプログラムがアクセスした共有メモリのアドレスと、アクセスした時刻と、に基づいて、前記オブジェクト間の依存関係を解析する、請求項１～３のいずれかに記載のソフトウェア解析装置。
  6. 　前記ソフトウェア解析装置は、解析対象のタスクを指定する指示の入力を受け付けるタスク指定部を更に備え、
    　前記第２解析部は、指定された前記タスクに関する前記オブジェクト間の依存関係のみを解析する、請求項１～５のいずれかに記載のソフトウェア解析装置。
  7. 　前記第２解析部による解析過程における前記オブジェクトの実行回数に応じた重要度値を含む解析結果を生成する、
    　請求項１～６のいずれかに記載のソフトウェア解析装置。
  8. 　前記第２解析部の解析結果において他のオブジェクトと依存関係を有するとされたオブジェクトが、前記ソフトウェアの一括データ群に含まれる場合、前記一括データ群の全てと前記他のオブジェクトとの間に依存関係があることを示す解析結果を生成する、
    　請求項１～７のいずれかに記載のソフトウェア解析装置。
  9. 　前記オブジェクト間の依存関係の影響の程度を示す影響度値を算出し、
    　前記影響度値は、前記一括データ群の中のデータと前記他のオブジェクトとの間の依存関係に対して、前記一括データ群の中のデータの数に応じて均等に割り付けられた割合値である、請求項８に記載のソフトウェア解析装置。
  10. 　前記一括データ群の中のデータのうち前記第２解析部の解析結果において前記他のオブジェクトと依存関係を有するとされたオブジェクトと、前記他のオブジェクトと、の間の依存関係に対して、前記一括データ群の中の他のデータと前記他のオブジェクトとの間の依存関係に付与された前記影響度値よりも高い影響度値を付与する、
    　請求項９に記載のソフトウェア解析装置。
  11. 　前記第２情報は、オブジェクトから他のオブジェクトへの遷移を示す情報を含み、
    　前記第２解析部は、前記第２情報を前記ソースコードが示すプログラムの実行途中から取得した場合、呼出し先のオブジェクトから呼出し元のオブジェクトへの遷移を示す情報に基づいて、前記オブジェクト間の依存関係を補完する、請求項２に記載のソフトウェア解析装置。
  12. 　前記第１解析部の解析結果、前記第２解析部の解析結果、並びに、前記第１解析部の解析結果および前記第２解析部の解析結果に基づいて解析された前記オブジェクト間の依存関係のうち少なくとも１つを表示する表示装置を更に備えた、
    　請求項１～１１のいずれかに記載のソフトウェア解析装置。
  13. 　前記第１解析部の解析結果のうち前記第２解析部の解析結果の中に存在しない依存関係を、前記第２解析部の解析結果に加えた解析結果を生成する第３解析部を更に備えた、請求項１～１２のいずれかに記載のソフトウェア解析装置。
  14. 　ソフトウェアのソースコードの構造を静的に解析し、前記ソフトウェアのオブジェクト間の依存関係を解析する第１解析ステップと、
    　前記ソースコードが示すプログラムを実行して前記オブジェクトの動作に関する第１情報を取得し、前記第１情報に基づいて前記オブジェクト間の依存関係を解析する第２解析ステップと、
    　前記第１解析ステップの解析結果と、前記第２解析ステップの解析結果と、に基づいて、前記オブジェクト間の依存関係を解析するステップと、
    　を含むソフトウェア解析方法。
  15. 　請求項１４に記載のソフトウェア解析方法をコンピュータに実行させるためのソフトウェア解析プログラム。
PCT/JP2018/036996 2018-10-03 2018-10-03 ソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラム WO2020070817A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US17/268,840 US11630662B2 (en) 2018-10-03 2018-10-03 Software analysis device, software analysis method, and software analysis program
EP18936141.3A EP3862873A4 (en) 2018-10-03 2018-10-03 SOFTWARE ANALYSIS DEVICE, SOFTWARE ANALYSIS METHOD AND SOFTWARE ANALYSIS PROGRAM
JP2020550997A JP7046217B2 (ja) 2018-10-03 2018-10-03 ソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラム
PCT/JP2018/036996 WO2020070817A1 (ja) 2018-10-03 2018-10-03 ソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2018/036996 WO2020070817A1 (ja) 2018-10-03 2018-10-03 ソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラム

Publications (1)

Publication Number Publication Date
WO2020070817A1 true WO2020070817A1 (ja) 2020-04-09

Family

ID=70054712

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/036996 WO2020070817A1 (ja) 2018-10-03 2018-10-03 ソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラム

Country Status (4)

Country Link
US (1) US11630662B2 (ja)
EP (1) EP3862873A4 (ja)
JP (1) JP7046217B2 (ja)
WO (1) WO2020070817A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11360751B2 (en) * 2020-03-19 2022-06-14 Codelogic, Inc. Systems and methods for dependency analysis

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05165680A (ja) * 1991-12-13 1993-07-02 Mitsubishi Electric Corp メモリ操作トレ−ス装置
JPH10240578A (ja) * 1997-02-24 1998-09-11 Toshiba Corp マルチタスク処理装置、マルチタスク処理方法およびマルチタスク処理表示方法
JP2000284988A (ja) * 1999-03-31 2000-10-13 Toshiba Corp オブジェクト指向システム解析装置及び方法並びにオブジェクト指向システム解析用ソフトウェアを記録した記録媒体
JP2001290639A (ja) * 2000-04-07 2001-10-19 Hitachi Ltd ソフトウェア再構成方式
JP2003256235A (ja) * 2002-02-27 2003-09-10 Mitsubishi Electric Corp 分散オブジェクトシステムの試験支援システム
JP2007293383A (ja) * 2006-04-20 2007-11-08 Toshiba Corp プログラム開発支援装置及びプログラム開発支援装置の動作方法
JP2009237654A (ja) * 2008-03-26 2009-10-15 Hitachi Software Eng Co Ltd テストプログラム管理システム
JP2009540464A (ja) * 2006-06-13 2009-11-19 マイクロソフト コーポレーション 反復的な静的および動的ソフトウェア分析
JP2013156786A (ja) 2012-01-30 2013-08-15 Hitachi Automotive Systems Ltd ソフトウェアの構造可視化プログラムおよびシステム
WO2018096632A1 (ja) 2016-11-24 2018-05-31 オリンパス株式会社 データ処理装置、コンピュータ読取可能媒体、データ処理方法、及びプログラム

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7409676B2 (en) * 2003-10-20 2008-08-05 International Business Machines Corporation Systems, methods and computer programs for determining dependencies between logical components in a data processing system or network
US7496893B2 (en) * 2006-06-15 2009-02-24 International Business Machines Corporation Method for no-demand composition and teardown of service infrastructure
JP5572619B2 (ja) 2011-12-02 2014-08-13 株式会社日立製作所 トレース情報の数を算出する計算機、トレース情報の数を算出する方法及びトレース情報の数を算出させるプログラム
US8893101B2 (en) * 2012-12-21 2014-11-18 International Business Machines Corporation Hybrid dependency analysis using dynamic and static analyses
US9569334B2 (en) * 2013-03-14 2017-02-14 Whitehat Security, Inc. Techniques for traversing representations of source code
US10089218B2 (en) * 2013-03-17 2018-10-02 Typemock Ltd. Methods circuits apparatuses systems and associated computer executable code for generating a software unit test
US20140289712A1 (en) * 2013-03-20 2014-09-25 Nec Laboratories America, Inc. Effective Lifetime Dependency Analysis and Typestate Analysis
US9342300B2 (en) * 2014-03-11 2016-05-17 Blue Wolf Group, LLC Analyzing components related to a software application in a software development environment
US9483240B1 (en) * 2015-05-27 2016-11-01 Google Inc. Data binding dependency analysis
JP6440895B2 (ja) 2016-02-17 2018-12-19 三菱電機株式会社 ソフトウェア分析装置及びソフトウェア分析方法
US10339480B2 (en) * 2016-08-15 2019-07-02 International Business Machines Corporation Executing a set of business rules on incomplete data
AU2016228166A1 (en) * 2016-09-13 2018-03-29 Canon Kabushiki Kaisha Visualisation for guided algorithm design to create hardware friendly algorithms
WO2018081629A1 (en) * 2016-10-28 2018-05-03 Tala Security, Inc. Application security service

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05165680A (ja) * 1991-12-13 1993-07-02 Mitsubishi Electric Corp メモリ操作トレ−ス装置
JPH10240578A (ja) * 1997-02-24 1998-09-11 Toshiba Corp マルチタスク処理装置、マルチタスク処理方法およびマルチタスク処理表示方法
JP2000284988A (ja) * 1999-03-31 2000-10-13 Toshiba Corp オブジェクト指向システム解析装置及び方法並びにオブジェクト指向システム解析用ソフトウェアを記録した記録媒体
JP2001290639A (ja) * 2000-04-07 2001-10-19 Hitachi Ltd ソフトウェア再構成方式
JP2003256235A (ja) * 2002-02-27 2003-09-10 Mitsubishi Electric Corp 分散オブジェクトシステムの試験支援システム
JP2007293383A (ja) * 2006-04-20 2007-11-08 Toshiba Corp プログラム開発支援装置及びプログラム開発支援装置の動作方法
JP2009540464A (ja) * 2006-06-13 2009-11-19 マイクロソフト コーポレーション 反復的な静的および動的ソフトウェア分析
JP2009237654A (ja) * 2008-03-26 2009-10-15 Hitachi Software Eng Co Ltd テストプログラム管理システム
JP2013156786A (ja) 2012-01-30 2013-08-15 Hitachi Automotive Systems Ltd ソフトウェアの構造可視化プログラムおよびシステム
WO2018096632A1 (ja) 2016-11-24 2018-05-31 オリンパス株式会社 データ処理装置、コンピュータ読取可能媒体、データ処理方法、及びプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3862873A4

Also Published As

Publication number Publication date
JPWO2020070817A1 (ja) 2021-05-13
EP3862873A4 (en) 2021-10-13
US20210232392A1 (en) 2021-07-29
US11630662B2 (en) 2023-04-18
EP3862873A1 (en) 2021-08-11
JP7046217B2 (ja) 2022-04-01

Similar Documents

Publication Publication Date Title
US10896117B2 (en) Application instrumentation code extension
US10621068B2 (en) Software code debugger for quick detection of error root causes
US10719431B2 (en) Graph based code performance analysis
US7937692B2 (en) Methods and systems for complete static analysis of software for building a system
US8286149B2 (en) Apparatus for and method of implementing feedback directed dependency analysis of software applications
US9411616B2 (en) Classloader/instrumentation approach for invoking non-bound libraries
US9632769B2 (en) Software build optimization
US7614042B1 (en) System and method for selecting applicable tests in an automation testing system
US8997065B2 (en) Automatic modularization of source code
US20040054991A1 (en) Debugging tool and method for tracking code execution paths
US10545852B2 (en) Diagnostics of state transitions
US20090182756A1 (en) Database system testing
US9588872B2 (en) Discovery of code paths
Song et al. Open source vizier: Distributed infrastructure and api for reliable and flexible blackbox optimization
US10275238B2 (en) Hybrid program analysis
US10872025B1 (en) Automatic performance testing and performance regression analysis in a continuous integration environment
WO2020070817A1 (ja) ソフトウェア解析装置、ソフトウェア解析方法およびソフトウェア解析プログラム
US20100010801A1 (en) Conflict resolution and error recovery strategies
US11995096B2 (en) Creation of message serializer for event streaming platform
US8745587B2 (en) System and method for testing computer programs
Spæren Performance analysis and improvements for Apache Beam
US8010572B1 (en) Kstore scenario simulator processor and XML file
US20230004361A1 (en) Code inspection interface providing method and apparatus for implementing the method
WO2022239148A1 (ja) 等価性検査システムおよび等価性検査プログラム
Maroneze Certified Compilation and Worst-Case Execution Time Estimation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18936141

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020550997

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018936141

Country of ref document: EP

Effective date: 20210503