JP2015069332A - Object range extractor, static verification system, object range extraction method, and object range extraction program for extracting object range to be subjected to static verification by static verification device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an object range extractor capable of displaying, about a matter to point out due to a difference between two entire source files, a matter to point out about one other than a module having a difference between the two entire source files in static verification.SOLUTION: The object range extractor includes object range generation means for generating object range information limiting a forth module in which a definition difference can occur due to a difference among second modules, on the basis of dependency information indicating dependency between a plurality of first modules included in a first entire source file, and difference information indicating the presence or absence of a difference between a second module and a third module that is among the plurality of first modules, has the common name with that of the second module, and is included in a second entire source file.

Description

  The present invention relates to a target range extraction device, a static verification system, a target range extraction method, and a target range extraction program that extract a target range that causes a static verification device to perform static verification.

  Software static analysis (also referred to as “static verification”, “static code analysis”, or “static program analysis”) is a type of computer software (program) analysis method that operates an executable file. It is to analyze without letting.

  In software development, static analysis of software code is performed to improve software quality. Generally, a source code file is repeatedly changed for reasons such as bug correction, software function change, and function addition.

  In the source code static analysis process, even if only a part of the source code is changed, static analysis is often performed on all source code files in order to improve the quality of the software. At this time, in the source code file whose contents have not been changed after the previous static analysis, the same static analysis result as the previous one is displayed. In particular, when the source code is large, a large amount of indication items are displayed in the static analysis result, and the confirmation work is complicated. In static analysis of the source code, the user of the static analysis system must check again because it cannot distinguish the pointed item confirmed in the previous static analysis result as the same pointed item. Inefficient.

  The source code analysis support device of Patent Document 1 extracts the difference between the source code before the change and the source code after the change, specifies a range where automatic analysis should be performed, and performs automatic analysis only on the specified portion. Do. At this time, the source code analysis support apparatus of Patent Document 1 does not redisplay the same indication item for the source code portion without change.

  As a result of the above operation, the source code analysis support device of Patent Document 1 reduces the display amount of the indication items in the static analysis result.

  The static analysis technique is applicable not only to a compiler language but also to a program written in an arbitrary language such as an interpreter language or an assembler language. Therefore, in the following, program code written in an arbitrary language is referred to as “source code”. A file including “source code” is referred to as “source code file” or “source file”. Further, an entire source file describing one executable program is referred to as an “entire source file”, and individual source files included in one “entire source file” are referred to as “partial source files”. A component of one whole source file is called a “module”. The module is, for example, a partial source file or a procedure in a procedural programming language (hereinafter simply referred to as “procedure”). The module is identified by the name of the module (hereinafter referred to as “module name”). The module name is, for example, a file name of a partial source file or a procedure name (for example, a function name).

JP 2009-146207 A (9th page, FIGS. 1 and 11)

Depending on the dependency between the source code that has been changed and the source code that has not been changed, additional indications may be required even for source code that has not been changed. Note that the “dependency” of the source code refers to a part of a certain source code (for example, a module such as a procedure or a partial source file) that is referenced from another source code (for example, a procedure call or a partial source file import). ) Means. The source code analysis support apparatus of Patent Literature 1 limits the target of executing static analysis to a source code portion having a difference. In other words, even if there are points to be added, there are no indications for the parts with no difference. Therefore, the source code analysis support apparatus of Patent Document 1 has a problem that not all of the indication items required by changing the source code may be displayed.
(Object of invention)
The object of the present invention relates to matters that need to be pointed out due to differences between two whole source files in static verification, and points that are necessary other than for modules that have differences between two whole source files An object of the present invention is to provide a target range extraction device, a static verification system, a target range extraction method, and a target range extraction program that can display items.

  The target range extraction apparatus of the present invention includes dependency relationship information indicating a mutual dependency relationship among a plurality of first modules included in the first entire source file, a second module among the plurality of first modules, Difference of definition based on difference of second module based on difference information indicating presence / absence of difference between third module and second module having common name and included in second whole source file And target range generation means for generating target range information for limiting the fourth module capable of generating

  The static verification system of the present invention includes a first entire source file including a plurality of first modules, and a third module having a common name with a second module of the plurality of first modules. A configuration management device that holds a partial source file and a build file included in the second whole source file, and generates difference information indicating whether there is a difference between the third module and the second module; An impact analysis device that generates dependency information indicating mutual dependencies of modules, a build analysis device that generates execution condition information indicating an execution condition of static verification from a build file included in the first entire source file, The target range that limits the fourth module that can produce a definition difference by the difference among the second modules based on the dependency relationship information and the difference information. Target range extraction device including target range generation means for generating information, command generation device for generating a command for static verification based on target range information and execution condition information, and static verification device for executing a command It is characterized by providing.

  The target range extraction method of the present invention includes dependency information indicating a mutual dependency of a plurality of first modules included in the first entire source file, a second module of the plurality of first modules, Difference of definition based on difference of second module based on difference information indicating presence / absence of difference between third module and second module having common name and included in second whole source file The fourth module that can produce the above is limited.

  The target range extraction program according to the present invention includes a computer included in a target range extraction apparatus, dependency relationship information indicating a mutual dependency relationship between a plurality of first modules included in a first entire source file, and a plurality of first items. Based on the difference information indicating whether or not there is a difference between the third module and the second module having the same name as the second module among the modules and included in the second entire source file, the second It is made to function as a target range production | generation means which produces | generates the target range information which limits the 4th module which can produce the difference of a definition by the difference among modules.

  According to the present invention, in matters that need to be pointed out due to a difference between two whole source files in static verification, necessary points other than a module that has a difference between two whole source files are also required. There is an effect that items can be displayed.

