JP2018169998A - Analysis device, analysis method, and analysis program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To detect propagation of a variable value through a database. SOLUTION: A call statement 14c that calls a function 13a using variables 14a and 14b and variables 14a as arguments, and a call statement 14d that calls a function 13b and assigns a return value to the variable 14b are detected from a source code 14. The log 15a showing the execution history of the call statements 14c and 14d and the log 15b showing the execution history of the query are acquired. Based on the comparison between the execution history of the call statement 14c and the execution history of the query at the time of writing, the data item 16a corresponding to the argument of the function 13a is determined, and the execution history of the call statement 14d and the execution history of the query at the time of reading are compared. The data item 16b corresponding to the return value of the function 13b is determined based on. The dependency of the variables 14a and 14b is determined based on whether or not the data items 16a and 16b are the same. [Selection diagram] Fig. 1

Description

  The present invention relates to an analysis apparatus, an analysis method, and an analysis program.

  In the development of computer software, there are cases where new functions are added to software or existing functions of software are changed by modifying existing source code. At this time, there is a possibility that an existing function that is not scheduled to be changed unintentionally changes due to a modification of a part of the source code, such as a problem with an existing function that has been operating normally. Therefore, when modifying the existing source code, it is preferable to support software development so that the developer can perform the modification work while confirming the influence range of the modification.

  For example, an influence analysis device that analyzes a source code statically and detects other variables that depend on a certain variable has been proposed. The proposed impact analysis device extracts from the source code the command statement that assigns a value to the variable and the command statement that references the variable, and variable information that associates the variable name with the assignment / reference distinction and the position of the command statement. Generate. When a variable is specified by the user, the impact analyzer searches for the position of the statement that refers to the specified variable, and searches for other variables that have values assigned at the same position as the searched position. Then, the position of the command statement referring to the other searched variable is searched. The influence analysis apparatus repeatedly detects the other variables affected by the variable designated by the user by repeatedly executing the above.

  In addition, for example, a specification change support system that detects an influence on a source code due to a database change has been proposed. In the proposed specification change support system, when a data item of the table is designated by the user, the SQL statement including the designated data item is searched from the source code. The specification change support system extracts other data items described as update targets in the searched SQL sentence, and searches the source code for the SQL sentence including the extracted other data items. The specification change support system repeatedly detects the other data items affected by the data item specified by the user by repeatedly executing the above.

  Further, for example, an influence range specifying method has been proposed in which the source code is statically analyzed to specify the range of methods that are affected by a change in a variable. In the proposed method for determining the range of influence, the passing of variable values between multiple methods is detected based on the method call described in the source code, and a dependency graph showing the dependency between the multiple methods is generated. To do. When a variable used in a method is specified by the user, the propagation of the value stored in the specified variable is tracked based on the dependency graph, and the range of the method in which the value is propagated is tracked. It is determined as the influence range.

JP 2002-82802 A Japanese Unexamined Patent Publication No. 2011-60062 JP 2012-212281 A

  If the propagation of variable values is all expressed directly in the source code, the range of source code affected by a variable can be comprehensively determined by static analysis of the source code. However, some software that accesses a database uses a database access library such as an O / R (Object-Relational) mapper. The behavior of the library may be defined in a configuration file outside the source code, and the source code of the library itself may not be available. For this reason, when viewed at the source code level, the internal processing of the library may become a black box.

  In this case, there is a problem that the propagation of the value of the variable through the database cannot be completely tracked only by static analysis of the source code. For example, it is assumed that an instruction statement for calling a library method for updating a database by giving a certain variable as an argument is described in the source code of the application software. Also, it is assumed that the source code includes a statement that calls a library method for searching the database and assigns the search result to another variable. In this case, depending on the implementation method of the library method, it may be difficult to determine whether or not the value written to the database by the former method call is read by the latter method call. For this reason, it may not be possible to determine whether or not the latter variable is affected by the former variable.

  In one aspect, an object of the present invention is to provide an analysis apparatus, an analysis method, and an analysis program that can detect propagation of a value of a variable via a database.

  In one aspect, an analysis apparatus having a storage unit and a processing unit is provided. The storage unit stores source code of software that uses a module that controls access to the database. The processing unit includes, from the source code, a first variable, a first call statement that calls the first function of the module using the first variable as an argument, a second variable, and a second function of the module And a second call statement that assigns the return value of the second function to the second variable is detected. The processing unit is a log generated when the software is executed, and is generated based on the first log indicating the execution history of the first call statement and the second call statement and the module control. The second log indicating the query execution history is acquired. Based on the comparison between the execution history of the first call statement included in the first log and the execution history of the query at the time of writing included in the second log, the processing unit is configured to store a plurality of data items included in the database. Of these, the first data item corresponding to the argument of the first function is determined, and the execution history of the second call statement included in the first log and the execution of the query at the time of reading included in the second log Based on the comparison with the history, the second data item corresponding to the return value of the second function among the plurality of data items is determined. The processing unit determines a dependency relationship between the first variable and the second variable based on whether or not the first data item and the second data item are the same.

  In one aspect, an analysis method executed by a computer is provided. In one aspect, an analysis program to be executed by a computer is provided.

  In one aspect, propagation of variable values through the database can be detected.

It is a figure which shows the example of the analyzer of 1st Embodiment. It is a figure which shows the example of the information processing system of 2nd Embodiment. It is a block diagram which shows the hardware example of an analyzer. It is a figure which shows the example of the source code of analysis object. It is a figure which shows the example of the influence range via a database. It is a figure which shows the example of an influence table. It is a figure which shows the example of an untracking table. It is a figure which shows the example of a call log table. It is a figure which shows the example of DB access log table. It is a figure which shows the example of a correspondence candidate table. It is a figure which shows the example of a correspondence table. It is a figure which shows the example of an additional influence table. It is a block diagram which shows the function example of an analyzer. It is a flowchart which shows the example of a procedure of influence range analysis. It is a flowchart which shows the example of a procedure of dynamic analysis. It is a block diagram which shows the other function example of an analyzer. It is a figure which shows the example of a label table. It is a figure which shows the 1st example of a SQL sentence and a stack trace. It is a figure which shows the 2nd example of a SQL sentence and a stack trace. It is a figure which shows the 3rd example of a SQL sentence and a stack trace. It is a figure which shows the example of a production | generation of a call graph. It is a figure which shows the example of a call graph. It is a 1st figure which shows the example of a search of a call graph. It is a 2nd figure which shows the example of a search of a call graph. It is a flowchart which shows the example of a procedure of log collection point determination. It is a flowchart which shows the example of a procedure of call graph production | generation. It is a flowchart which shows the example of a procedure of a call graph search. It is a figure which shows the other example of an untracked table. It is a figure which shows the other example of a correspondence candidate table. It is a figure which shows the example of a test | inspection table.

Hereinafter, the present embodiment will be described with reference to the drawings.
[First Embodiment]
A first embodiment will be described.