It is a block diagram which shows an example of a structure of the target range extraction apparatus in the 1st Embodiment of this invention. It is a block diagram which shows an example of the hardware constitutions of the target range extraction apparatus in the 1st Embodiment of this invention. It is a flowchart which shows operation | movement of the target range extraction apparatus in the 1st Embodiment of this invention. It is a figure for demonstrating the specific example of the process sequence of the target range extraction apparatus in the 1st Embodiment of this invention. It is a figure for demonstrating operation | movement of the target range extraction means of the target range extraction apparatus in the 1st Embodiment of this invention. It is a figure for demonstrating another specific example of the process sequence of the target range extraction means of the target range extraction apparatus in the 2nd Embodiment of this invention. It is a block diagram which shows an example of a structure of the target range extraction apparatus in the 2nd Embodiment of this invention. It is a flowchart which shows operation | movement of the static verification system in the 2nd Embodiment of this invention. It is a figure for demonstrating the specific example of the process sequence of the static verification system in the 2nd Embodiment of this invention. It is the first half part of the figure for demonstrating another specific example of the process sequence of the static verification system in the 2nd Embodiment of this invention. It is the latter half part of the figure for demonstrating another specific example of the process sequence of the static verification system in the 2nd Embodiment of this invention.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In all the drawings, equivalent components are denoted by the same reference numerals, and description thereof will be omitted as appropriate.
(First embodiment)
FIG. 1 is a block diagram showing an example of the configuration of the target range extraction device 100 in the present embodiment.

  The target range extraction device 100 is an information processing device such as a computer, for example.

  The target range extraction device 100 includes target range extraction means 140.

  The target range extraction unit 140 generates target range information 510 based on the source difference information 210 and the influence range information 410.

  The source difference information 210 is a difference between modules in two overall source files having a common module name (hereinafter, one is referred to as a “first overall source file” and the other is referred to as a “second overall source file”). This is information indicating the presence or absence of. The source difference information 210 is, for example, information indicating whether or not there is a difference in file contents for each partial source file in the entire source file at the old and new two points. Alternatively, the source difference information 210 is information indicating whether or not there is a code difference for each procedure in two overall source files corresponding to two variants of the program, for example.

  The influence range information 410 is information indicating a dependency relationship between modules in one whole source file (hereinafter, referred to as “first whole source file”) including a static verification target. Note that the “dependency relationship” of a module means that a certain module (for example, a procedure, a partial source file, etc.) is referenced from another module (for example, a procedure is called or a partial source file is taken in). The influence range information 410 is information indicating whether or not a procedure or macro is called from one source file to the other source file for each set of two source files in the first entire source file, for example. Alternatively, the influence range information 410 is information indicating whether or not the other procedure is called from one procedure for each set of two procedures in the first entire source file, for example.

  The target range information 510 is information indicating whether or not there is an influence for each module in the first entire source file. The target range information 510 indicates, for example, whether or not the file contents for each partial source file have changed from the second whole source file corresponding to the old one time point in the first whole source file corresponding to the new one time point. Information. Alternatively, the target range information 510 may be, for example, from a second overall source file corresponding to another variant of the program in a first overall source file corresponding to a variant of one program that is the subject of static verification. This is information indicating whether or not there is a change in the definition (procedure behavior) for each procedure.

  That is, the target range extraction unit 140 generates the target range information 510 by limiting the range where the difference affects each module in the first entire source file based on the source difference information 210 and the affected range information 410. To do. Note that “the influence of the difference on the module” means a difference in the definition of the module caused by the difference. That is, it means a difference in the entire code that defines a module, including a reference to another module in one module (for example, calling a procedure (code), taking in a partial source file).

  FIG. 2 is a block diagram illustrating an example of a hardware configuration of the target range extraction device in the present embodiment.

  The target range extraction apparatus 101 includes a storage device 102, a CPU (Central Processing Unit) 103, a keyboard 104, a monitor 105, and an I / O (Input / Output) 108, which are connected via an internal bus 106. ing. The storage device 102 stores an operation program of the CPU 103 such as the target range extraction unit 140. The CPU 103 controls the entire target range extraction device 101, executes an operation program stored in the storage device 102, executes programs such as the target range extraction means 140 and transmits / receives data via the I / O 108. The internal configuration of the target range extracting apparatus 101 is an example. The target range extraction device 101 may include only the CPU 103, the storage device 102, and the I / O 108, and may operate using a keyboard 104 and a monitor 105 provided outside.

  Next, the operation of this embodiment will be described.

  FIG. 3 is a flowchart showing the operation of the target range extraction apparatus 100 in the present embodiment.

  The target range extraction unit 140 generates target range information 510 based on the source difference information 210 and the influence range information 410 (step S11).

  Next, a specific example of the processing procedure of this embodiment will be described.

  FIG. 4 is a diagram for explaining a specific example of a processing procedure of the target range extraction device 100 in the present embodiment.