FIG. 1 is a diagram illustrating an example of an analysis apparatus according to the first embodiment.
The analysis apparatus 10 according to the first embodiment analyzes a source code of existing software, determines a dependency relationship between variables, and supports a correction work of the source code. As will be described below, the analysis apparatus 10 can track the propagation of the value of a variable via a database by combining static analysis of a source code and dynamic analysis using an execution log. The analysis device 10 may be a client computer or a server computer.

  The analysis device 10 includes a storage unit 11 and a processing unit 12. The storage unit 11 may be a volatile semiconductor memory such as a RAM (Random Access Memory) or a non-volatile storage such as an HDD (Hard Disk Drive) or a flash memory. The processing unit 12 is, for example, a processor such as a CPU (Central Processing Unit) or a DSP (Digital Signal Processor). However, the processing unit 12 may include an electronic circuit for a specific application such as an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA). The processor executes a program stored in a memory such as a RAM (or the storage unit 11). The program includes an analysis program. A set of processors may be referred to as “multiprocessor” or simply “processor”.

  The storage unit 11 stores the source code 14. The source code 14 is software source code that accesses the database 16 using the module 13. The source code 14 is described in a high-level language such as an object-oriented language, for example.

  The module 13 is a library module for database access such as an O / R mapper that mutually converts object type data and relation type data. The analysis apparatus 10 may not have the source code of the module 13 in some cases. Further, the behavior of the module 13 may be controlled by a unique setting file outside the source code. Therefore, when viewed from the source code 14, the internal processing of the module 13 may be a black box. The database 16 has a plurality of data items. For example, the database 16 is a relational database having a plurality of columns as data items. However, the database 16 only needs to have a specified data format so that a plurality of data items can be identified, and may be another type of database such as a tree type or an object type.

  The processing unit 12 performs a static analysis on the source code 14. At this time, the processing unit 12 detects variables 14 a and 14 b and calling statements 14 c and 14 d from the source code 14. The call statement 14c is a command statement for calling the function 13a of the module 13 using the variable 14a as an argument. The calling statement 14d is a command statement that calls the function 13b included in the module 13 and assigns the return value of the function 13b to the variable 14b.

  The functions 13a and 13b are processing units that can be called from the outside of the module 13, and may be called by other names such as methods, procedures, and sections. As the function 13a, a processing unit in which a function for updating the database 16 using a value received as an argument is installed is assumed. As the function 13b, a processing unit in which a function of retrieving data from the database 16 and outputting a search result as a return value is assumed.

  In the above static analysis, since the internal processing of the functions 13a and 13b is unknown, it is unknown which data item in the database 16 corresponds to the argument of the call statement 14c, and the return value of the call statement 14d is It is unknown which data item in the database 16 corresponds to. Therefore, only the static analysis described above may cause the value written by the calling statement 14c to be read by the calling statement 14d, or the value written by the calling statement 14c and the value read by the calling statement 14d are irrelevant. It is difficult to judge whether there is.

  Therefore, the analysis apparatus 10 acquires a log generated when the software is executed and additionally performs dynamic analysis. Preferably, the analysis apparatus 10 sets the log collection position in a limited manner based on the result of the static analysis, and causes the software to be executed. The apparatus that executes the software may be the analysis apparatus 10 itself or another apparatus. However, the analysis apparatus 10 can also use a log collected before the static analysis.

  The processing unit 12 acquires a log 15a indicating the execution history of the call statements 14c and 14d. The log 15a can be acquired, for example, by setting the caller of the functions 13a and 13b as the log collection position. The log 15a includes, for example, an argument value specified when the function 13a is called and a return value obtained when the function 13b is called.

  Further, the processing unit 12 acquires a log 15b indicating a query execution history generated based on the control of the module 13. The log 15b can be acquired, for example, by setting the query generation function in the module 13 or another module used from the module 13 to the log collection position. The log 15b includes, for example, a generated query statement and an output from the database 16 for the query statement. The query statement is described in a query language corresponding to the type of the database 16 such as SQL. A query statement indicating writing of a value to the database 16 includes a write value in association with, for example, a data item. A query statement indicating reading of a value from the database 16 includes, for example, identification information of a data item in which the value to be read is stored, and the read value is added to the query statement.

  As an example, the log 15a includes a record indicating that the function 13a is called by specifying the argument “23”, and a record indicating that the return value “23” is acquired by calling the function 13b. The log 15b includes a record indicating a query statement for inserting data in which the value of the data item “c1” is “23” and the value of the data item “c2” is “0”. Further, the log 15b indicates a query statement for reading the values of the data items “c1” and “c2”, and includes records indicating that the read values are “23” and “0”, respectively.

  The processing unit 12 compares the execution history of the call statement 14c included in the log 15a with the execution history of the query at the time of writing included in the log 15b, and determines the data item 16a corresponding to the argument of the function 13a. For example, the processing unit 12 extracts the argument value of the function 13a from the log 15a, extracts the write value of each data item in the query statement from the log 15b, and the write value that matches the argument value is specified. Detect data items.

  Further, the processing unit 12 compares the execution history of the call statement 14d included in the log 15a with the execution history of the query at the time of reading included in the log 15b, and determines the data item 16b corresponding to the return value of the function 13b. . Data item 16b may or may not be the same as data item 16a. For example, the processing unit 12 extracts the return value of the function 13b from the log 15a, extracts the read value of each data item in the output corresponding to the query statement from the log 15b, and obtains the read value that matches the return value. Detected data item.

  As an example, “23” is extracted from the log 15a as an argument value of the function 13a, and “23” and “0” are extracted from the log 15b as write values of the data items “c1” and “c2”. In this case, since the value of the argument matches the written value of the data item “c1”, it is determined that the data item 16a corresponding to the argument of the function 13a is “c1”. Further, “23” is extracted from the log 15a as a return value of the function 13b, and “23” and “0” are extracted from the log 15b as read values of the data items “c1” and “c2”. In this case, since the return value matches the read value of the data item “c1”, the data item 16b corresponding to the return value of the function 13b is determined to be “c1”.

  The processing unit 12 determines the dependency between the variable 14a and the variable 14b based on whether or not the determined data item 16a and the data item 16b are the same. For example, when the data item 16a and the data item 16b are the same, the value of the variable 14a is written to a predetermined data item in the database 16 via the call statement 14c, and from the data item of the database 16 via the call statement 14d. May be read. In this case, the value of the variable 14a may propagate to the variable 14b, and the variable 14b is determined to be affected by the variable 14a.

  According to the analysis device 10 of the first embodiment, the variables 14a and 14b and the call statements 14c and 14d are detected from the source code 14, and the logs 15a and 15b are acquired. Based on the comparison between the execution history of the call statement 14c included in the log 15a and the execution history of the query at the time of writing included in the log 15b, the data item 16a corresponding to the argument of the function 13a is determined. The data item 16b corresponding to the return value of the function 13b is determined based on a comparison between the execution history of the call statement 14d included in the log 15a and the execution history of the query at the time of reading included in the log 15b. Based on whether or not the data item 16a and the data item 16b are the same, the dependency relationship between the variable 14a and the variable 14b is determined.

  Thus, even when the database 16 is accessed using the module 13, the data items of the database 16 corresponding to the function arguments and return values can be determined, and the limit of the static analysis of the source code 14 is compensated. Can do. Therefore, the propagation of the value of the variable via the database 16 can be traced with high accuracy, and the determination accuracy of other variables affected by a certain variable can be improved. As a result, the modification work of the source code 14 can be made efficient.

[Second Embodiment]
Next, a second embodiment will be described.
FIG. 2 is a diagram illustrating an example of an information processing system according to the second embodiment.

  The information processing system according to the second embodiment supports development work in which an existing source code of application software is modified to add or change a function. The information processing system includes an analysis device 100 and a server device 200. The analysis device 100 and the server device 200 are connected to a network 30 such as a LAN (Local Area Network).

  The analysis device 100 is a client computer used by a user. The analysis apparatus 100 displays the source code of the application software on a display, and supports the user's correction work of the source code. At this time, the analysis apparatus 100 analyzes the dependency relationship between the variables described in the source code, and determines the range of the source code affected by a certain variable. For example, when one variable is designated by the user, the analysis apparatus 100 highlights other variables and methods that are affected by the designated variable on the source code. For example, the analysis apparatus 100 displays a list of other variables and methods that are affected.

  The server device 200 is a server computer that experimentally executes application software. Since the application software of the second embodiment uses a database, a database is constructed in the server device 200. In the influence range analysis of the analysis apparatus 100, a log generated by executing the application software is used in addition to the source code. Therefore, application software is executed by the server device 200 in response to an instruction from the analysis device 100, and a log generated by the server device 200 is transferred to the analysis device 100. However, the application software may be executed by the analysis apparatus 100 instead of being executed by the server apparatus 200.

FIG. 3 is a block diagram illustrating an example of hardware of the analysis apparatus.
The analysis apparatus 100 includes a CPU 101, a RAM 102, an HDD 103, an image signal processing unit 104, an input signal processing unit 105, a medium reader 106, and a communication interface 107. The above unit is connected to a bus. The server apparatus 200 can also be implemented using the same hardware as the analysis apparatus 100.

  The CPU 101 is a processor including an arithmetic circuit that executes program instructions. The CPU 101 loads at least a part of the program and data stored in the HDD 103 into the RAM 102 and executes the program. The CPU 101 may include a plurality of processor cores, the analysis apparatus 100 may include a plurality of processors, and the following processing may be executed in parallel using a plurality of processors or processor cores. A set of processors may be referred to as “multiprocessor” or simply “processor”.

  The RAM 102 is a volatile semiconductor memory that temporarily stores programs executed by the CPU 101 and data used by the CPU 101 for calculations. Note that the analysis device 100 may include a type of memory other than the RAM, or may include a plurality of memories.

  The HDD 103 is a nonvolatile storage device that stores software programs such as an OS (Operating System) and application software, and data. The analysis apparatus 100 may include other types of storage devices such as flash memory and SSD (Solid State Drive), and may include a plurality of nonvolatile storage devices.

  The image signal processing unit 104 outputs an image to the display 111 connected to the analysis apparatus 100 in accordance with a command from the CPU 101. As the display 111, any type of display such as a CRT (Cathode Ray Tube) display, a liquid crystal display (LCD), a plasma display, an organic EL (OEL: Organic Electro-Luminescence) display, or the like can be used.

  The input signal processing unit 105 acquires an input signal from the input device 112 connected to the analysis apparatus 100 and outputs it to the CPU 101. As the input device 112, a mouse, a touch panel, a touch pad, a pointing device such as a trackball, a keyboard, a remote controller, a button switch, or the like can be used. A plurality of types of input devices may be connected to the analysis apparatus 100.

  The medium reader 106 is a reading device that reads programs and data recorded on the recording medium 113. As the recording medium 113, for example, a magnetic disk, an optical disk, a magneto-optical disk (MO), a semiconductor memory, or the like can be used. Magnetic disks include flexible disks (FD: Flexible Disk) and HDDs. The optical disc includes a CD (Compact Disc) and a DVD (Digital Versatile Disc).

  For example, the medium reader 106 copies a program or data read from the recording medium 113 to another recording medium such as the RAM 102 or the HDD 103. The read program is executed by the CPU 101, for example. The recording medium 113 may be a portable recording medium and may be used for distributing programs and data. In addition, the recording medium 113 and the HDD 103 may be referred to as computer-readable recording media.

  The communication interface 107 is an interface that is connected to the network 30 and communicates with the server device 200 via the network 30. The communication interface 107 is a wired communication interface connected to a communication device such as a switch by a cable, for example. However, a wireless communication interface connected to the base station via a wireless link may be used.

Next, the influence range analysis by the analysis apparatus 100 will be described.
FIG. 4 is a diagram illustrating an example of source code to be analyzed.
The source code 131 is an example of source code to be analyzed. The source code 131 shown in FIG. 4 is a pseudo source code based on object orientation. The source code 131 describes three classes “SampleClassA”, “SampleClassB”, and “DBAccess”. The class “SampleClassA” includes a method “methodA ()”. The class “SampleClassB” includes a method “methodD ()”. The class “DBAccess” includes methods “methodB (int)” and “methodE ()”.

  The method “methodA ()” has an integer type variable x as a local variable, and calls the method “methodB (int)” with the variable x as an argument. The method “methodD ()” has an array type variable z as a local variable, calls the method “methodE ()”, and assigns the return value to the variable z. The array used here is an ArrayList <Bean> type, and can store an arbitrary number of Bean type elements.

  The class “DBAccess” has a character string type variable b as a class member, and refers to the class “UrlMapper”. The class “UrlMapper” is an O / R mapper that mutually converts object type data and relation type data, and is a library that facilitates access to the relational database. Since the behavior of the class “UrlMapper” is separately defined by the setting file, the content of the class “UrlMapper” as viewed from the source code 131 is a black box.

  The method “methodB (int)” has an integer type variable “a” as an argument. The method “methodB (int)” calls the method “methodC (int, String)” of the class “UrlMapper” with the variables a and b as arguments. The method “methodE ()” has an array type variable y as a local variable, calls the method “methodF ()” of the class “UrlMapper”, and assigns the return value to the variable y. The method “methodE ()” outputs the value of the variable y as a return value to the caller.

FIG. 5 is a diagram illustrating an example of an influence range via a database.
Here, a call relationship between a plurality of methods described in the source code 131 is represented by a graph. The method 132a is “methodA ()” and has an integer type variable x. The method 132b is “methodB (int)” and has an integer type variable a. The method 132a calls the method 132b using the variable x as an argument. The method 132c is “methodC (int, String)”, and has an integer type variable a and a character string type variable b. The method 132b calls the method 132c using the variable a as an argument.

  The method 132d is “methodD ()” and has an array type variable z. The method 132e is “methodE ()”, has an array type variable y, and uses the value of the variable y as a return value. The method 132d calls the method 132e and assigns the return value to the variable z. The method 132f is “methodF ()”. The method 132e calls the method 132f and assigns the return value to the variable y.

  The methods 132c and 132f are O / R mapper methods. When the methods 132c and 132f are called, a JDBC (Java (registered trademark) Database Connectivity) method 132g is called through several stages of method calls. The JDBC is a module that establishes a connection with a relational database and issues a query to the relational database. When the JDBC method 132g is called, an SQL statement for operating the database table 132h is output. In the following description, the name of the database table 132h may be written as “T1”. The database table 132h has columns c1, c2, and c3.

  In the second embodiment, in response to a method call via the method 132c, the JDBC method 132g outputs an SQL statement (insert statement) that inserts a record into the database table 132h. The value of column c1 of the record to be inserted is the value of variable a of method 132c, and the value of column c2 is the value of variable b of method 132c. The value of the column c3 does not depend on the values of the variables a and b. In response to a method call via the method 132f, the JDBC method 132g outputs an SQL statement (select statement) for searching for a record from the database table 132h, and acquires the searched record. Each record to be acquired includes the values of columns c1 and c2.

  Here, according to the static analysis of the source code 131, it can be detected that the variable x of the method 132a affects the variable a of the method 132b and the variable a of the method 132b affects the variable a of the method 132c. That is, the variable a of the method 132c depends on the variable a of the method 132b, and the variable a of the method 132b depends on the variable x of the method 132a. Further, according to the static analysis, it can be detected that the return value of the method 132f affects the variable y of the method 132e, and the variable y of the method 132e affects the variable z of the method 132d. That is, the variable z of the method 132d depends on the variable y of the method 132e, and the variable y of the method 132e depends on the return value of the method 132f.

  However, method calls prior to the methods 132c and 132f cannot be traced only by static analysis of the source code 131. For this reason, it cannot be determined whether or not the variables a and b of the method 132c affect the return value of the method 132f via the relational database. Actually, the variables a and b of the method 132c affect the return value of the method 132f via the columns c1 and c2 of the database table 132h. Therefore, the variable x of the method 132a affects the variable z of the method 132d.

  In order to analyze the dependency relationship of variables via such a relational database, the analysis apparatus 100 executes a combination of static analysis using source code and dynamic analysis using logs. The analysis apparatus 100 causes the server apparatus 200 to execute software and collects a log of a method 132b that calls a method 132c that cannot be traced and a log of a method 132e that calls a method 132f that cannot be traced. Further, the analysis apparatus 100 collects a log of the JDBC method 132g that issues a query. The position where the log is collected can be limited to the above position. Then, the analysis apparatus 100 analyzes the log by a method that will be described later, and determines the relationship between the variables a and b of the method 132c and the return value of the method 132f.

  Log collection is performed, for example, by the following method. The analysis apparatus 100 places a compiled application program obtained by compiling the source code 131 in the server apparatus 200. Further, the analysis apparatus 100 creates an agent program indicating a log collection method and arranges it in the server apparatus 200. The analysis device 100 transmits a command for starting the application program to the server device 200. At this time, the analysis apparatus 100 gives an option to the command so that the agent program is inserted into the application program. The insertion of the agent program can be realized by using a byte code injection technique that partially rewrites the program at the time of activation. That is, the server device 200 rewrites the application program according to the agent program when loading the application program into the RAM. Thereby, the log can be collected at the designated position without modifying the source code 131.

  Although the relational database is used as the database in the second embodiment, other types of databases such as an XML (Extensible Markup Language) database may be used. The database to be used may be any database in which a plurality of data items are defined in advance and data manipulation is performed by a query in a predetermined format. In that case, a connection is established using a module corresponding to the type of database instead of the JDBC.

Next, an influence range analysis procedure will be described.
FIG. 6 is a diagram illustrating an example of the influence table.
The analysis apparatus 100 generates an influence table 141 (table 1) by static analysis of the source code 131. The influence table 141 includes items of a variable name, a class name, a method name, and a variable type for the variable of the influence source. In addition, the influence table 141 includes items of a variable name, a class name, a method name, and a variable type for the variable to be affected. The variable name is the name of the local variable used in the method. The class name is the name of the class to which the method belongs. The method name is the name of the method. The variable type is a variable type.

  In the influence table 141, a direct influence relation (dependency relation) between two variables is registered. By combining a plurality of influence relationships registered in the influence table 141 in a chained manner, it is possible to determine the range of other variables affected by a certain variable.

  For example, in the influence table 141, an influence relationship in which the variable x of the method “methodA ()” is the influence source and the variable “a” of the method “methodB (int)” is the influence destination is registered. Further, an influence relationship is registered in which the variable “a” of the method “methodB (int)” is the influence source and the variable “a” of the method “methodC (int, String)” is the influence destination. In addition, an influence relationship in which the return value (return) of the method “methodF ()” is an influence source and the variable y of the method “methodE ()” is an influence destination is registered. In addition, an influence relationship in which the variable y of the method “methodE ()” is the influence source and the variable z of the method “methodD ()” is the influence destination is registered. In FIG. 6, since the source codes of “methodC (int, String)” and “methodF ()” do not exist and cannot be traced, the class name is described as “DBAccess”.

FIG. 7 is a diagram illustrating an example of the untracked table.
The analysis apparatus 100 generates an untracked table 142 (table 2) together with the above-described influence table 141 by static analysis of the source code 131. The untracked table 142 indicates a method that is not defined in the source code 131 and has not been tracked in the static analysis. The untracked table 142 includes items of a class name, a method name, and a caller. The class name is the name of the class to which the caller belongs. The method name is the name of a method that is not tracked. The caller is the name of the method that called the untracked method.

  For example, it is registered in the untracked table 142 that the method “methodB (int)” of the class “DBAccess” has called the method “methodC (int, String)”. In addition, it is registered that the method “methodE ()” of the class “DBAccess” calls the method “methodF ()”.

FIG. 8 is a diagram illustrating an example of a call log table.
The analysis device 100 causes the server device 200 to collect a log (call log) at the call source registered in the untracked table 142 and acquires the call log from the server device 200. The analysis device 100 extracts data used for dynamic analysis from the acquired call log and generates a call log table 143 (table 3). The call log table 143 includes items of class name, method name, time, argument, and return value.

  The class name is the name of the class to which the caller belongs. The method name is the name of the invoked untracked method. The time is the time when an untracked method is called. The argument is the value of the argument passed to the called method. When a method without an argument is called, the argument is null. The return value is the return value obtained from the callee method. If a method with no return value is called, the return value is null.

  As an example, it is assumed that the method “methodC (int, String)” is called three times and the method “methodF ()” is called once by executing the application software. “MethodC (int, String)” is called at time 11:22:33 with an argument value of (50, α). Also, the argument value is called as (35, β) at time 11:22:43, and the argument value is called as (20, γ) at time 11:22:55. “MethodF ()” is called at time 11:27:59, and an array of {(50, α), (35, β), (20, γ)} is acquired as a return value. The array elements (50, α), (35, β), and (20, γ) are each a bean type object.

FIG. 9 is a diagram illustrating an example of a DB access log table.
The analysis apparatus 100 causes the server apparatus 200 to collect the log (DB access log) of the JDBC method 132g, and acquires the DB access log from the server apparatus 200. The collected log of the JDBC method 132g indicates the processing of the JDBC method 132g from when the connection to the relational database is opened to when it is closed. The analysis apparatus 100 extracts data used for dynamic analysis from the acquired DB access log and generates a DB access log table 144 (Table 4). The DB access log table 144 has items of time, SQL statement, stack trace, and output.

  The time is the time when the JDBC method 132g is called. The SQL statement is an SQL statement as a query output to the relational database. The stack trace is a stack trace of method calls at the time when the JDBC method 132g is called, that is, a list of names of a plurality of methods that have been called hierarchically. When the JDBC method 132g is called via the method “methodC (int, String)”, the stack trace includes the name “methodC (int, String)”. When the JDBC method 132g is called via the method “methodF ()”, the name “methodF ()” is included in the stack trace. The output is data acquired from the relational database as a response to the SQL sentence. For an SQL statement (such as an insert statement or an update statement) indicating writing to the relational database, the return value is null.

  As an example, it is assumed that the JDBC method 132g is called four times in response to the above three calls of “methodC (int, String)” and one call of “methodF ()”. At time 11:22:34, an insert statement with a write value (50, α, 50) is issued. At time 11:22:45, an insert statement having a write value (35, β, 0) is issued. At time 11:23:00, an insert statement with a write value (20, γ, 0) is issued. At time 11:28:00, a select statement for searching the values of the columns c1 and c2 is issued, and a search result of {(50, α), (35, β), (20, γ)} is acquired. ing.