First, the premise for demonstrating the specific example of the process sequence of the target range extraction apparatus 100 in this embodiment is demonstrated.
(Premise 1) The entire source file includes procedures “main” and “sub” which are modules.
(Premise 2) There are two whole source files in the whole source file.
(Premise 3) Of the procedures included in the first entire source file, only “sub” has a difference from the second entire source file.
(Assumption 4) “main” calls the “sub” procedure among the procedures included in the first entire source file. This relationship may indicate the relationship in the first entire source file, and the relationship in the second entire source file is arbitrary.
(Premise 5) Of the procedures included in the first entire source file, “sub” does not call other procedures. This relationship may also indicate the relationship in the first entire source file, and the relationship in the second entire source file is arbitrary.

  The above is a premise for explaining a specific example of the processing procedure of the target range extraction apparatus 100 in the present embodiment.

  The source difference information 210 has two modules according to the premise 1 and indicates that there is a difference between the two entire source files only in “sub” according to the premise 2-3. In the table of FIG. 4, the presence of a difference is indicated by a logical value “1” representing “true”, and the absence thereof is indicated by a logical value “0” representing “false”. Hereinafter, a logical value representing “true” is represented by “1”, and a logical value representing “false” is represented by “0”.

  The influence range information 410 has information on two modules according to the premise 1. In addition, based on the assumption 4-5, the calling relationship between modules indicated by the influence range information 410 is as shown in the table of FIG. The table row indicates the calling module, the table column indicates the called module, and “1” indicates that the call exists and “0” indicates that the call does not exist. Also, a call from a module to the module itself is always considered to exist.

  The target range extraction unit 140 generates target range information 510 based on the source difference information 210 and the influence range information 410 (step S11, details will be described later).

  The target range information 510 has two modules according to the premise 1 and indicates that “main” and “sub” are affected by the source difference 210, that is, a target of static verification. In the table of FIG. 4, “1” indicates that the influence is exerted, and “0” indicates that the influence is not exerted.

  FIG. 5 is a diagram for explaining a specific example of the processing procedure of the target range extraction unit 140 of the target range extraction apparatus 100 in the present embodiment.

  The matrix in the figure is called a dependency structure matrix (DSM). The dependency structure matrix has a dimension that matches the number of modules (in the figure, an example in which the dimension is “4” is shown). The matrix row indicates the dependency destination module, the table column indicates the dependency source module, “1” indicates that there is a dependency relationship between modules, and “0” indicates that no dependency relationship exists between the modules. Show.

  The right column vector (hereinafter referred to as “change vector”) in the figure has a dimension (for example, “4”) that matches the number of modules. In the table, “1” indicates that there is a change in the module, and “0” indicates that there is no change in the module.

  The left column vector (hereinafter referred to as “influence vector”) in the figure has a dimension (for example, “4”) that matches the number of modules. In the table, “1” indicates that the module has an influence of change, and “0” indicates that the module has no influence of change.

The influence vector is obtained by multiplying the dependency structure matrix by the change vector. The multiplication of the dependency structure matrix and the change vector is calculated according to the same rule as the multiplication of ordinary matrices. That is, the j-th component (j = 0, 1,..., M, where m is the number of modules in the first entire source file) of the change vector is b _j , and the i-th component (i = 0, 1, ..., component _{c i} of m), the components of the row i and column j of the dependency structure matrix When _{a ij,} effect vector is calculated by _{c i = Σa ij * b j} . Here, “*” means a logical product, and “Σ” means a sum for all the j-th components. The sum is a logical sum of all components.

Here, a _ij * b _j indicates whether or not the change of the j-th module of the dependence source actually affects the i-th module of the dependence destination. Therefore, c _i = Σa _ij * b _j indicates whether or not the i-th element of the influence vector is affected. That is, each element of the target range information is always “1” indicating that it is a target of static verification when it is partially affected by the difference of the partial source code.

  Instead of the influence vector, the transposed vector of the influence vector may be calculated by multiplying the transposed vector of the change vector by the transposed matrix of the dependency structure matrix.

  The target range extraction unit 140 gives a predetermined order to each module, regards the influence range information 410 as a dependency structure matrix, regards the source difference information 210 as a change vector, and multiplies the dependency structure matrix by the change vector. The target range information 510, which is an influence vector, is generated (step S11). As described above, the target range extraction unit 140 may generate the target range information 510 by limiting the transposed vector of the influence vector by multiplying the transposed vector of the change vector by the transposed matrix of the dependency structure matrix. .

  In FIG. 4, the target range information 500 (influence vector) is obtained by multiplying the influence range information 410 (dependence structure matrix) by the source difference information 210 (change vector).

When a module having the first entire source file is not included in the second entire source file, the target range extracting unit 140 also applies a predetermined order to modules not included in the second entire source file. (For example, k (k is a natural number)). The target range extraction unit 140 associates the influence range information 410 with the dependency structure matrix, the source difference information 210 with the change vector, and the influence vector with the target range information 510. Here, the k-th row component b _k of the change vector is regarded as “1”.

  The dependency structure matrix indicates dependency relationships including indirect dependency relationships between modules. If the dependency structure matrix includes only a direct dependency relationship between modules and does not include an indirect dependency relationship, the dependency structure matrix is raised to a power (for example, M power (M is a natural number)). As a result, an indirect dependency structure matrix showing the dependency including indirect dependency considering the chain of the direct dependency between modules up to M times is obtained. This is because, in the above-described case, the influence vector indicates the result of the change vector being affected by the influence of only the direct dependency relationship M times. Thus, if there are m modules in the first overall source file, the chain can occur (m−1) times, so M is equal to m−1. In the above-described case, the target range extraction unit 140 may generate an influence vector by multiplying the power of the square of the dependency structure matrix by a square or more and a change vector. The power of the dependency structure matrix is a matrix obtained by multiplying a plurality of dependency structure matrices as a matrix. In multiplication as a matrix of the dependency structure matrix, a product between components is a logical product, and a sum between components is a logical sum.

For example, consider the case where there are the following direct dependencies between three modules, and no other direct dependencies. Module “1” depends directly on module “2”. Module “2” depends directly on module “3”. In the above case, module “1” depends on module “3” via module “2”. If this is expressed by the dependency structure matrix, the component a _ij of i rows and j columns of the dependency structure matrix is
_{a 12 = a 23 = a 11} = a 22 = a 33 = 1
a _ij = 0 (all elements other than the above)
It is.

A component d _ij of i rows and j columns of the indirect dependency structure matrix obtained by squaring the dependency structure matrix is
d _ij = Σa _im * a _mj (m = 1, 2, 3)
= A _i1 * a _1j + a _i2 * a _2j + a _i3 * a _3j
So, for example,
d ₁₃ = a ₁₁ * a ₁₃ + a ₁₂ * a ₂₃ + a ₁₃ * a ₃₃
= 1 * 0 + 1 * 1 + 0 * 1
= 1
It is.

Thus, by squaring the dependency structure matrix, an indirect dependency structure matrix indicating whether a certain module indirectly depends on another module is obtained by one chain of direct dependency relationships. This is because, for example, focusing on the dependency relationship of module “1” to module “3”, module d of module “1” is included in element d ₁₃ indicating whether or not module “1” is indirectly dependent on module “3”. This is because the product of the element a ₁₂ indicating whether or not there is a direct dependency on “2” and a ₂₃ indicating whether or not the module “2” is directly dependent on the module “3” is included. When the above two direct dependencies exist, the product of the two elements is “1”, indicating that there is an indirect dependency of module “1” on module “3”. When one of the two direct dependencies does not exist, the product of the two elements is “0”, indicating that there is no indirect dependency of module “1” on module “3”.

  The same applies to the case where the number of modules is four or more. That is, the presence or absence of indirect dependence of a module on other modules by one chain of direct dependence is indicated by the indirect dependence structure matrix obtained by the above method. Therefore, the indirect dependency structure matrix that indicates the presence or absence of an indirect dependency of one module on another module by multiplying the obtained indirect dependency structure matrix by the dependency structure matrix further, by two chains of direct dependencies. Can be requested. In this way, by repeating the multiplication of the dependency structure matrix to the indirect dependency structure matrix, that is, by obtaining the (m−1) th power of the dependency structure matrix, indirect between the modules “1”,. An indirect dependency structure matrix indicating the presence or absence of dependency can be obtained. If the (M−1) th power of the dependency structure matrix is equal to the Mth power, all the powers of the dependency structure matrix that are (M−1) th power or higher are the same. The calculation of is unnecessary.

  FIG. 6 is a diagram for explaining another specific example of the processing procedure of the target range extraction unit 140 of the target range extraction device 100 in the present embodiment.

  The influence range information 420 is an example showing a calling relationship including only a direct calling relationship between modules. The influence range information 420 indicates that “main” directly calls “sub”, “sub” directly calls “sub2”, and has no other direct calling relationship.

  On the other hand, the influence range information 430 is an example showing a calling relationship including an indirect calling relationship between modules. The influence range information 430 indicates that “main” indirectly calls “sub2” via “sub” in addition to the calling relationship indicated by the influence range information 420. The dependency structure matrix corresponding to the influence range information 430 is a power of at least the square of the dependency structure matrix corresponding to the influence range information 420.

  It is assumed that the static verification is performed on the second entire source file before the static verification is performed on the first entire source file. For the module “sub” having a difference between the second entire source file and the first entire source file, static verification is required in the first entire source file.

  On the other hand, for the module “main” in which there is no difference between the second whole source file and the first whole source file, “main” calls “sub”. It may change. Therefore, regarding “main”, there is no difference between the second entire source file and the first entire source file, but static verification is required again. The target range extraction apparatus 100 extracts both “main” and “sub” as target ranges for static verification. Accordingly, the verification result includes a procedure “main ()” designated as a target for static verification and having no difference between the first overall source code and the second overall source code, the first overall source code, and The indication regarding the procedure “sub ()” having a difference between the second whole source codes is included.

  As described above, in the target range extraction apparatus 100 according to the present embodiment, a difference between different procedures (for example, “sub”) even for a procedure (for example, “main”) that has no difference between the two entire source files. If it is affected by the difference, specify it as the target of static verification. Therefore, the target range extraction apparatus 100 according to the present embodiment has a difference between the two entire source files regarding matters that need to be pointed out due to the difference between the two entire source files in the static verification. Necessary indications can be displayed for modules other than modules.