FIG. 10 is a diagram illustrating an example of the correspondence candidate table.
The analysis apparatus 100 collates the call log table 143 and the DB access log table 144, extracts candidates for correspondence between the method variables and the relational database columns, and generates a correspondence candidate table 145 (Table 5). The correspondence candidate table 145 includes items of type, variable name, class name, method name, variable type, table name, column name, and time.

  The type is a type of access to the relational database, and is “Write” indicating writing or “Read” indicating reading. The type can be determined from the SQL sentence. The type of the insert statement and the update statement is “Write”, and the type of the select statement is “Read”. The variable name is the name of a variable as a method argument or return value described in the call log table 143. The class name is the name of the class to which the method belongs. The method name is the name of an untracked method. The variable type is the type of the variable registered in the variable name item. The table name is the name of the database table to which the column that may correspond to the variable belongs. The column name is the name of a column that may correspond to a variable. The time is the time of the DB access log table 144.

  The analysis apparatus 100 generates the correspondence candidate table 145 from the call log table 143 and the DB access log table 144 as follows. The analysis apparatus 100 selects one record (DB access record) from the DB access log table 144 and detects an untracked method from the stack trace included in the selected DB access record. The analysis apparatus 100 selects, from the call log table 143, a record (call record) that calls the detected untracked method immediately before DB access.

  When the SQL statement included in the selected DB access record is a write type, the analysis apparatus 100 compares the write value described in the SQL statement with the argument value included in the selected call record. If any of the written values matches the value of any of the arguments, the analysis apparatus 100 sets the column in which the written value is written and the variable in which the value of the argument is stored as a correspondence candidate. Register in table 145.

  When the SQL statement included in the selected DB access record is of the Read type, the analysis apparatus 100 obtains the value of each column in the output included in the selected DB access record and the return value included in the selected call record. Compare. When the value of any column is included as an element in the return value, the analysis apparatus 100 registers the column and a variable indicating the return value in the correspondence candidate table 145 as a correspondence candidate.

  The record of the correspondence candidate table 145 can be generated from the selected DB access record and the selected call record. Although the call log table 143 does not describe the variable name corresponding to the argument, the analysis apparatus 100 can acquire the variable name through static analysis. In addition, the column name corresponding to the write value may not be described in the DB access log table 144. However, the analysis apparatus 100 may use the column from the query template (prepared statement) set in the JDBC in the dynamic analysis. You can get the name.

  As an example, the analysis apparatus 100 selects the DB access record in the first row from the DB access log table 144 in FIG. The stack trace of the selected DB access record includes the name of the method “methodC (int, String)”. Then, the analysis apparatus 100 selects the call record on the first line including the method name and including the time immediately before the selected DB access record from the call log table 143 of FIG. The “immediately preceding time” is the time that is closest to the time of the DB access record before the time of the DB access record among the times described in the call log table 143.

  Since the SQL statement included in the DB access record is a write type, the analysis apparatus 100 uses the argument value (50, α) included in the call record and the write value (50, α, 50) included in the DB access record. Compare Since the value of the first argument matches the first and third write values, the analysis apparatus 100 sets the correspondence between the variable a and the column c1 and the correspondence between the variable a and the column c3 as candidates. Further, since the value of the second argument matches the second write value, the analysis apparatus 100 sets the correspondence between the variable b and the column c2 as candidates.

  As an example, the analysis apparatus 100 selects the DB access record on the fourth line from the DB access log table 144 of FIG. The stack trace of the selected DB access record includes the name of the method “methodF ()”. Then, the analysis apparatus 100 selects the call record on the fourth line including the method name and including the time immediately before the selected DB access record from the call log table 143 of FIG.

  Since the SQL statement included in the DB access record is of the Read type, the analysis apparatus 100 returns the return values {(50, α), (35, β), (20, γ)} included in the call record and the DB access record. Are compared with the output values {(50, α), (35, β), (20, γ)} included in. Since the value of the first column and the value of the second column are included as elements of the return value of the method, the analysis apparatus 100 associates the variable indicating the return value with the column c1, and the variable indicating the return value. And the column c2 as a candidate.

FIG. 11 is a diagram illustrating an example of the correspondence table.
The analysis apparatus 100 generalizes the correspondence candidates at each time described in the correspondence candidate table 145, determines the correspondence between variables and columns throughout all times, and generates the correspondence table 146 (Table 6). The correspondence table 146 has items of type, variable name, class name, method name, variable type, table name, and column name. These items included in the correspondence table 146 correspond to items of the same name in the correspondence candidate table 145.

  The analysis apparatus 100 extracts records having the same type, variable name, class name, method name, and variable type from the correspondence candidate table 145, adopts a combination of a table name and a column name that appear in common at all times, Register in the correspondence table 146. The analysis apparatus 100 discards the table name and column name pairs that appear only at a part of the time without adopting them.

  As an example, the analysis apparatus 100 sets the same type, variable name, class name, method name, and variable type as records in the first row, the third row, the fourth row, and the sixth row from the correspondence candidate table 145 of FIG. Extract records. There are three times in the set of extracted records. (Table T1, column c1) appears in common at three times, while (Table T1, column c3) appears only in one time. Therefore, the analysis apparatus 100 determines that the variable a corresponds to (table T1, column c1) and does not correspond to (table T1, column c3).

  Similarly, the analysis apparatus 100 extracts records of the second, fifth, and seventh lines from the correspondence candidate table 145 of FIG. 10 as records having the same type, variable name, class name, method name, and variable type. To do. There are three times in the set of extracted records. Since (table T1, column c2) appears in common at three times, the analysis apparatus 100 determines that the variable b corresponds to (table T1, column c2).

FIG. 12 is a diagram illustrating an example of the additional influence table.
The analysis apparatus 100 extracts the influence relation between the two variables by tracing the correspondence relation between the variable and the column registered in the correspondence table 146, and generates the additional influence table 147 (Table 7). Similar to the influence table 141, the additional influence table 147 includes items of a variable name, a class name, a method name, and a variable type for the variable of the influence source. Further, the additional influence table 147 includes items of a variable name, a class name, a method name, and a variable type for the variable of the influence destination. The additional influence table 147 shows the influence relation detected by the dynamic analysis although it could not be detected by the static analysis. By adding the record of the additional influence table 147 to the influence table 141, the influence relation between the variables via the relational database is completed.

  The analysis apparatus 100 selects one Write-type record from the correspondence table 146, and extracts the table name and column name of the selected Write-type record. The analysis apparatus 100 searches the correspondence table 146 for a Read type record including the extracted table name and column name. When a corresponding Read-type record is searched, the analysis apparatus 100 registers an influence relationship in which the variable of the Write-type record is an influence source and the variable of the Read-type record is an influence destination in the additional influence table 147. This means that the value of the variable at the influence source is propagated to the variable at the influence destination via the same column of the database table.

  As an example, the analysis apparatus 100 selects the write type record in the first row from the correspondence table 146 in FIG. 11 and extracts (table T1, column c1) from the selected write type record. The analysis apparatus 100 searches the correspondence table 146 for a Read-type record in the third row including (table T1, column c1), and uses the variable a as the influence source and the influence value having the return value of “methodF ()” as the influence destination. Detect relationships.

  Further, the analysis apparatus 100 selects the Write type record in the second row from the correspondence table 146 in FIG. 11 and extracts (table T1, column c2) from the selected Write type record. The analysis apparatus 100 searches the correspondence table 146 for a Read-type record in the fourth row including (table T1, column c2), and uses the variable b as the influence source and the influence value with the return value of “methodF ()” as the influence destination Detect relationships.

By adding such a record of the additional influence table 147 to the influence table 141 in FIG. 6, the following chain of influence relationships is expressed in the influence table 141.
The variable x of “methodA ()” affects the variable “a” of “methodB (int)”, and the variable “a” of “methodB (int)” affects the variable “a” of “methodC (int, String)”. The variable “a” of “methodC (int, String)” affects the return value of “methodF ()”. The return value of “methodF ()” affects the variable y of “methodE ()”, and the variable y of “methodE ()” affects the variable z of “methodD ()”.

  When these influence relationships are connected, the variable x of “methodA ()” affects the variable z of “methodD ()”. That is, the value of the variable x of “methodA ()” is propagated to the variable z of “methodD ()”. Thus, it becomes possible to express the propagation of the value of the variable via the relational database.

Next, functions of the analysis apparatus 100 will be described.
FIG. 13 is a block diagram illustrating an example of functions of the analysis apparatus.
The analysis apparatus 100 includes a source code storage unit 121, a static analysis unit 122, a log collection unit 123, a log storage unit 124, a dynamic analysis unit 125, an intermediate data storage unit 126, an analysis result storage unit 127, and an influence range output unit 128. Have The source code storage unit 121, the log storage unit 124, the intermediate data storage unit 126, and the analysis result storage unit 127 are mounted using, for example, a storage area secured in the RAM 102 or the HDD 103. The static analysis unit 122, the log collection unit 123, the dynamic analysis unit 125, and the influence range output unit 128 are implemented using, for example, program modules executed by the CPU 101.

  The source code storage unit 121 stores a source code 131 of application software. The static analysis unit 122 performs a static analysis on the source code 131 stored in the source code storage unit 121, and displays an influence table 141 (Table 1) indicating propagation of the value of the variable detected from the source code 131. Generate. When application software uses a library to access a database, the static analysis unit 122 may not be able to fully track the propagation of variable values through the database. The static analysis unit 122 stores the influence table 141 generated by the static analysis in the analysis result storage unit 127. Further, the static analysis unit 122 generates an untracked table 142 (table 2) indicating a method that could not be analyzed, and stores it in the intermediate data storage unit 126.

  When one or more untracked methods are registered in the untracked table 142, the log collection unit 123 collects a log used for dynamic analysis. For example, the log collection unit 123 places an application program and an agent program for collecting logs on the server device 200 and causes the server device 200 to execute the application program. The log collection position in the program can be limited to the minimum based on the result of the static analysis. The log collection unit 123 acquires the log generated by the server device 200 from the server device 200. The log collection unit 123 generates a call log table 143 (table 3) and a DB access log table 144 (table 4) indicating the log contents, and stores them in the log storage unit 124.

  The log storage unit 124 stores the call log table 143 and the DB access log table 144 generated by the log collection unit 123. The dynamic analysis unit 125 performs dynamic analysis using the call log table 143 and the DB access log table 144 stored in the log storage unit 124, and supplements propagation of variable values that could not be tracked by static analysis. To do.

  The dynamic analysis unit 125 compares the call log table 143 and the DB access log table 144 to generate a correspondence candidate table 145 (table 5) indicating candidates for correspondence between the variables of the untracked method and the columns of the database table. And stored in the intermediate data storage unit 126. The dynamic analysis unit 125 generalizes the generated correspondence candidate table 145 to generate a correspondence table 146 (table 6), and stores it in the intermediate data storage unit 126. The dynamic analysis unit 125 uses the generated correspondence table 146 to generate an additional influence table 147 (table 7) indicating a set of variables whose values are propagated through the same column, and stores them in the intermediate data storage unit 126. . The dynamic analysis unit 125 transfers the propagation of the value of the variable indicated by the additional influence table 147 to the influence table 141 stored in the analysis result storage unit 127.

  The intermediate data storage unit 126 stores the untracked table 142 generated by the static analysis unit 122. Further, the intermediate data storage unit 126 stores the correspondence candidate table 145, the correspondence table 146, and the additional influence table 147 generated by the dynamic analysis unit 125. The analysis result storage unit 127 stores the influence table 141 generated by the static analysis unit 122. The influence table 141 may be updated by the dynamic analysis unit 125.

  The influence range output unit 128 outputs the result of the influence range analysis based on the influence table 141 stored in the analysis result storage unit 127. For example, the influence range output unit 128 causes the display 111 to display the result of the influence range analysis. At this time, the influence range output unit 128 may cause the display 111 to display the text described in the influence table 141. Further, the influence range output unit 128 may display the source code 131 on the display 111 in a manner reflecting the result of the influence range analysis. For example, when the user selects one variable, the influence range output unit 128 searches for other variables and methods affected by the selected variable, and highlights the searched other variables and methods. It is done.

FIG. 14 is a flowchart illustrating an example of the procedure of influence range analysis.
(S10) The static analysis unit 122 reads the source code 131.
(S11) The static analysis unit 122 performs static analysis on the read source code 131. At this time, the static analysis unit 122 extracts a method and a local variable in the method from the source code 131, and tracks the propagation of the value of the variable via the method call.

(S12) The static analysis unit 122 records the propagation of the value of the variable detected by the static analysis in step S11 in the influence table 141 (Table 1).
(S13) In the static analysis in step S11, the static analysis unit 122 selects an untracked method when there is a method that has not been tracked because the content is not defined in the source code 131, such as an O / R mapper method. Record in the untracked table 142 (Table 2).

  (S14) The log collection unit 123 determines whether one or more records are recorded in the untracked table 142. When one or more records are recorded, the process proceeds to step S15, and when one record is not recorded, the process proceeds to step S21.

  (S15) The log collection unit 123 adds a log collection module for collecting the call log to the caller of the untracked method (for example, at a position immediately before calling the untracked method). For example, the log collection unit 123 generates a call log collection agent program used for bytecode injection.

  (S16) The log collection unit 123 adds a log collection module for collecting a DB access log to the JDBC that establishes a connection with the database and issues an SQL statement. For example, the log collection unit 123 generates an agent program for collecting a DB access log used for bytecode injection.

  (S17) The log collection unit 123 causes the server apparatus 200 to execute an application program. The application program to be executed may be compiled in advance, or may be compiled from the source code 131 by the analysis apparatus 100 or the server apparatus 200. For example, the log collection unit 123 places an application program and an agent program on the server device 200, and transmits a start command to the server device 200 with an option to rewrite the application program at the time of loading.

  (S18) When the execution of the application program by the server device 200 ends, the log collection unit 123 reads the call log and the DB access log from the server device 200. The log collection unit 123 records the contents of the call log in the call log table 143 (table 3). In addition, the log collection unit 123 records the contents of the DB access log in the DB access log table 144 (Table 4).

  (S19) The dynamic analysis unit 125 performs dynamic analysis using the call log table 143 and the DB access log table 144, and records the result of the dynamic analysis in the additional influence table 147 (Table 7). The procedure of dynamic analysis will be described later.

  (S20) The dynamic analysis unit 125 integrates the additional influence table 147 into the influence table 141. That is, the dynamic analysis unit 125 transcribes the propagation of the variable value recorded in the additional influence table 147 to the influence table 141. As a result, both the propagation of the section until the untracked method is called and the propagation of the section that calls the untracked method and accesses the relational database are recorded in the influence table 141, and the cooperation between the two is expressed.

  (S21) The influence range output unit 128 outputs the result of the influence range analysis based on the influence table 141. For example, the influence range output unit 128 starts from one variable, and continuously traces a plurality of records recorded in the influence table 141, so that all other variables affected by the one variable All methods can be searched exhaustively.

FIG. 15 is a flowchart illustrating an example of a procedure for dynamic analysis.
This dynamic analysis is executed in step S19 described above.
(S30) The dynamic analysis unit 125 selects one DB access record recorded in the DB access log table 144 (Table 4).

  (S31) The dynamic analysis unit 125 searches for the name of the untracked method recorded in the untracked table 142 (Table 2) from the stack trace included in the DB access record selected in Step S30.

  (S32) The dynamic analysis unit 125 determines whether any untracked method is detected from the stack trace. If any untracked method is detected, the process proceeds to step S33, and if not detected, the process proceeds to step S37.

  (S33) The dynamic analysis unit 125 indicates the call of the untracked method in step S32 from the call log table 143 (table 3), and selects the call record generated immediately before the selected DB access record.

  (S34) The dynamic analysis unit 125 determines whether the SQL statement included in the DB access record selected in step S30 is a write type that updates the relational database. The insert statement and the update statement are Write types, and the select statement is a Read type. If the SQL statement is a write type, the process proceeds to step S35, and if the SQL statement is a read type, the process proceeds to step S36.

  (S35) The dynamic analysis unit 125 compares the value of the argument included in the selected call record with the value written in the SQL statement included in the selected DB access record, and compares the variable corresponding to the argument with the database table. A candidate for correspondence with a column is generated. The dynamic analysis unit 125 records the generated correspondence relationship candidates in the correspondence candidate table 145 (table 5). Then, the process proceeds to step S37.

  (S36) The dynamic analysis unit 125 compares the return value included in the selected call record with the output value for the SQL statement included in the selected DB access record, and compares the variable corresponding to the return value with the column of the database table. A candidate for the corresponding relationship is generated. The dynamic analysis unit 125 records the generated correspondence relationship candidates in the correspondence candidate table 145.

  (S37) The dynamic analysis unit 125 determines whether all DB access records have been selected from the DB access log table 144 in step S30. If all DB access records are selected, the process proceeds to step S38. If there is an unselected DB access record, the process proceeds to step S30.

  (S38) The dynamic analysis unit 125 extracts candidates for correspondence between variables and columns that appear in common at all times from the correspondence candidate table 145, and adopts them as correct correspondences. The dynamic analysis unit 125 records the adopted correspondence relationship in the correspondence table 146 (table 6).

  (S39) The dynamic analysis unit 125 searches the correspondence table 146 for a combination of a Write-type record and a Read-type record having the same table name and column name. The dynamic analysis unit 125 combines the searched Write type record and the Read type record, and determines a propagation relationship in which the variable described in the former is an influence source and the variable described in the latter is an influence destination. To do. The dynamic analysis unit 125 records the propagation of the determined variable value in the additional influence table 147 (table 7). Then, the dynamic analysis ends.

  According to the information processing system of the second embodiment, it is possible to visualize other variables and methods that are affected by a certain variable when modifying existing source code. Therefore, the occurrence of unintended defects can be suppressed, and the correction work can be made efficient. Even if a relational database is accessed by calling a method that cannot be traced only by static analysis of the source code, the correspondence between variables and columns can be determined using dynamic analysis. Therefore, the propagation of the value of the variable via the relational database can be accurately tracked.

  Also, since only the information that is insufficient in the static analysis needs to be supplemented by the dynamic analysis, the log collection position should be limited compared to the case where the propagation of the values of all variables is tracked only by the dynamic analysis. Can do. In addition, since it is based on static analysis using source code, it becomes easy to comprehensively extract propagation of variable values. Therefore, the influence range analysis can be made efficient.

[Third Embodiment]
Next, a third embodiment will be described. Differences from the second embodiment will be mainly described, and description of the same contents as those of the second embodiment may be omitted.

  In the second embodiment, the target method (log collection point) for collecting the call log in FIG. 8 is an untracked method that could not be tracked by static analysis of the source code. This untracked method is a method that is as close as possible to the JDBC method that executes the SQL statement on the relational database. However, depending on the application software, multiple database tables and multiple types of SQL statements may be used. If the log collection points are not set properly, the correspondence between the database table columns and the variables in the source code The accuracy of attachment may be reduced. Therefore, in the third embodiment, a log collection point for collecting a call log can be appropriately set for each type of SQL statement.

First, the situation that affects the accuracy of associating the columns of the database table with the variables in the source code will be described. It is assumed that a common method (DB accessor) used for accessing a plurality of database tables is defined in the source code created by the user. By specifying an argument indicating the type of SQL statement to the DB accessor, this DB
It is possible to access different database tables via the accessor.

  For example, it is assumed that the database includes a table Ta including the column C1 and a table Tb including the column C2. The source code includes a method mc that is a DB accessor, a method ma that calls the method mc using the variable a, and a method mb that calls the method mc using the variable b. The method ma accesses the table Ta via the method mc, and the variable a affects the column C1 of the table Ta. The method mb accesses the table Tb via the method mc, and the variable b affects the column C2 of the table Tb.

  Since the method mc is closer to the JDBC method than the methods ma and mb, it is conceivable to set the method mc that is a DB accessor as a log collection point. However, in that case, a call from the method ma and a call from the method mb are not distinguished, and there is a possibility that an erroneous dependency relationship is determined. For example, there is a possibility that a dependency relationship that the variable a of the method ma affects the column C2 of the table Tb or a dependency relationship that the variable b of the method mb affects the column C1 of the table Ta may be determined.

  On the other hand, if a common method called from a plurality of methods on the source code is always excluded from the log collection point, the log collection point may be far away from the JDBC method. If the log collection point is separated from the JDBC method, the value of the variable at the log collection point is processed before it is propagated to the JDBC method, and even if the call log and the DB access log are compared, the column and the variable can be associated with each other. There are cases where it is not possible.

  Therefore, in the third embodiment, for each of a plurality of types of SQL statements, a method as close as possible to a JDBC method is set as a log collection point within a range that can be distinguished from other types of SQL statements. Therefore, in the third embodiment, log collection is performed in two stages. In the first stage, a log collection module is added to the JDBC method, and an SQL statement and a stack trace are acquired for each database access. Based on the acquired SQL statement and the stack trace, a log collection point for collecting the call log is determined for each type of SQL statement. In the second stage, the log collection module is added to the call source of the determined log collection point and the JDBC method, and the call log and the DB access log are acquired as in the second embodiment. Thus, in the third embodiment, the log collection point of the call log is determined through dynamic analysis. The determined log collection point is handled as an untracked method according to the second embodiment.

  Next, the analysis apparatus 100a of 3rd Embodiment is demonstrated. The analysis apparatus 100a is used in place of the analysis apparatus 100 of the second embodiment. Note that the analysis apparatus 100a can be mounted using the same hardware as in FIG.