In the above description, the case where the influence range information 410 is a dependency relationship between procedures in the procedural programming language has been described. However, the influence range information 410 of the present embodiment does not need to be information indicating the dependency relationship between procedures. That is, the influence range information 410 of the present embodiment may be information indicating a dependency relationship between partial source files. The target range extraction unit 140 of the target range extraction apparatus 100 generates target range information 510 for each partial source file based on the source difference information 210 for each partial source file and the influence range information 410 for each partial source file. If the external static verification device can limit the verification range for each procedure, the target range extraction device 100 needs to point out due to the difference between the two entire source files in the static verification. Necessary items to be indicated can be displayed for modules other than the module having a difference between the two entire source files.
(Second Embodiment)
In the description of the present embodiment, descriptions common to the first embodiment and the present embodiment are omitted, and only the differences of the present embodiment from the first embodiment will be described.

  In the present embodiment, the configuration of the entire static verification system including the target range extraction device 190 in the present embodiment will be described.

  FIG. 7 is a block diagram illustrating an example of the configuration of the target range extraction device 190 in the present embodiment. The configuration of the target range extraction device 190 in the present embodiment is the same as the configuration of the target range extraction device 100 in the first embodiment shown in FIG. 1, but the source difference information 215 and the influence range information that are inputs. The data format of 415 is different.

  A static verification system including the target range extraction device 190 in the present embodiment will be described. The static verification system includes a configuration management device 110, an impact analysis device 130, a build analysis device 120, a target range extraction device 190, a command generation device 400, and a static verification device 500.

  The configuration management device 110 is an information processing device such as a computer, for example. The configuration management apparatus 110 is also called a “configuration management system”. The configuration management system includes, for example, “Subversion (registered trademark)”. The configuration management apparatus 110 holds the partial source file 221-224 and the build file 225 in the first whole source file 220, and the partial source file 231-234 and the build file 235 in the second whole source file 230. The configuration management apparatus 110 further outputs the partial source files 221-224 and the build file 225 in the first entire source file 220. The configuration management apparatus 110 further performs the first operation based on the partial source file 221-224 and the build file 225 in the first entire source file 220 and the partial source file 231-234 and the build file 235 in the second entire source file 230. Source difference information 215 indicating a difference for each partial source file between the one entire source file 220 and the second entire source file 230 is generated.

  The influence analysis device 130 is an information processing device such as a computer, for example. The impact analysis device 130 is also referred to as an “impact analysis system”. The impact analysis system includes, for example, “Lattix” manufactured by TechMatrix (registered trademark). The influence analysis device 130 generates influence range information 415 indicating the dependency relationship between the partial source files 221-224 based on the partial source files 221-224 and the build file 225 in the first overall source file 220.

  The build analysis device 120 is an information processing device such as a computer, for example. The build analysis device 120 is also called a “build analysis system”. An example of the build analysis system is “Lattix” manufactured by TechMatrix. The build analysis apparatus 120 generates execution condition information 310 indicating execution conditions for static verification from the build file 225 in the first entire source file 220.

  The target range extraction device 190 includes target range generation means 145. The target range generation unit 145 limits the range in which the difference affects each module in the first overall source file 220 based on the source difference information 215 and the affected range information 415, so that the first overall source file 220 The target range information 510 indicating the target module for static verification is generated.

  The command generation device 400 generates a static verification command 520 for executing static verification based on the target range information 510 and the execution condition information 310.

  The execution condition information 310 is a verification condition (information for designating program operation) at the time of static verification. When the source file is described in a compiler language, the execution file is generated by compiling the source file. The execution condition information 310 includes a part of options specified at the time of compilation (hereinafter referred to as “compile-time options”). Compile-time options are described in the build file. The execution condition information 310 may include a part of options (hereinafter referred to as “execution options”) specified at the time of execution of the execution file. The runtime option includes, for example, a command line option of an execution file, and may be described in a script file (shell script, command file), a test execution file, or the like.

  The static verification command 520 is a command line for causing the static verification apparatus 500 to execute static verification. The static verification command 520 includes a source file selected as a target for static verification from a group of source files and a command line option (hereinafter referred to as “static verification option”) for specifying the program operation at the time of static verification. ").

  The static verification device 500 is an information processing device such as a computer, for example. The static verification apparatus 500 is also called a “static verification system”. Examples of the static verification system include “C ++ test” and “Jtest” of TechMatrix. The static verification apparatus 500 executes the static verification command 520 in which the partial source file selected as the target of static verification and the static verification option are specified, and generates a verification result 530. The verification result 530 includes an indication regarding a partial source file specified as a target for static verification, and does not include an indication regarding a partial source file not specified as a target for static verification.

  Next, the operation of this embodiment will be described.

  FIG. 8 is a flowchart showing the operation of the static verification system in the present embodiment.

  The configuration management apparatus 110 obtains the source difference information 215 from the partial source file 221-224 and the build file 225 in the first whole source file 220 and the partial source file 231-234 and the build file 235 in the second whole source file 230. Generate (step S21).

  The impact analysis apparatus 130 generates impact range information 415 indicating the dependency between the partial source files 221-224 from the partial source files 221-224 and the build file 225 in the first overall source file 220 (step S 22). .

  The build analysis apparatus 120 generates execution condition information 310 indicating execution conditions for static verification from the build file 225 in the first entire source file 220 (step S23).

  The target range generation unit 145 of the target range extraction apparatus 190 indicates a target module (partial source file) for static verification in the first entire source file 220 based on the influence range information 415 and the source difference information 215. Range information 510 is generated (step S24).

  The command generation device 400 generates a static verification command 520 based on the target range information 510 and the execution condition information 310 (step S25).

  The static verification apparatus 500 executes the static verification command 520 in which the partial source file selected as the target of static verification and the static verification option are specified, and generates a verification result 530 (step S26).

  Next, a specific example of the processing procedure of this embodiment will be described.

  FIG. 9 is a diagram for explaining a specific example of the processing procedure of the static verification system in the present embodiment.

  Two whole source files 220 and 230 exist in the whole source file. The build file 235 and the partial source files 231 to 234 are the build file and the partial source file at the second time point (for example, the old time point). The build file 225 and the partial source files 221 to 224 are a build file and a partial source file at a first time (for example, a new time). The entire source files 220 and 230 are described in the C language, and the partial source files “main.c” 221, 231, “sub.c” 222, 232, “sub2.c” 223, 233, “com.h” 224 234. The two entire source files 220 and 230 excluding the header file (“com.h”) 224 and 234 are stored in different directories (folders. For example, “new” and “old”). The header files 224 and 234 are stored in the “include” directory under the directory in which the partial source file excluding the header file is stored.

  Of the partial source files included in the first whole source file 220, only “sub.c” 222 has a difference from the second whole source file 230. In the partial source file 222, one line is added to the sixth line with respect to the partial source file 232. There is no difference between the build file 225 and the build file 235. The partial source files 221, 222, and 224 have no difference with respect to the partial source files 231, 232, and 234, respectively.

  Of the partial source files included in the first whole source file 220, “main.c” 221 calls the procedure “sub.c” 222 and the macro “com.h” 224. This relationship may indicate the relationship in the first entire source file 220, and the relationship in the second entire source file 230 is arbitrary.

  Of the partial source files included in the first whole source file 220, “sub.c” 222 calls the procedure “sub2.c” 223 and the macro “com.h” 224. This relationship may also indicate the relationship in the first entire source file 220, and the relationship in the second entire source file 230 is arbitrary.

  Of the partial source files included in the first whole source file 220, “sub2.c” 223 does not call both the procedures of the other source files and the macro of “com.h” 224. This relationship may also indicate the relationship in the first entire source file 220, and the relationship in the second entire source file 230 is arbitrary.

  FIG. 10 is the first half of a diagram for explaining another specific example of the processing procedure of the static verification system in the present embodiment.

  The configuration management apparatus 110 generates source difference information 215 from the partial source files 221-224 in the first entire source file 220 and the partial source files 231-234 in the second entire source file 230 (step S 21).

  The source difference information 215 indicates whether or not there is a difference for each partial source file between the first entire source file 220 and the second entire source file 230. Only “sub.c” indicates that there is a difference between the two entire source files.

  The source difference information 225 is an example of the execution result of a general “diff” command. Of the partial source file and the build file between the first entire source file and the second entire source file, the difference is only between the partial source file “sub.c” 222 and the partial source file “sub.c” 232. is there. Therefore, the source difference information 225 indicates that there is a difference between the partial source file 222 and the partial source file 232 and the content of the difference. This source difference information 225 matches the content shown in the source difference information 215.

  The impact analysis apparatus 130 generates impact range information 415 indicating the dependency between the partial source files 221-224 from the partial source files 221-224 and the build file 225 in the first overall source file 220 (step S 22). .

  The influence range information 415 has information on the dependency relationship between the four partial source files 221-114. The calling relationship between modules indicated by the influence range information 415 is as shown in the table of FIG. The influence range information 415 indicates a calling relationship including all direct and indirect calling relationships between modules. A call from a module to the module itself is always considered to exist.

  The partial source file “main.c” 221 depends on the partial source file “sub.c” 222 via the function “sub ()”, and the partial source file via the functions “sub ()” and “sub2 ()”. Depends on the file “sub2.c” 223 and on the partial source file “com.h” 224 via the “include” line. That is, the partial source file “main.c221” is directly or indirectly dependent on the partial source file “sub.c” 222, the partial source file “sub2.c” 223, and the partial source file “com.h” 224. To do.

  The partial source file “sub.c” 222 depends on the partial source file “sub2.c” 223 via the function “sub2 ()”, and changes to the partial source file “com.h” 224 via the “include” line. Dependent. That is, the partial source file “sub.c” 222 depends directly or indirectly on the partial source file “sub2.c” 223 and the partial source file “com.h” 224.

  The partial source files “sub2.c” 223 and “com.h” 224 do not depend on other partial source files, whether through functions or “include” lines.

  The influence range information 425 indicates a call relationship including only a direct call relationship between the four partial source files 221-114. The partial source file “main.c” 221 indirectly depends on the partial source file “sub2.c” 223 via the functions “sub ()” and “sub2 ()”, but not directly. The power of 2 or more of the dependency structure matrix of the influence range information 425 matches the dependency structure matrix of the influence range information 415.