FIG. 16 is a block diagram illustrating another function example of the analysis apparatus.
The analysis apparatus 100a includes a source code storage unit 121, a static analysis unit 122a, a log collection unit 123a, a log storage unit 124, a dynamic analysis unit 125, an intermediate data storage unit 126, an analysis result storage unit 127, and an influence range output unit 128. And a log collection point determination unit 129. The static analysis unit 122a, the log collection unit 123a, and the log collection point determination unit 129 are implemented using program modules executed by the CPU 101, for example.

  The static analysis unit 122a performs a static analysis on the source code stored in the source code storage unit 121, similarly to the static analysis unit 122 of the second embodiment. However, since the method of the untracked table 142 (table 2) in FIG. 7 is determined by the log collection point determination unit 129, the static analysis unit 122a may not generate the untracked table 142.

  The log collection unit 123a collects logs used by the log collection point determination unit 129 as a first stage after the static analysis by the static analysis unit 122a. The first-stage log includes an SQL statement and a stack trace when the JDBC method is executed. In addition, when the log collection point determination unit 129 determines the log collection point, the log collection unit 123a collects a log used by the dynamic analysis unit 125 as a second stage. The second-stage log includes a call log at the log collection point determined by the log collection point determination unit 129 and a DB access log. For example, the log collection unit 123a places an application program and an agent program for collecting logs on the server device 200, and causes the server device 200 to execute the application program. The log collection unit 123a acquires the log generated by the server device 200 from the server device 200. Note that the log collection unit 123a may perform the first-stage log collection before the static analysis by the static analysis unit 122a.

  The log collection point determination unit 129 analyzes the first-stage log collected by the log collection unit 123a, and obtains a log collection point (“DB association log collection method” corresponding to the untracked method of the second embodiment). Can also be said). At this time, the log collection point determination unit 129 classifies the SQL statements included in the log into a plurality of types, and generates a call graph indicating the call relationship of a plurality of methods from the stack trace included in the log. The log collection point determination unit 129 analyzes the relationship between the SQL statement type and the execution path on the call graph, and selects a method suitable for dynamic analysis for each SQL statement type. A method suitable for dynamic analysis for a certain type of SQL statement is a method that is as close as possible to a JDBC method among methods that can be easily distinguished from other types of SQL statements.

FIG. 17 is a diagram illustrating an example of a label table.
The label table 148 (table 8) is generated by the log collection point determination unit 129 and stored in the intermediate data storage unit 126. As described above, the log collection point determination unit 129 classifies the SQL sentence included in the first-stage log into a plurality of types. The label table 148 associates the types of SQL sentences with labels.

  The type of the SQL statement is determined based on the command type (INSERT or SELECT) of the database operation, the table name of the operation target table, and the column name of the operation target column. An SQL statement having the same command type, table name, and column name is the same type of SQL statement, and an SQL statement having at least one of the command type, table name, and column name is a different type of SQL statement. Condition information such as a WHERE clause does not affect the type of SQL statement.

  A part of the character string in the SQL sentence is extracted as a type part indicating the type of the SQL sentence. An SQL statement with the same type part is an SQL statement of the same type. For example, in the case of a SELECT statement, a character string from the beginning to the front of the WHERE phrase is extracted as the type part. From the SQL statement “SELECT C1, C2, C3 FROM T1 WHERE C1 = 0”, “SELECT C1, C2, C3 FROM T1” is extracted as the type part. Further, for example, in the case of an INSERT statement, a character string from the beginning to before VALUES is extracted as a type portion. From the SQL statement “INSERT INTO T1 (C1, C2, C3) VALUES (10, 20, 30)”, “INSERT INTO T1 (C1, C2, C3)” is extracted as a type part.

  A label is assigned to the type part of the SQL sentence as a simple character string. For example, “SELECT pfa_user_password_id, user_id, change_date, password, delete_flag, insert_date, insert_user, update_date, update_user FROM ppass_user_pass_user_pass_user_pass_user_pass_user_pass_user_pass_user_pass_user_pass_user_pas_user_pass is assigned to FROM_pass_1.

FIG. 18 is a diagram illustrating a first example of an SQL statement and a stack trace.
The first-stage log collected by the log collection unit 123a includes a plurality of records. These plural records are stored in the log storage unit 124. One record is generated by one execution of the JDBC method, and includes an executed SQL statement and a stack trace indicating a sequence of methods that are passed until the JDBC method is called.

  As an example, a record including an SQL statement 151 and a stack trace 152 is stored in the log storage unit 124. The SQL statement 151 is a SELECT statement and includes one table name and nine column names. The SQL sentence 151 is classified into a label S1. The stack trace 152 enumerates the methods called when executing the SQL statement 151 in the order closer to the JDBC method. The stack trace 152 includes method names of four methods between the JDBC method and the screen control method. The method executeQuery of the class BaseDao, the method findForInfo of the class PfaUserPasswordDao, the method authenticate of the class AuthBean, and the method auth of the class AuthAction are described.

FIG. 19 is a diagram illustrating a second example of an SQL statement and a stack trace.
Further, as an example, a record including an SQL statement 153 and a stack trace 154 is stored in the log storage unit 124. The SQL statement 153 is a SELECT statement and includes one table name and 11 column names. The SQL sentence 153 is classified into the label S2. The stack trace 154 is a list of methods called when executing the SQL statement 153 in order from the JDBCC method. The stack trace 154 includes method names of four methods between the JDBC method and the screen control method. A method executeQuery of the class BaseDao, a method findForInfo of the class PfmUserDao, a method checkUserRole of the class UserCheckBean, and a method auth of the class AuthAction are described.

FIG. 20 is a diagram illustrating a third example of an SQL statement and a stack trace.
Further, as an example, a record including an SQL statement 155 and a stack trace 156 is stored in the log storage unit 124. The SQL statement 155 is a SELECT statement, and includes the same table name and column name as the SQL statement 153. The SQL sentence 155 is classified into the label S2. The stack trace 156 is a list of methods called when executing the SQL statement 155 in order from the JDBCC method. The stack trace 156 includes method names of four methods between the JDBC method and the screen control method. The method executeQuery of the class BaseDao, the method findForInfo of the class PfmUserDao, the method getUserInfo of the class UserMasterReferenceBean, and the method auth of the class AuthAction are described.

FIG. 21 is a diagram illustrating a generation example of a call graph.
One subgraph can be generated from one record stored in the log storage unit 124. Each subgraph is a directed graph including a node representing a method described in the stack trace and a link representing a call relationship between the methods. A label indicating the type of SQL sentence is added to each node. By combining a plurality of subgraphs corresponding to a plurality of records, a call graph indicating the overall method call relationship is generated.

  A partial graph 161 is generated from the SQL statement 151 and the stack trace 152. The subgraph 161 includes four nodes that represent the four methods described in the stack trace 152. A label S1 is added to each node of the subgraph 161. Also, a partial graph 162 is generated from the SQL statement 153 and the stack trace 154 described above. The subgraph 162 includes four nodes that represent the four methods described in the stack trace 154. A label S <b> 2 is added to each node of the subgraph 162. A partial graph 163 is generated from the SQL statement 155 and the stack trace 156. The subgraph 163 includes four nodes that represent the four methods described in the stack trace 156. A label S2 is added to each node of the subgraph 163.

  The call graph 164 is generated by combining the partial graphs 161, 162, and 163. Nodes representing the same method between the subgraphs 161, 162, and 163 are aggregated into a single node. At this time, the label added to the aggregated node is a union of labels added to the node before aggregation. For example, nodes representing the method auth of the class AuthAction are included in the subgraphs 161, 162, and 163 in common. The call graph 164 includes a single node representing the method auth of the class AuthAction, and labels S1 and S2 are added to the node.

  The generated call graph is a graph having a node representing the JDBC method as an end point node, but does not necessarily have a tree structure. The link between the nodes has a direction from the node representing the screen control method to the node representing the JDBC method. The JDBC method side is downstream, and the screen control method side is upstream.

FIG. 22 is a diagram illustrating an example of a call graph.
The call graph 165 is an extension of the call graph 164 using another SQL statement and a stack trace. The call graph 165 includes nodes 165a, 165b, 165c, 165d, 165e, 165f, 165g, 165h, 165i, 165j, 165k, 165l, 165m, and 165n.

  Nodes 165a and 165b are nodes having a distance of 1 from the end point node indicating the JDBC method. The node 165a indicates a method executeQuery of the class BaseDao and has labels S1, S2, and S5. The next stage of the node 165a is an end point node. The node 165b indicates a method executeUpdate of the class BaseDao and has labels S3 and S4. The next stage of the node 165b is an end point node.

  Nodes 165c, 165d, 165e, and 165f are nodes having a distance of 2 from the end point node. The node 165c indicates a method findForInfo of the class PfmUserPasswordDao and has a label S1. The next stage of the node 165c is a node 165a. The node 165d indicates a method findForInfo of the class PfmUserDao and has a label S2. The next stage of the node 165d is a node 165a. The node 165e indicates a method findForKey of the class TmdTimeRecordDao and has a label S5. The next stage of the node 165e is a node 165a. The node 165f indicates a method insert of the class BaseDao and has labels S3 and S4. The next stage of the node 165f is a node 165b.

  Nodes 165g, 165h, 165i, 165j, and 165k are nodes having a distance of 3 from the end node. The node 165g indicates a method authenticate of the class AuthBean and has a label S1. The next stage of the node 165g is a node 165c. The node 165h indicates a method checkUserRole of the class UserCheckBean and has a label S2. The next stage of the node 165h is a node 165d. The node 165i indicates a method getUserInfo of the class UserMasterReferenceBean and has a label S2. The next stage of the node 165i is a node 165d. The node 165j indicates a method checkInsert of the class TimeRecordRegistBean and has a label S5. The next stage of the node 165j is a node 165e. The node 165k indicates a method insert of the class RestRegistBean and has a label S3. The next stage of the node 165k is a node 165f.

  Nodes 165l and 165m are nodes having a distance of 4 from the end node. The node 165l indicates the method auth of the class AuthAction and has labels S1 and S2. The next stage of the node 165l is nodes 165g, 165h, and 165i. The node 165m indicates a method insert of the class TimeRecordRegistBean and has labels S4 and S5. The next stage of the node 165m is nodes 165f and 165j.

  The node 165n is a node having a distance of 5 from the end point node. The node 165n indicates a method recordPortalTime of the class TimeRecordBean and has labels S3, S4, and S5. The next stage of the node 165n is nodes 165m and 165k. The call graph 165 includes a start node indicating a screen control method. The preceding stage of the nodes 165l and 165n is, for example, a start point node.

Next, a method for determining an appropriate log collection point for each type of SQL sentence using the call graph 165, that is, a method for selecting an appropriate node for each label will be described.
FIG. 23 is a first diagram illustrating a search example of a call graph.

  The log collection point determination unit 129 searches for a node having a single label in order from the end point node indicating the JDBC method. When a node having a single label is detected, the log collection point determination unit 129 associates the method indicated by the node with the label of the node. As a result, one method is assigned as a log collection point for one type of SQL sentence. In addition, the log collection point determination unit 129 deletes the label from other nodes toward the upstream (starting node direction) from the node. In principle, this is repeated until a method is associated with every label.

  For the call graph 165 described above, the log collection point determination unit 129 first checks the nodes 165a and 165b having a distance of 1. None of the labels of the nodes 165a and 165b is a single label. Next, the log collection point determination unit 129 checks the nodes 165c, 165d, 165e, and 165f at the distance 2. The label of the node 165f is not a single label, while the labels of the nodes 165c, 165d, and 165e are a single label.

  The log collection point determination unit 129 associates the method of the node 165c with the label S1, and deletes the label S1 from the nodes 165g and 165l located upstream from the node 165c. In addition, the log collection point determination unit 129 associates the method of the node 165d with the label S2, and deletes the label S2 from the nodes 165h, 165i, and 165l located upstream from the node 165d. In addition, the log collection point determination unit 129 associates the method of the node 165e with the label S5, and deletes the label S5 from the nodes 165j, 165m, and 165n located upstream from the node 165e.

At this time, since no method is associated with the labels S3 and S4, the log collection point determination unit 129 continues searching the call graph 165.
FIG. 24 is a second diagram illustrating a search example of a call graph.

  Next, the log collection point determination unit 129 examines the nodes 165g, 165h, 165i, 165j, and 165k at the distance 3. The labels of the nodes 165g, 165h, 165i, and 165j are not a single label, while the label of the node 165k is a single label. The log collection point determination unit 129 associates the method of the node 165k with the label S3, and deletes the label S3 from the node 165n located upstream from the node 165k.

  Next, the log collection point determination unit 129 inspects the nodes 165l and 165m at the distance 4. The label of node 165l is not a single label, while the label of node 165m is a single label. The log collection point determination unit 129 associates the method of the node 165m with the label S4, and deletes the label S4 from the node 165n located upstream from the node 165m. As a result, the method is associated with all the labels, and the log collection point determination unit 129 ends the search for the call graph 165.

  As described above, different methods are assigned as log collection points to different types of SQL statements. The methods of the nodes 165c, 165d, 165e, 165k, and 165m are log collection points. Therefore, in the second stage log collection, a call log when the method of the node 165c is called from the method of the node 165g is collected. In addition, a call log is collected when the method of the node 165d is called from the method of the nodes 165h and 165i. In addition, a call log when the method of the node 165e is called from the method of the node 165j is collected. In addition, a call log is collected when the method of the node 165k is called from the method of the node 165n. In addition, a call log when the method of the node 165m is called from the method of the node 165n is collected.

The log collection point determination unit 129 can generate the untracked table 142 based on the association between the label and the method.
Next, a processing procedure of the analysis apparatus 100a will be described. The influence range analysis by the analysis device 100a is different in step S13 in the influence range analysis of the second embodiment shown in FIG. The analysis apparatus 100a executes the following log collection point determination instead of step S13.

FIG. 25 is a flowchart illustrating an exemplary procedure for determining log collection points.
(S40) The log collection unit 123a adds a log collection module for collecting a DB access log to the JDBC that establishes a connection with the database and issues an SQL statement. For example, the log collection unit 123a generates a DB access log collection agent program used for bytecode injection.

  (S41) The log collection unit 123a causes the server device 200 to execute an application program. The application program to be executed may be compiled in advance, or may be compiled from source code by the analysis apparatus 100a or the server apparatus 200. For example, the log collection unit 123a places an application program and an agent program in the server device 200, and transmits a startup command to which an option for rewriting the application program is added to the server device 200 when loaded.

  (S42) When the execution of the application program by the server apparatus 200 is completed, the log collection unit 123a reads a log including an SQL statement and a stack trace from the server apparatus 200. The log collection unit 123 a stores the read log in the log storage unit 124.

(S43) The log collection point determination unit 129 analyzes the SQL statement and the stack trace in step S42 to generate a call graph. Details of the call graph generation will be described later.
(S44) The log collection point determination unit 129 searches the call graph in step S43 to determine a log collection point. Details of the call graph search will be described later.

(S45) The log collection point determination unit 129 records the log collection point determined in step S44 in the untracked table 142 (Table 2).
FIG. 26 is a flowchart illustrating an example of a procedure for generating a call graph.

This call graph generation is executed in step S43 described above.
(S50) The log collection point determination unit 129 selects one log record.
(S51) The log collection point determination unit 129 generates a partial graph from the stack trace included in the selected record. The subgraph includes nodes corresponding to the methods described in the stack trace, and links (edges) indicating the calling order of the methods. The link transition source represents the caller method, and the link transition destination represents the callee method. Therefore, the end node of the subgraph indicates the JDBC method. The direction approaching the JDBC method is downstream, and the direction away from the JDBC method is upstream.

  (S52) The log collection point determination unit 129 extracts, as a type part, a character string suitable for identifying the type of the SQL sentence from the SQL sentence included in the selected record. The type part to be extracted includes, for example, a command type, a table name, and a column name, and does not include a specific column value.

  (S53) The log collection point determination unit 129 determines whether the label corresponding to the type portion extracted in step S52 has been defined. If the extracted type part is recorded in the label table 148, it is already defined, and if it is not recorded in the label table 148, it is undefined. If the label has been defined, the process proceeds to step S55. If the label has not been defined, the process proceeds to step S54.

(S54) The log collection point determination unit 129 defines a new label corresponding to the type part extracted in step S52 and records it in the label table 148 (table 8).
(S55) The log collection point determination unit 129 adds a label corresponding to the extracted type portion to each node included in the subgraph generated in step S51.

  (S56) The log collection point determination unit 129 integrates the subgraph to which the label is added into the current call graph. Note that the initial state of the call graph is empty. Therefore, when the first partial graph is generated, the partial graph is held as a call graph. When the second and subsequent subgraphs are generated, nodes, labels, and links are aggregated by detecting common nodes between the subgraph and the current call graph.

  (S57) The log collection point determination unit 129 determines whether all records included in the log have been selected in step S50. When all the records are selected, the call graph generation ends, and when there is an unselected record, the process proceeds to step S50.

FIG. 27 is a flowchart illustrating an exemplary procedure for calling graph search.
This call graph generation is executed in step S44 described above.
(S60) The log collection point determination unit 129 sets the distance x to 1.

(S61) The log collection point determination unit 129 selects one node whose distance from the end point node (JJDB node) indicating the JDBC method is x.
(S62) The log collection point determination unit 129 determines whether the node (selected node) selected in step S61 has a single label. If it has a single label, the process proceeds to step S63. If it has no label or has two or more labels, the process proceeds to step S65.

(S63) The log collection point determination unit 129 associates the label of the selected node with the method indicated by the selected node. At most one method is associated with one label.
(S64) The log collection point determination unit 129 follows another node from the selected node upstream (in a direction away from the JDBC node), and deletes the label of the selected node from among the labels of the other node. The other nodes mentioned here are nodes that share a route from the JDBC node to the selected node. Therefore, the label of the node existing downstream from the selected node (direction approaching the JDBC node) is not deleted. Also, the labels of nodes on different branches that do not share the route from the JDBC node to the selected node are not deleted.

  (S65) The log collection point determination unit 129 determines whether there is an unselected node in step S61 among the nodes whose distance from the JDBC node is x. If there is an unselected node whose distance is x, the process proceeds to step S61, and if not, the process proceeds to step S66.

  (S66) The log collection point determination unit 129 determines whether there is a node whose distance from the JDBC node is greater than x and that has not been selected in step S61. If there is an unselected node, the process proceeds to step S67, and if not, the process proceeds to step S68.