The direct dependencies between the four modules are as follows: Module “1” depends directly on module “2” and module “4”. Module “2” depends directly on module “3” and module “4”. In the above case, module “1” depends on module “3” via module “2”. If this is expressed by the dependency structure matrix, the component a _ij of i rows and j columns of the dependency structure matrix is
_{a 12 = a 14 = a 23} = a 24 = a 11 = a 22 = a 33 = a 44 = 1
a _ij = “0” (all elements other than the above)
It is.

A component d _ij of i rows and j columns of the indirect dependency structure matrix obtained by squaring the dependency structure matrix is
d _ij = Σa _im * a _mj (m = 1, 2, 3, 4)
= A _i1 * a _1j + a _i2 * a _2j + a _i3 * a _3j + a _i4 * a _4j
So, for example,
d ₁₃ = a ₁₁ * a ₁₃ + a ₁₂ * a ₂₃ + a ₁₃ * a ₃₃ + a ₁₄ * a ₄₃
= 1 * 0 + 1 * 1 + 0 * 1 + 1 * 0
= 1
It is. That is, module “1” depends indirectly on module “3”. In the present embodiment, the module “1” directly depends on the module “2”, and the module “2” directly depends on the module “3”. Therefore, a ₁₂ = a ₂₃ = 1 It has become. Therefore, although the number of modules is four, the presence / absence of indirect dependence of module “1” on module “3” can be determined only by squaring the dependency structure matrix.

  Based on the influence range information 415 and the source difference information 215, the target range generation unit 145 generates target range information 515 indicating a static verification target module in the first entire source file 220 (step S24). The target range information 515 matches the influence vector that is the result of multiplying the dependency structure matrix corresponding to the influence range information 415 by the change vector corresponding to the source difference information 215.

  When the influence range information includes only a direct call relationship between partial source files and does not include an indirect call relationship, the target range extraction unit 145 includes a dependency structure matrix corresponding to the influence range information 425. The influence vector corresponding to the target range information 515 may be generated by multiplying the power of 2 or more by the change vector corresponding to the source difference information 215.

  FIG. 11 is the latter half of the diagram for explaining another specific example of the processing procedure of the static verification system in the present embodiment.

  The build analysis apparatus 120 generates execution condition information 315 indicating the execution conditions for static verification from the build file 225 in the first entire source file 220 (step S23). The second line of the build file 225 includes “−I./include” as a compile option of “main.c”. The third line of the build file 225 includes “−I./include” as a compile option of “sub.c”. The fourth line of the build file 225 does not include a valid option as a compile option of “sub2.c”. The aforementioned compile option information is included in the contents shown in the build information 315 in FIG. In the build information 315 of FIG. 11, the “main.c” and “sub.c” options are on the fifth line, and the “main.c” and “sub.c” options are on the ninth line. , “Sub2.c” is indicated in the 25th line, and “sub2.c” is indicated in the 29th line. In the build information 315 in FIG. 11, the directory is indicated by an absolute path, but it can be read as a relative path.

  The command generation device 400 generates a static verification command 520 based on the target range information 515 and the execution condition information 315 (Step S25).

  In the execution condition information 310, only “main.c” 221 and “sub.c” 222 call “com.h” 225, so only “main.c” and “sub.c” have the value “−I./ "include" (general C compiler command line option). Note that “−I./include” indicates that the call destination directory of “com.h” is “./include”.

  For example, the command generation device 400 designates the command name as “tool”, and designates “main.c” and “sub.c” as verification targets by the target range information 510. Then, the command generation device 400 designates the C compiler command line option “-I./include” corresponding to “main.c” and “sub.c” as the verification condition based on the execution condition information 310, and statically A verification command 520 is generated.

  In the above description, an example of the “-I” option for specifying a header file is shown as an option at the time of static verification. The static verification option may include a “-D” option for additionally defining a macro, a “-U” option for undefining a macro, or a “-nostdinc” option for not searching a standard header file.

  The static verification apparatus 500 executes the static verification command 520 in which the target range information and the execution condition information are specified, and generates a verification result 530 (step S26).

  It is assumed that the static verification is performed on the second entire source file before the static verification is performed on the first entire source file. For the module “sub.c” having a difference between the second entire source file and the first entire source file, static verification is required in the first entire source file.

  On the other hand, for the module “main.c” in which there is no difference between the second entire source file and the first entire source file, “main.c” calls “sub.c”, so “sub.c”. The operation may change due to the change in the operation. Therefore, for “main.c”, there is no difference between the second whole source file and the first whole source file, but it is necessary to perform static verification again. Modules “sub2.c” and “com.h” that do not differ between the second whole source file and the first whole source file do not call other partial source files, so a static verification is necessary again. Absent. The target range extraction device 190 extracts both “main.c” and “sub.c” as target ranges for static verification. Therefore, the verification result 530 includes a partial source file “main.c” designated as a target for static verification and having no difference between the first entire source code and the second entire source code, and the first entire source code. The indication regarding the partial source file “sub.c” having a difference between the source code and the second whole source code is included.

  As described above, in the target range extraction device 190 according to the present embodiment, a source file (for example, “main.c”) that has no difference between two entire source files is also used as another source file (for example, “sub”). .C ″), if the difference affects the difference, it is designated as a target for static verification. Therefore, the target range extraction apparatus 190 according to the present embodiment has a difference between the two entire source files regarding matters that need to be pointed out due to the difference between the two entire source files in the static verification. Necessary indications can be displayed for modules other than modules.

  In the first and second embodiments, the case where the target range extraction device is an independent device has been described. However, the target range extraction device of the present invention is not necessarily an independent device. That is, one or more of the configuration management device 110, the impact analysis device 130, the build analysis device 120, the static verification device 500, or the static verification device, and the target range extraction device are integrated into one device. Also good.

  Each process of the target range extraction device in FIG. 3 may be executed by software. That is, a computer program for performing each process may be read and executed by a CPU (FIG. 2: 903) provided in the target range extraction device. Even if each process is performed using a program, the same process as the process of the above-described embodiment can be performed. The above program may be stored in a non-transitory medium such as a ROM (Read Only Memory), a RAM (Random Access Memory), a semiconductor memory device such as a flash memory, an optical disk, a magnetic disk, or a magneto-optical disk. .

  Alternatively, each process may be executed by a component such as an individual circuit.

  In addition, this invention is not limited to the above-mentioned embodiment, It can implement in various changes and deformation | transformation in the range which does not deviate from the summary of this invention.