(S67) The log collection point determination unit 129 increases the distance x by one. Then, the process proceeds to step S61, and steps S61 to S65 are executed for the updated distance x.
(S68) The log collection point determination unit 129 determines whether there is a label that is not associated with a method among the labels appearing in the call graph. If there is a label that is not associated with a method, the process proceeds to step S69, and if not, the call graph search ends.

  (S69) The log collection point determination unit 129 counts the number of labels (remaining label number) not associated with a method among the labels appearing in the call graph. The log collection point determination unit 129 determines whether or not the number of remaining labels has decreased due to the current search in steps S60 to S67. That is, it is determined whether or not a method is associated with at least one label during the current search in steps S60 to S67. When the number of remaining labels decreases, it returns to step S60 and performs the search of steps S60-S67 again. If the number of remaining labels has not decreased, the call graph search ends. Note that the search in steps S60 to S67 is repeatedly executed because a node having two or more labels may be changed to a node having a single label by the label deletion in step S64, and the node satisfying the condition in step S62. This is because there is a possibility of increasing.

  In this way, the analysis apparatus 100a can generate the untracked table 142 (table 2) indicating the determined log collection points. The procedure of the influence range analysis after generating the untracked table 142 is the same as that of the second embodiment. However, the analysis apparatus 100a refers to the information indicating the correspondence relationship between the SQL statement type and the method, and generates the correspondence table 146 (table 6) from the correspondence candidate table 145 (table 5) (step in FIG. 15). The accuracy of S38) can also be improved. Hereinafter, such modifications will be described.

FIG. 28 is a diagram illustrating another example of the untracked table.
The log collection point determination unit 129 can generate an untracked table 142a instead of the untracked table 142 of the second embodiment. The untracked table 142a includes items of class name, method name, caller, and label. The class name, method name, and caller items are the same as those in the untracked table 142 in FIG. The class name and method name of the untracked table 142a are the class name and method name of the log collection point determined by the log collection point determination unit 129. The label of the untracked table 142a is a label associated with the log collection point, and identifies the type of SQL sentence registered in the label table 148.

Next, the situation that affects the accuracy of step S38 of the dynamic analysis of FIG. 15 will be described using the call graph 165 of FIGS.
FIG. 29 is a diagram illustrating another example of the correspondence candidate table.

  The correspondence candidate table 145a is generated by the same method as the correspondence candidate table 145 of the second embodiment. In the correspondence candidate table 145a of FIG. 29, two methods, method insert and method findForKey, are associated with the reading of the column record_time. This is because, in addition to the method findForKey associated with the label S5, the method insert associated with the label S4 is included in the stack trace when the SQL statement belonging to the label S5 is executed.

  This is also explained in FIG. 24 because the log collection point of label S4 exists on the execution path of label S5. As described above, log call points corresponding to other types of SQL statements may be set on the execution path of a certain type of SQL statement also by the call graph search of the third embodiment. In that case, unnecessary propagation relations may be output. In the correspondence candidate table 145a, the correspondence between the reading of the column record_time and the method findForKey is correct, and the correspondence between the reading of the column record_time and the method insert is incorrect.

  Therefore, when generating the correspondence table 146 from the correspondence candidate table 145a, the analysis apparatus 100a filters inappropriate records among the records registered in the correspondence candidate table 145a by using information on the type of SQL sentence.

FIG. 30 is a diagram illustrating an example of an inspection table.
The dynamic analysis unit 125 generates an inspection table 149 from the label table 148. The inspection table 149 includes items of label, type, table name, and column name. One record of the inspection table 149 is generated from one record of the label table 148.

  The label of the inspection table 149 is the label of the label table 148. The type of the inspection table 149 is Read or Write, and is determined from the command type included in the SQL statement in the label table 148. The type of the SELECT statement is Read, and the type of the INSERT statement is Write. The table name of the inspection table 149 is a table name included in the SQL statement of the label table 148. The column name of the inspection table 149 is a column name included in the SQL statement of the label table 148.

  The dynamic analysis unit 125 collates the untracked table 142a and the inspection table 149, and determines the type, table name, and column name corresponding to the class name and method name. The dynamic analysis unit 125 ignores the record in the correspondence candidate table 145a that does not match this correspondence.

  From the untracked table 142a and the inspection table 149, for example, for the label S4, writing of the column record_time of the table tmd_time_record is associated with the method insert of the class TimeRecordRegistBean. In addition, for the label S5, reading of the column record_time of the table tmd_time_record is associated with the method findForKey of the class TmdTimeRecordDao.

  The correspondence candidate table 145a includes a record having a type of Write, a class name of TimeRecordRegistBean, a method name of insert, a table name of tmd_time_record, and a column name of record_time, and this record is valid. The correspondence candidate table 145a includes a record having a type of Read, a class name of TimeRecordRegistBean, a method name of insert, a table name of tmd_time_record, and a column name of record_time. This record is valid. On the other hand, the correspondence candidate table 145a includes a record with a type of Read, a class name of TmdTimeRecordDao, a method name of findForKey, a table name of tmd_time_record, and a column name of record_time. is there.

  Thus, by adding a label to the untracked table 142a, when generating the correspondence table 146 from the correspondence candidate table 145a, it is possible to filter inappropriate records in the correspondence candidate table 145a and improve accuracy. Can do.

  According to the analysis device 100a of the third embodiment, the same effect as the analysis device 100 of the second embodiment can be obtained. Furthermore, according to the analysis apparatus 100a, the relationship between the type of SQL statement and the method call is analyzed through preliminary log collection. Then, a log collection point for collecting a call log including an argument and a return value is appropriately set for each type of SQL statement. Therefore, it is possible to suppress estimation of an erroneous propagation relationship caused by setting a shared method used for executing a plurality of types of SQL statements as a log collection point. Further, association failure due to setting a method far from the JDBC method as a log collection point can be suppressed.

DESCRIPTION OF SYMBOLS 10 Analysis apparatus 11 Memory | storage part 12 Processing part 13 Module 13a, 13b Function 14 Source code 14a, 14b Variable 14c, 14d Call statement 15a, 15b Log 16 Database 16a, 16b Data item

Claims (10)

A storage unit for storing source code of software that uses a module for controlling access to a database;
From the source code, a first variable, a first call statement that calls the first function of the module using the first variable as an argument, a second variable, and a second function of the module And a second call statement that assigns the return value of the second function to the second variable, and
A log generated when the software is executed, the log generated based on the control of the module and the first log indicating the execution history of the first call statement and the second call statement A second log showing the query execution history,
Based on the comparison between the execution history of the first call statement included in the first log and the execution history of the query at the time of writing included in the second log, the plurality of data items included in the database The first data item corresponding to the argument of the first function is determined, and the execution history of the second call statement included in the first log and the reading included in the second log Determining a second data item corresponding to the return value of the second function among the plurality of data items based on a comparison with the execution history of the query at the time,
A processing unit for determining a dependency relationship between the first variable and the second variable based on whether the first data item and the second data item are the same;
Analyzing device. In the determination of the dependency relationship, the processing unit determines that the second variable is dependent on the first variable when the first data item and the second data item are the same. To
The analysis device according to claim 1. In the detection from the source code, the processing unit includes a third variable, a first statement that updates a value of the first variable based on a value of the third variable, and a fourth variable. And a second statement that updates the value of the fourth variable based on the value of the second variable,
In the determination of the dependency relationship, the processing unit determines the dependency between the third variable and the fourth variable based on whether the first data item and the second data item are the same. Further determine the relationship,
The analysis device according to claim 1. In the acquisition of the first log, the processing unit is configured to generate the first log when the software is executed in response to detection of the first call statement and the second call statement. Set the log recording position in the software,
The analysis device according to claim 1. The execution history of the second log includes stack trace information indicating a sequence of functions that are called in a chain manner until the time of query execution,
In the determination of the first data item, the processing unit extracts the execution history in which the stack trace information includes the identification information of the first function from the second log and extracts the first call In the determination of the second data item as compared with the statement execution history, the processing unit obtains an execution history in which the identification information of the second function is included in the stack trace information from the second log. Extract and compare with the execution history of the second call statement;
The analysis device according to claim 1. Before the processing unit acquires the first log and the second log,
Obtaining a third log including a plurality of records each including an executed query and stack trace information indicating a sequence of functions called in a chained manner until the query is executed;
Classifying the query included in the third log into a plurality of query types, and generating a graph showing a calling relationship of a plurality of functions using stack trace information included in the third log;
From the graph, a specific function that is used to execute one query type among the plurality of query types and is not used to execute another query type is selected.
Controlling to obtain the first log for a call to the specific function;
The analysis device according to claim 1. In the selection of the specific function, the processing unit preferentially selects, as the specific function, a function that is used in execution of one query type and is not used in execution of another query type and that has a slow call order. ,
The analysis device according to claim 6. In the determination of the first data item and the second data item, the processing unit, based on a query type corresponding to the specific function, the first data item and the first data item among the plurality of data items. Narrow down the 2 data items,
The analysis device according to claim 6. An analysis method executed by a computer,
From a source code of software that uses a module that controls access to a database, a first call, a first call statement that calls the first function of the module using the first variable as an argument, 2 variables and a second call statement that calls the second function of the module and assigns the return value of the second function to the second variable;
A log generated when the software is executed, the log generated based on the control of the module and the first log indicating the execution history of the first call statement and the second call statement A second log showing the query execution history,
Based on the comparison between the execution history of the first call statement included in the first log and the execution history of the query at the time of writing included in the second log, the plurality of data items included in the database The first data item corresponding to the argument of the first function is determined, and the execution history of the second call statement included in the first log and the reading included in the second log Determining a second data item corresponding to the return value of the second function among the plurality of data items based on a comparison with the execution history of the query at the time,
Determining a dependency between the first variable and the second variable based on whether the first data item and the second data item are the same;
analysis method. On the computer,
From a source code of software that uses a module that controls access to a database, a first call, a first call statement that calls the first function of the module using the first variable as an argument, 2 variables and a second call statement that calls the second function of the module and assigns the return value of the second function to the second variable;
A log generated when the software is executed, the log generated based on the control of the module and the first log indicating the execution history of the first call statement and the second call statement A second log showing the query execution history,
Based on the comparison between the execution history of the first call statement included in the first log and the execution history of the query at the time of writing included in the second log, the plurality of data items included in the database The first data item corresponding to the argument of the first function is determined, and the execution history of the second call statement included in the first log and the reading included in the second log Determining a second data item corresponding to the return value of the second function among the plurality of data items based on a comparison with the execution history of the query at the time,
Determining a dependency between the first variable and the second variable based on whether the first data item and the second data item are the same;
Analysis program that executes processing.

Images