Claims (8)

Dependency information indicating mutual dependency among a plurality of first modules included in the first overall source file, and a name common to a second module of the plurality of first modules, And a difference that indicates whether or not there is a difference between the third module and the second module included in the entire second source file, and a difference in definition may be generated by the difference in the second module. Target range generation means for generating target range information for limiting the module of
A target range extracting apparatus comprising: The dependency information includes all information indicating direct and indirect dependency relationships between the plurality of first modules,
The target range generation unit generates the influence vector as the target range information by multiplying the dependency structure matrix as the dependency relationship information by a change vector as the difference information. The target range extraction device described. The dependency relationship information includes all direct dependency relationship information indicating a direct dependency relationship between the plurality of first modules, and includes indirect dependency relationship information indicating an indirect dependency relationship between the plurality of first modules. not included,
The target range generation means multiplies the dependency structure matrix, which is the direct dependency relationship information, to the 2nd to (m-1) th power (m is the number of the first modules) by the change vector, which is the difference information. The target range extraction apparatus according to claim 1, wherein an influence vector that is the target range information is generated. 4. The target range extracting apparatus according to claim 1, wherein the module is a file, and the difference is a difference in contents of the file. 5. 4. The target range extracting apparatus according to claim 1, wherein the module is a procedure in a procedural programming language, and the difference is a difference in code of the procedure. Included in a first overall source file including a plurality of first modules and a second overall source file including a third module having a common name with a second module of the plurality of first modules A configuration management device that holds a partial source file and a build file, and generates difference information indicating whether there is a difference between the third module and the second module;
An impact analysis device that generates dependency information indicating mutual dependency among the plurality of first modules;
A build analysis device that generates execution condition information indicating an execution condition of static verification from a build file included in the first entire source file;
Including target range generation means for generating target range information for limiting a fourth module that can cause a difference in definition by the difference among the second modules based on the dependency relationship information and the difference information. A target range extraction device;
A command generation device for generating a command for the static verification based on the target range information and the execution condition information;
A static verification device for executing the command;
A static verification system comprising: Dependency information indicating mutual dependency among a plurality of first modules included in the first overall source file, and a name common to a second module of the plurality of first modules, And a difference that indicates whether or not there is a difference between the third module and the second module included in the entire second source file, and a difference in definition may be generated by the difference in the second module. A target range extraction method characterized by limiting the number of modules. A computer included in the target range extraction device,
Dependency information indicating mutual dependency among a plurality of first modules included in the first overall source file, and a name common to a second module of the plurality of first modules, And a difference that indicates whether or not there is a difference between the third module and the second module included in the entire second source file, and a difference in definition may be generated by the difference in the second module. A target range extraction program for functioning as target range generation means for generating target range information for limiting the modules.

Images