JP2007179488A - Program for predicting source code problem - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a technique for predicting source code problems, capable of improving detection accuracy of the problems in software static analysis. <P>SOLUTION: In the source code problem prediction program 20, function calling string information 31 to an exception processing information table 34 and a detection result table 36 are generated from a source code 40 and a detection function list 41 by a word/syntax analysis part 21, a detection part 22, a function calling string extraction part 23 to an exception processing information extraction part 26, and a function calling relation information 35 is generated from them by a function calling relation information generation part 27. An execution frequency information table 37 is generated from function calling relation information 35 and a weight definition table 42 by an execution frequency prediction part 28, and a detection result report 50 is generated from the detection result table 36, the execution frequency information table 37 and a rank definition table 43 by an execution frequency prediction part 28. Functions of problem are effectively narrowed using the detection function list 41, the weight definition table 43 and the rank definition table 43, and ranked and displayed. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a source code problem prediction technique, for example, a technique effective when applied to verification, management, evaluation work, etc. of source code quality in a software review process.

In recent years, in various software developments, with the increasing scale and diversification of software, there is an increasing demand for ensuring high quality at a low cost.
Software static analysis is a technique for improving software quality at low cost. In software static analysis, source code (hereinafter referred to as source) is analyzed to detect various problems.

A profiler, a debugger, and other general test techniques require information at the time of program execution (such as operation logs).
Unlike these test techniques, software static analysis targets the source and can be used for problem detection work in the design and coding process upstream of the development process. In other words, it is possible to find problems before simulation or actual machine test. As the problem of the program can be discovered early in this way, the correction cost can be reduced, and the cost and performance of the software can be reduced.

  However, software static analysis does not use run-time information, so it is a technical issue how to accurately predict problems that occur at run time. However, all of the conventional products have low prediction accuracy. .

  That is, all the conventional products define objects (function calls, etc.) that may be problematic, and search and output them uniformly from the source. For this reason, many things that are not actually a problem are detected, resulting in low accuracy.

As a result, it is necessary to review a large number of functions regardless of the weight of the problem, and the man-hour in the source review process of software development increases.
Furthermore, the output result of the important problem part is buried in a large amount of output information that does not cause a problem, and the visibility and operability are lowered, so the utilization rate of the support program itself is also lowered.

  In Patent Document 1, a class name, a process name, and a processing pattern that may degrade the execution performance of an object-oriented program are accumulated in advance as performance degradation information for each execution environment, and a source based on this performance degradation information is stored. A technique for statically analyzing a code and displaying a portion in the source code that has a possibility of degrading execution performance is disclosed.

However, in the case of Patent Document 1, since the control structure such as the conditional branch structure included in the source is not analyzed in detail, there is a concern that the detection accuracy of the problem portion may be relatively low.
JP 2002-73369 A

An object of the present invention is to provide a source code problem prediction technique capable of improving the detection accuracy of a problem location in software static analysis.
Another object of the present invention is to provide a source code problem prediction technique capable of reducing man-hours in the design process and review process of software development.

  Another object of the present invention is to provide a source code problem prediction technique capable of optimizing a method for detecting a problem location based on user evaluation and past experience in a software development design process and a review process. There is.

  Another object of the present invention is to improve the visibility and operability of a source code problem prediction program that supports the design process and review process of software development.

A first aspect of the present invention is a process for extracting control structure information related to at least one of a function calling relationship, a repetition structure, and a conditional branch structure included in a source code of a program;
A process of predicting a specific area that is repeatedly executed at a high frequency when the program is executed from the control structure information;
A process for checking whether there is a call to a specific function given in advance for the specific area, and ranking and displaying the specific function that has existed based on the predicted execution frequency of the specific area;
A source code problem prediction program for causing a computer to execute the program is provided.

According to a second aspect of the present invention, there is provided a step of extracting control structure information related to at least one of a function calling relationship, a repetition structure, and a conditional branch structure included in a program source code
Predicting a specific region that is repeatedly executed at a high frequency when the program is executed from the control structure information;
Checking whether there is a call to a specific function given in advance for the specific area, and ranking and displaying the existing specific function based on the predicted execution frequency of the specific area,
Provide a source code problem prediction method including.

According to a third aspect of the present invention, there is provided a first means for extracting control structure information related to at least one of a function calling relationship, a repetition structure, and a conditional branch structure included in a program source code;
A second means for predicting a specific area that is repeatedly executed at a high frequency when the program is executed from the control structure information;
A third means for checking whether there is a call to a specific function given in advance for the specific area, and ranking and displaying the specific function that has existed based on the predicted execution frequency of the specific area;
A source code problem prediction apparatus including

  In the present invention, a portion that is likely to become a bottleneck at the time of execution (a portion that is frequently executed) is estimated in the source, and a search narrowed down to that portion is performed to improve the detection accuracy of the problem portion.

  For example, the prediction of the part executed frequently is performed as follows. A call relationship between functions and a control syntax (such as an if statement) such as a loop or conditional branch in each function are extracted from the source code, and a weight indicating the nature of the control syntax is given to them. Based on this weight, a function having a high sum of related weights is predicted as a function having a high execution frequency.

  Thereby, an important function from the viewpoint of problem detection is selectively output as a detection result, and the problem point indication accuracy is improved. In this case, the data may be ranked and output in descending order of execution frequency. Since the unimportant function is not output, the visibility of the detection result of the problem portion is improved. Further, for example, by performing weighting according to the importance of each function that is empirically known from the outside, it is possible to optimize the detection of the problem location according to the user's evaluation and experience. As a result, it becomes possible to point out problems with high accuracy and improve operability.

According to the present invention, it is possible to improve the detection accuracy of a problem location in software static analysis.
In addition, it is possible to reduce man-hours in the software development design process and review process.

Further, in the design process and review process of software development, it is possible to optimize the method for detecting a problem location based on user evaluation and past experience.
Further, the visibility and operability of the source code problem prediction program that supports the design process and review process of software development can be improved.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
FIG. 1A is a conceptual diagram showing an example of the operation of a source code problem prediction program and method according to an embodiment of the present invention.

FIG. 1B is a conceptual diagram showing an example of the configuration of a source code problem prediction apparatus that implements a source code problem prediction program and method according to an embodiment of the present invention.
FIG. 2 is a flowchart showing an example of the operation of the source code problem prediction program and method according to an embodiment of the present invention.

FIG. 3 is an explanatory diagram showing an example of source code processed by the source code problem prediction program of the present embodiment.
First, an example of the information processing apparatus 10 (computer) that constitutes the source code problem prediction apparatus according to the present embodiment will be described with reference to FIG. 1B.

  The information processing apparatus 10 according to the present embodiment includes a central processing unit 11, a main memory 12, an external storage device 13, a display 14, an information input device 15, and a network interface 16.

The central processing unit 11 is composed of, for example, a microprocessor and performs desired information processing by executing a program installed in the main memory 12.
The main memory 12 is composed of, for example, a semiconductor memory, and stores software and data executed by the central processing unit 11.

  In the case of the present embodiment, the main memory 12 has an operating system 18, a source code problem prediction program 20, a function call sequence information 31, a loop information table 32, a conditional branch information table 33, an exception handling information table 34, and a function call relationship. Information 35, a detection result table 36, and an execution frequency information table 37 are stored.

The central processing unit 11 controls the overall operation of the information processing apparatus 10 by executing the operating system 18.
The source code problem prediction program 20 is an application program that runs under the operating system 18.

The function call sequence information 31 to the execution frequency information table 37 are information that the source code problem prediction program 20 outputs during execution.
The external storage device 13 is composed of a storage device composed of a nonvolatile storage medium.

  In the case of the present embodiment, the external storage device 13 holds information such as the source code 40, the detection function list 41, the weight definition table 42, the rank definition table 43, and the function weight definition table 44.

  Although not particularly illustrated, the external storage device 13 also permanently holds an operating system 18 and a source code problem prediction program 20, and is loaded into the main memory 12 and executed as necessary.

A detection result report 50 output from the source code problem prediction program 20 is displayed on the display 14.
The information input device 15 includes user input devices such as a keyboard and a mouse, for example. In the case of the present embodiment, various information for controlling the source code problem prediction program 20 is input from the user as necessary.

The network interface 16 controls the exchange of information between the information processing apparatus 10 and the external information network 17.
For example, the information stored in the external storage device 13 may be acquired from the information network 17 via the network interface 16 as necessary.

It is also possible to output the detection result report 50 output to the display 14 to the information network 17.
On the other hand, as illustrated in FIG. 1A, the source code problem prediction program 20 of the present embodiment includes a lexical / syntax analyzing unit 21, a detecting unit 22, a function call sequence extracting unit 23, a loop information extracting unit 24, a conditional branch. Each functional block includes an extraction unit 25, an exception processing information extraction unit 26, a function call relation information generation unit 27, an execution frequency prediction unit 28, and a report output unit 29.

The lexical / syntax analyzing unit 21 analyzes the source code 40 and outputs source code analysis information 30 described later.
The detection unit 22 outputs the detection result table 36 from the source code analysis information 30 and the detection function list 41.

The function call sequence extraction unit 23 analyzes the source code analysis information 30 and outputs function call sequence information 31.
The loop information extraction unit 24 analyzes the source code analysis information 30 and outputs a loop information table 32.

The conditional branch extraction unit 25 analyzes the source code analysis information 30 and outputs a conditional branch information table 33.
The exception processing information extraction unit 26 analyzes the source code analysis information 30 and outputs an exception processing information table 34.

  The function call relationship information generation unit 27 inputs the function call sequence information 31, the loop information table 32, the conditional branch information table 33, the exception handling information table 34, and the detection result table 36, and outputs the function call relationship information 35.

The execution frequency prediction unit 28 inputs the weight definition table 42 (and / or the function weight definition table 44) and the function call relation information 35 and outputs the execution frequency information table 37.
The report output unit 29 inputs the detection result table 36, the execution frequency information table 37, and the rank definition table 43 and outputs a detection result report 50.

The source code problem prediction program 20 of this embodiment operates as shown in the flowchart illustrated in FIG.
First, the lexical / syntax analyzing unit 21 analyzes the source code 40 and outputs the source code analysis information 30 illustrated in FIG. 4 (step 100).

Next, the detection unit 22 detects the function call described in the detection function list 41 from the source code analysis information 30 and records it in the detection result table 36 (step 200).
Next, the function call sequence extraction unit 23 extracts the function call sequence information 31 from the source code analysis information 30 (step 300).

  Next, the loop information extraction unit 24 (conditional branch extraction unit 25) (exception processing information extraction unit 26) converts the loop information table 32 (conditional branch information table 33) (exception processing information table 34) from the source code analysis information 30. Output (step 400).

  Next, the function call relationship information generation unit 27 generates function call relationship information 35 from the detection result table 36, the function call sequence information 31, and the loop information table 32 (conditional branch information table 33) (exception processing information table 34). (Step 500).

Next, the execution frequency prediction unit 28 generates the execution frequency information table 37 from the function call relation information 35 by using the weight definition table 42 (function weight definition table 44) (step 600).
Finally, the detection result report 50 is output from the execution frequency information table 37, the detection result table 36, and the rank definition table 43 (step 700).

Hereinafter, each of step 100 to step 700 described above will be described in detail.
First, in step 100 described above, the lexical / syntax analyzing unit 21 analyzes the source code 40. For the lexical / syntax analysis itself, an analysis technique such as a program language parser described in the source code 40 can be used.

  As a result of the analysis, source code analysis information 30 illustrated in FIG. 4 is created. The source code analysis information 30 is described so that a plurality of nodes 30a each holding a description element such as a program function name, variable name, declaration, etc. form a tree structure starting from a ROOT node.

[Details of Step 200]
FIG. 5 is a conceptual diagram showing a configuration example of the detection function list 41 in the present embodiment. In the detection function list 41, a class name 41a, a method name 41b, and an argument type 41c are stored in association with each other. In the detection function list 41, a deprecated function as described later is set.

  Next, using the detection function list 41 and the above-described source code analysis information 30 as inputs, a function call described in the detection function list 41 is searched. FIG. 6 is a flowchart of this processing.

  Here, in the Java source code (pseudo code) of FIG. 3, a plurality of functions are defined, and other functions are called in these functions. The functions such as f100 and f101 call the get function of the LinkedList class and the insert function of the Vector class. They are generally known as functions that cause performance degradation when called frequently. The detection function list 41 is a table in which a user defines a deprecated function that causes such a problem in advance.

As illustrated in FIG. 6, in this process, an empty detection result table 36 is generated (step 201), and the detection function list 41 is read (step 202).
If an unprocessed detection function exists in the detection function list 41 (step 203), the unprocessed function is selected as a processing target (step 204), and the target function is selected from the source code analysis information 30. Is called (step 205), and it is determined whether there is a call to the target function (step 206).

  If there is a call to the target function, an ID (call ID 36a) is assigned to the detected call with a serial number (step 208), and the ID, function name, call location (line number) is assigned to the detection result table 36. Is registered (step 209).

Then, assuming that the function has been processed (step 207), the process returns to step 203 and is repeated for all functions registered in the detection function list 41.
Information of the detection result table 36 illustrated in FIG. 7 is obtained by the processing of the flowchart shown in FIG.

In the detection result table 36, a call ID 36a, an existing location 36b, and a detection function 36c are stored in association with each other.
The call ID 36a is an identifier assigned in order to the detected function. For each function specified by the detection function 36c, the presence position (line number in the file) of the call is also extracted and stored in the detection result table 36 as the presence location 36b.

[Details of Step 300]
Next, in step 300, function call sequence information 31 is extracted from the source code analysis information 30. FIG. 8 is a flowchart of this process.

  It is determined whether or not an unprocessed function exists (step 301). If there is, an unprocessed function (@ 1) is acquired from the source code analysis information 30 (step 302), and a node 31a indicating the function is created. (Step 303).

It is determined whether or not there is a function call in the function (step 304). If there is a function call, it is further determined whether or not the function function node 31a has been created (step 305).
If it has been created, the function to be called (@ 2) is acquired (step 306), and the link 31b from the function (@ 1) to the function (@ 2) is created (step 307). Return.

  If it has not been created in step 305, a node 31a of the function (@ 2) to be called is created, and a link 31b from the function (@ 1) to the function (@ 2) is created ( Step 307), returning to Step 301.

If there is no function call in step 304, the process returns to step 301.
Thereby, the function call sequence information 31 illustrated in FIG. 9 is obtained. The function call sequence information 31 is generated by paying attention to each detection function in the detection result table 36 as a function call relationship included in the source code 40. For example, when the call with the call ID 36a of # 3 follows the link 31b related to the call of the function that reaches it, “f0 → f1 → f102 → # 3” and “f2 → f102 → # 3 "is the two call queues.
[Details of Step 400]
In step 400, the loop information table 32 and the conditional branch information table 33 are also extracted from the source code analysis information 30. FIG. 10 is a flowchart of this process showing details of step 400.

First, an empty loop information table 32 is generated (step 401), and it is determined whether an unprocessed function exists (step 402).
If it exists, an unprocessed function (@ 1) is acquired from the source code analysis information 30 (step 403), and it is determined whether there is a further function call in the function (step 404).

  If it exists, the function (@ 2) to be called is further acquired (step 405), and the loop structure including the function (@ 2) call in the function (@ 1) (for example, for statement, while statement) Is determined (step 406).

  If it exists, the loop structure information (loop syntax type, number) is acquired (step 407), and further, the extracted loop structure information using two functions (@ 1) and function (@ 1) as keys. Is registered in the loop information table 32 (step 408), and the process returns to step 402.

If the determination condition is not satisfied in the above-described step 406 and step 404, the process returns to step 402.
By this processing, the loop information table 32 and the conditional branch information table 33 obtained are as shown in FIGS.

  That is, the loop information table 32 in FIG. 11 holds the function pair 32a and the type 32b in association with each other. For example, the first entry expresses that there is a while statement in the definition of the function f0 and that the function f1 is called in the statement.

The conditional branch information table 33 in FIG. 12 stores a function pair 33a and a type 33b in association with each other. The meaning is the same as in the case of the loop information table 32.
Thus, the loop information table 32 and the conditional branch information table 33 indicate the presence / absence / number of loops (for statements and while statements) and conditional branches (if statements and switch statements) existing between functions. It is a thing.
[Details of Step 500]
In the process of step 500 described above, loop information and conditional branch information are added to the function call sequence information 31 to generate function call relationship information 35 illustrated in FIG.

  FIG. 13 is a flowchart illustrating an example of this process. The function call relation information 35 generated here represents a loop or a conditional branch included in the call sequence in addition to the function call sequence. The function call relation information 35 includes a node 35a, a link 35b, and a node 35c.

  First, it is determined whether or not an unacquired key (function pair) exists in the loop information table 32 (step 501). If there is an unacquired key, an unacquired key is obtained from the loop information table 32 (step 502). The loop information corresponding to the key is obtained from the table 32 (step 503).

  Then, in the function call relation information 35, a node 35c representing loop information is inserted between the nodes 35a of the two functions represented by the keys (step 505), and the process returns to step 501.

If it is determined in step 501 that there is no unacquired function pair, it is determined whether an unacquired key (function pair) exists in the conditional branch information table 33 (step 506).
If it exists, an unacquired key is acquired from the conditional branch information table 33 (step 507), and conditional branch information corresponding to the key is acquired from the conditional branch information table 33 (step 508).

  Then, in the function call relation information 35, a node 35c representing conditional branch information is inserted between the nodes 35a of the two functions represented by the keys (step 509), and the process returns to step 506.

If no unacquired key exists in step 506, the process ends.
[Details of Step 600]
In step 600 described above, the execution frequency illustrated in FIG. 18 is obtained from the function call relationship information 35 described above and the weight definition (weight definition table 42) illustrated in FIG. 15 by the processing of the flowchart illustrated in FIG. An information table 37 is generated. In each call sequence, the weight specified in the weight definition table 42 is added to the included loop or conditional branch. FIG. 17 is a conceptual diagram illustrating the state of the function call relationship information 35 in this process.

From the function call relation information 35 to which the weight is assigned, the total weight in the call sequence is obtained for each call sequence. This result is generated as an execution frequency information table 37.
As illustrated in FIG. 15, the weight definition table 42 holds a type 42 a, a syntax 42 b, and a weight 42 c in association with each other.

As illustrated in FIG. 18, the execution frequency information table 37 holds a call string 37 a and a total weight 37 b in association with each other.
As illustrated in FIG. 19, the rank definition table 43 holds a rank 43 a and a total weight 43 b in association with each other.

  In the execution frequency prediction of FIG. 16, first, the function call relation information 35 and the weight definition table 42 are read (step 601), and it is determined whether there is an unprocessed terminal call (step 602). Here, the “terminal call” means a call represented by #n in the function call relation information 35 of FIG. 14, and is, for example, a node 35a such as # 1, # 2, etc.

If there is an unprocessed end call, the unprocessed “end call” is set as the processing target (step 603), and the total weight (@ 2) is initialized to 0 (step 604).
Then, it is determined whether or not there is an unprocessed “call sequence leading to a terminal call” (step 605). Here, the “call sequence leading to the end call” means the call sequence in which the call indicated by #n comes last in the function call relation information 35 of FIG. For example, in the example of FIG. 14, in the case of # 3, f0 → while → f1 → for → f102 → # 3 and f2 → for → f102 → # 3.

If there is an unprocessed “call sequence leading to the end call” in step 605, the unprocessed “call sequence leading to the end call” is selected as a processing target (step 606).
Then, the call sequence is traced from the top, and a weight is added to each node 35c in accordance with the weight definition in the weight definition table 42 (step 607).

Next, the weights of the respective nodes are summed up to obtain the value (@ 1) in the entire call sequence (branch) (step 608).
After the value (@ 1) of each call sequence is added to the total weight (@ 2) (step 609), the process returns to step 605.

  If it is determined in step 605 that there is no unprocessed “call sequence leading to the end call”, the end call to be processed and its total weight (@ 2) are registered in the execution frequency information table 37. (Step 610), the process returns to Step 602.

At step 602, if there are no outstanding end calls, the process ends.
[Details of Step 700]
Finally, in step 700 described above, from the execution frequency information of the execution frequency information table 37 and the function detection result (FIG. 7) of the detection result table 36 using the rank definition of the rank definition table 43 illustrated in FIG. The detection result report 50 illustrated in FIG. 21 is generated.

  As illustrated in FIG. 19, the rank definition table 43 holds ranks 43 a and weight sums 43 b in association with each other. In the case of the present embodiment, the rank 43a is classified into five stages A to E according to the size of the total weight 43b.

  FIG. 20 shows this processing flow. Here, the value of the execution frequency information table 37 and the rank definition of the rank definition table 43 are collated to obtain the corresponding rank (A to E). The rank and the function detection result are integrated and output as a detection result report 50.

  The detection result table 36, rank definition table 43, and execution frequency information table 37 are read (step 701), and the following steps 703 and 704 are repeated for each row of the detection result table 36 (steps 702 and 705).

That is, the function call ID 36a in the detection result table 36 is searched from the execution frequency information table 37, and the execution frequency (weight total 37b) is acquired (step 703).
For the obtained execution frequency, the total weight 43b in the rank definition table 43 is searched to obtain the corresponding rank (step 704).

Thereafter, the obtained information is sorted by rank to generate a detection result report 50 (step 706).
The generated detection result report 50 is displayed on the display 14, for example.

As illustrated in FIG. 21, the detection result report 50 displays detection IDs 50a, problem ranks 50b, existing locations 50c, and detection functions 50d in association with each other.
As described above, in the case of the present embodiment, the detection result report 50 is automatically selected from the functions specified in the detection function list 41 with a high execution frequency (probably problematic). Since the ranking is displayed, the visibility of the detection result report 50 is extremely high.

A modification of the execution frequency evaluation method will be described below.
A recursive call (a form in which a function calls itself internally) can be regarded as a kind of loop in the same way as a for statement and a while statement in that a program is repeatedly executed.

  When there is a recursive call in the source code 40 as exemplified in FIG. 22A, as an example, the function call sequence information 31 is as shown in FIG. Here, the function call relation information 35 is created by inserting a node 35c indicating a recursive call as shown in FIG. The subsequent processing for generating the execution frequency information table 37 is the same as described above.

FIGS. 24A to 24C show an example of generation processing of the execution frequency information table 37 in the case of this recursive call.
As shown in FIG. 24A, when the function f10 is connected to the terminal call # 6, the function call relation information 35 is set to the “RC” node 35c indicating the recursive call.

In this case, as shown in FIG. 24B, “RC” indicating recursive call is set in the syntax 42b of the weight definition table 42 as the syntax of the loop.
As a result, as illustrated in FIG. 24C, the execution frequency at which the call sequence 37a continues to # 6 is a value reflecting the weight of “RC”.

  In an object-oriented programming language such as Java (registered trademark), there is a mechanism called inheritance. An example of source code 40-1 using inheritance is shown in FIG. Inheritance is the reuse of one class (superclass) to create another class (subclass).

  In general, there is often one superclass and multiple subclasses. As a feature of inheritance, a function with the same name is defined in each class, as in the example of the source code 40-1. As a result, in the code example, a function called f20 is called, and this calls one of f20 of the superclass and the three subclasses (which is actually called is determined at the time of program execution).

That is, not only SuperC f20 but also SubC1 to SubC3 f20 may be called (any one of the four f20s is called).
Therefore, a class function call using inheritance can be regarded as a kind of branch processing. Here, weighting is performed in the same manner as the above-mentioned if sentence and switch sentence. This processing is shown in FIG. 26, FIG. 27, and FIG.

FIG. 26 shows function call sequence information 31 in this case, and FIG. 27 shows function call relation information 35 in this case.
In the function call relation information 35, three "Inh" are added as a node 35d corresponding to succession in addition to the node 35a of f20 itself.

  In the weight definition table 42 illustrated in FIG. 28B, “branch” is set as the type 42a corresponding to inheritance, “Inn” is set in the syntax 42b, and −0. 2 is set, and a corresponding weight is given to “Inn” of the node 35d of the function call sequence information 31 as illustrated in FIG.

As a result, as shown in FIG. 28C, in the execution frequency information table 37, in the terminal call # 7, the execution frequency reflects-. 6
The condition value of the conditional branch can also be used for weighting the execution frequency prediction. That is, weighting is performed in consideration of the condition values of the if sentence and the switch sentence.

  For example, the execution frequency of the error processing part is usually small. Since the error processing part is often expressed as in the source code 40-2 illustrated in FIG. 29A, by looking at the condition value (character string constant, in this case “FILE_IO_ERROR”), It can be predicted whether or not the branch is error processing.

The function call sequence information 31 corresponding to the source code 40-2 is as shown in FIG. 29B, and the determination of the condition value contributes to the prediction of the execution frequency of “end call” of # 8.
To determine whether or not this conditional branch is an error processing part, the variable name or constant name of the condition value is acquired from the source code analysis information 30. Then, matching with a character string such as “ERR” or “ERROR” is performed. When it is determined by matching that the character string has a similar condition value, function call relation information 35 is generated as shown in FIG. 30 corresponding to the function call string information 31 of FIG. In this case, a “Val” node 35 d corresponding to the condition value to be evaluated is added to the function call relation information 35.

  Thereafter, as illustrated in FIG. 31B, the weight definition table 42 is provided with an entry in which the type 42a is a conditional branch and the syntax 42b is “Val”, and the weight 42c is set. ), A weight value corresponding to the “Val” node 35d of the function call relation information 35 is assigned, and the “end call” of # 8 is applied to FIG. An execution frequency information table 37 exemplified in c) is obtained.

  As a similar example, the exception processing represented by the catch clause is usually less frequently executed as is the case with error processing. Therefore, a function call in the catch clause is given a weight that decreases the execution frequency. This example is shown in FIG.

  When the catch clause is included as in the example of the source code 40-3 in FIG. 32A, the function call sequence information 31 is as shown in FIG. 32B, and the exception handling information table 34 is shown in FIG. c), and the function call relation information 35 is as shown in FIG. The exception processing information table 34 includes a function pair 34a and a type 34b.

As a result, the execution frequency can be obtained as the total weight as in the case of the condition value described above.
In general, for example, there are cases in which the user knows in advance which function is frequently executed in a program based on past experience or the use of the program.

  In such a case, the execution frequency prediction processing up to the above can be made more accurate by providing the source code problem prediction program 20 with information related to the function known by the user as described below.

  First, as shown in FIG. 33A, the user designates a function to be executed frequently and its weight using the function weight definition table 44. In this case, the function weight definition table 44 includes a function name 44a and a corresponding weight 44b.

  Using the weight definition in the function weight definition table 44 as an input, the weight is added to the specified function in the function call relation information 35 as illustrated in FIG. Thereafter, by performing the same processing as described above, the execution frequency information table 37 is generated as shown in FIG. 33C, and the execution frequency is predicted from the total weight.

FIG. 34 compares and contrasts the effects of the present embodiment and the conventional reference technique.
In the case of the conventional reference technique, function calls are detected uniformly from the source code. Therefore, in the design review using the same, it is necessary to review all the functions in the same way, which requires a large number of man-hours. Moreover, the visibility of a result is also inferior.

  On the other hand, in the case of the present embodiment, problem functions can be detected with high accuracy by weighting (that is, essential problems are detected intensively). good. Thereby, the man-hour for the design review can be greatly reduced.

  For example, unlike general programs executed on existing computers, embedded software development often involves parallel development of software and actual equipment. Often, it is difficult to conduct a static test early in development.

  At this time, in the case of the present embodiment, effective reviews can be performed at an early stage of the development process by predicting and detecting the problem function or the like with high accuracy as described above. There is an advantage that the code can be improved and corrected.

FIG. 35 is an explanatory diagram showing an example of the operation screen displayed on the display 14 in the source code problem prediction program 20 of the present embodiment and the operation of the evaluation process based on the operation screen.
In the case of the present embodiment, not only the detection result report 50 is simply displayed on the display 14, but also the user evaluates the detection result report 50 and feeds back the evaluation result to various weight settings. The detection accuracy of the problem in the source code 40 can be improved.

  That is, the user evaluation input area 60 is displayed together with the detection result report 50 on the operation screen. This user evaluation input area 60 is provided with a check column 61 and a comment column 62 corresponding to each row of the detection ID 50a on the detection result report 50 side.

  Based on the result of the detection result report 50, the check column 61 is provided with an “improvement” check item 61a indicating that improvement is necessary, and a “no actual harm” check item 61b indicating that the present state is acceptable. Yes.

When “improvement” of the check item 61b is checked, a corresponding countermeasure is described in the comment column 62.
When “no actual harm” in the check item 61a is checked, the function of the detection ID 50a on the detection result report 50 side is determined to have no actual harm even if it is present. From the viewpoint of problem detection, the detection result report 50 can be regarded as noise.

  Therefore, in the case of the present embodiment, the weight value in the weight definition table 42 and the function weight definition table 44 related to the function of the detection ID 50a for which the check item 61a is checked can be changed and detected as a problem. Lower sex and rank.

  That is, in the example of FIG. 35, the items for which the check item 61a “no actual damage” is checked (in this case, the detection ID 50a is # 2 and # 1) are extracted, and the detection correction targets are further narrowed down. In this case, # 1 is already at the lowest rank “E”, and it is determined that the weight change is unnecessary, and the function whose detection ID 50a is # 2 is determined as a weight adjustment target.

  Then, for # 2 determined in this way, the weight setting values in the weight definition table 42, the function weight definition table 44, etc. are changed so that the “probability of problem” rank of the problem rank 50b decreases. In this change, the weight setting item that has less influence on the detection accuracy of other detection results is selected and changed.

The example of FIG. 35 shows an example in which the weight for the conditional branch of the “if” sentence in the weight definition table 42 is reduced.
As a result, as illustrated in FIG. 36, the execution frequency information table 37 changes from FIG. 36 (a) to FIG. 36 (b) before and after the change. In response to this, in the output detection result report 50, the problem rank 50b with the detection ID 50a of # 2 changes from D to the lowest E.

  Thus, for example, if the problem rank 50b is displayed in the descending order of the rank and displayed on the detection result report 50, “No actual harm” # 2 is displayed at the end and becomes inconspicuous as noise in problem detection. improves.

  In the example of FIG. 35, the number of functions in the detection result report 50 is 5. However, in actual evaluation of the source code, the number of functions to be extracted may exceed 1000, as in the present embodiment. The effect of improving the visibility and operability by narrowing down to functions that may be problematic and ranking the output is very large.

As described above, in the case of the present embodiment, the user's evaluation is added to the result output as the detection result report 50, and the detection accuracy of the problem portion of the source code 40 and the visual recognition of the detection result report 50 are further added. And operability can be improved.
Needless to say, the present invention is not limited to the configuration exemplified in the above-described embodiment, and various modifications can be made without departing from the spirit of the present invention.

(Appendix 1)
A process of extracting control structure information related to at least one of a function calling relationship, a repetition structure, and a conditional branch structure included in a program source code;
A process of predicting a specific area that is repeatedly executed at a high frequency when the program is executed from the control structure information;
A process for checking whether there is a call to a specific function given in advance for the specific area, and ranking and displaying the specific function that has existed based on the predicted execution frequency of the specific area;
A source code problem prediction program that causes a computer to execute.
(Appendix 2)
In the source code problem prediction program described in Appendix 1,
Predicting by measuring the number of each of the repeated structure and the conditional branch structure included in the function call sequence, and multiplying the measured value of each number by a weight based on predefined weight definition information The computer program further causes the computer to execute a process for calculating the execution frequency.
(Appendix 3)
In the source code problem prediction program described in Appendix 1,
Extracting the function that performs recursive call, and predicting the processing within the function as the specific region with high execution frequency,
A process of extracting a class group having an inheritance relationship in an object-oriented program and assigning an execution frequency inversely proportional to the number of classes for the function having the same name declared in each class;
For variables and constants that are the condition values of the conditional branch structure, the character string representation of the variables and constants is compared with a character string that represents a predefined error process. A process that assigns a low execution frequency to the processing area,
A process of measuring the number of exception processes included in the function call sequence and assigning an execution frequency inversely proportional to the number of exception processes to each of the functions;
A process of accepting a weight definition from a user for a specific function and assigning an execution frequency to each of the functions using the weight definition;
A source code problem prediction program that causes the computer to execute at least one of the following.
(Appendix 4)
Extracting control structure information relating to at least one of a function calling relationship, a repetition structure, and a conditional branch structure included in a program source code;
Predicting a specific region that is repeatedly executed at a high frequency when the program is executed from the control structure information;
Checking whether there is a call to a specific function given in advance for the specific area, and ranking and displaying the existing specific function based on the predicted execution frequency of the specific area,
A source code problem prediction method comprising:
(Appendix 5)
First means for extracting control structure information related to at least one of a function calling relationship, a repetition structure, and a conditional branch structure included in a program source code;
A second means for predicting a specific area that is repeatedly executed at a high frequency when the program is executed from the control structure information;
A third means for checking whether there is a call to a specific function given in advance for the specific area, and ranking and displaying the specific function that has existed based on the predicted execution frequency of the specific area;
A source code problem prediction apparatus comprising:
(Appendix 6)
In the source code problem prediction apparatus according to attachment 5,
In the second means, the number of each of the repetitive structure and the conditional branch structure included in the function call sequence is measured, and the measured value of each number is weighted based on predefined weight definition information. A source code problem prediction apparatus characterized by calculating the execution frequency predicted by multiplying.
(Appendix 7)
In the source code problem prediction apparatus according to attachment 5,
The source code problem prediction apparatus characterized in that the second means extracts the function that performs recursive calls and predicts the processing in the function as the specific area with high execution frequency.
(Appendix 8)
In the source code problem prediction apparatus according to attachment 5,
In the second means, a class group having an inheritance relationship in the object-oriented program is extracted, and an execution frequency inversely proportional to the number of classes is assigned to the function having the same name declared in each class. Source code problem prediction device.
(Appendix 9)
In the source code problem prediction apparatus according to attachment 5,
In the second means, for the variables and constants that are the condition values of the conditional branch structure, the character string representation of the variables and constants is collated with a character string representing a predefined error process, and if the similarity is high A source code problem prediction apparatus, wherein a low execution frequency is assigned to a processing area executed when a condition is matched.
(Appendix 10)
In the source code problem prediction apparatus according to attachment 5,
In the second means, the number of exception processes included in the function call sequence is measured, and an execution frequency inversely proportional to the number of exception processes is allocated to each of the functions. .
(Appendix 11)
In the source code problem prediction apparatus according to attachment 5,
An apparatus for predicting source code problems, wherein a weight definition from a user for a specific function is received, and the second means assigns an execution frequency to each function using the weight definition.

It is a conceptual diagram which shows an example of an effect | action of the source code problem prediction program and method which are one embodiment of this invention. It is a conceptual diagram which shows an example of a structure of the source code problem prediction apparatus which implements the source code problem prediction program and method which are one embodiment of this invention. It is a flowchart which shows an example of an effect | action of the source code problem prediction program and method which are one embodiment of this invention. It is explanatory drawing which shows an example of the source code processed with the source code problem prediction program which is one embodiment of this invention. It is explanatory drawing which shows an example of the source code analysis information produced | generated with the source code problem prediction program which is one embodiment of this invention. It is a conceptual diagram which shows the structural example of the detection function table entered into the source code problem prediction program which is one embodiment of this invention. It is a flowchart which shows an example of the function detection process in the source code problem prediction program which is one embodiment of this invention. It is a conceptual diagram which shows an example of the detection result table output with the source code problem prediction program which is one embodiment of this invention. It is a flowchart which shows an example of the extraction process of the function call sequence information in the source code problem prediction program which is one embodiment of this invention. It is a conceptual diagram which shows an example of the function call sequence information extracted in the source code problem prediction program which is one embodiment of the present invention. It is a flowchart which shows an example of the extraction process of the loop information in the source code problem prediction program which is one embodiment of this invention. It is a conceptual diagram which shows an example of the loop information table output in the source code problem prediction program which is one embodiment of this invention. It is a conceptual diagram which shows an example of the conditional branch information table output in the source code problem prediction program which is one embodiment of this invention. It is a flowchart which shows an example of the extraction process of the function call related information in the source code problem prediction program which is one embodiment of this invention. It is a conceptual diagram which shows an example of the function call relationship information output in the source code problem prediction program which is one embodiment of this invention. It is a conceptual diagram which shows an example of the weight definition table input into the source code problem prediction program which is one embodiment of this invention. It is a flowchart which shows an example of the execution frequency prediction process in the source code problem prediction program which is one embodiment of this invention. It is the conceptual diagram which illustrated the state of the function call relation information in the execution frequency prediction process of the source code problem prediction program which is one embodiment of this invention. It is a conceptual diagram which shows an example of the execution frequency information table output in the source code problem prediction program which is one embodiment of this invention. It is a conceptual diagram which shows an example of the rank definition table input into the source code problem prediction program which is one embodiment of this invention. It is a flowchart which shows an example of the output process of the detection result report in the source code problem prediction program which is one embodiment of this invention. It is a conceptual diagram which shows an example of the detection result report output in the source code problem prediction program which is one embodiment of this invention. (A) And (b) is a conceptual diagram which shows an example of the function call relationship information corresponding to the example of a source code including a recursive call processed in the source code problem prediction program which is one embodiment of the present invention. . It is a conceptual diagram which shows an example of the function call relationship information output in the source code problem prediction program which is one embodiment of this invention. (A)-(c) is a conceptual diagram which shows the example of the production | generation process of the execution frequency information table in the case of a function recursive call. It is a conceptual diagram which shows an example of the source code containing the inheritance input into the source code problem prediction program which is one embodiment of this invention. It is a conceptual diagram which shows an example of the function call sequence information output corresponding to the source code containing inheritance in the source code problem prediction program which is one embodiment of the present invention. In the source code problem prediction program which is one embodiment of this invention, it is a conceptual diagram which shows an example of the function call relationship information output corresponding to the source code including inheritance. (A)-(c) is a conceptual diagram which shows an example of the weighting process with respect to the source code containing inheritance. (A), (b) is a conceptual diagram in the case of using the condition value of a conditional branch for execution frequency prediction in the source code problem prediction program which is one embodiment of the present invention. It is a conceptual diagram which shows an example of the function call relationship information containing a condition value output in the source code problem prediction program which is one embodiment of this invention. (A)-(c) is a conceptual diagram which shows an example of the weighting process of the function call related information containing a condition value in the source code problem prediction program which is one embodiment of this invention. (A)-(d) is a conceptual diagram which shows the example of generation | occurrence | production of the function call relationship information in the source code containing exception processing in the source code problem prediction program which is one embodiment of this invention. (A)-(c) is a conceptual diagram which shows the example of a function weighting process by the user in the source code problem prediction program which is one embodiment of this invention. It is explanatory drawing which compares and contrasts the effect in the case of the source code problem prediction technique which is one embodiment of this invention, and the case of the conventional reference technique. It is explanatory drawing which shows an example of the operation | movement screen in the source code problem prediction program which is one embodiment of this invention, and the effect | action of weight adjustment using the same (A)-(c) is a conceptual diagram which shows an example of the optimization of the detection result by weight adjustment.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Information processing apparatus 11 Central processing unit 12 Main memory 13 External storage device 14 Display 15 Information input device 16 Network interface 17 Information network 18 Operating system 20 Source code problem prediction program 21 Lexical and syntax analysis unit 22 Detection unit 23 Function call sequence extraction Unit 24 loop information extraction unit 25 conditional branch extraction unit 26 exception processing information extraction unit 27 function call relation information generation unit 28 execution frequency prediction unit 29 report output unit 30 source code analysis information 30a node 31 function call sequence information 31a node 31b link 32 Loop information table 32a Function pair 32b Type 33 Conditional branch information table 33a Function pair 33b Type 34 Exception handling information table 34a Function pair 34b Type 35 Function call relation information 35a Node 35b Link 35c node

35d Node 36 Detection result table 36a Call ID
36b Location 36c Detection function 37 Execution frequency information table 37a Call sequence 37b Total weight 40 Source code 40-1 Source code 40-2 Source code 40-3 Source code 41 Detection function list 41a Class name 41b Method name 41c Argument type 42 Weight definition table 42a Type 42b Syntax 42c Weight 43 Rank definition table 43a Rank 43b Total weight 44 Function weight definition table 44a Function name 44b Weight 50 Detection result report 50a Detection ID
50b Problem rank 50c Location 50d Detection function 60 User evaluation input area 61 Check field 61a Check item 61b Check item 62 Comment field

Claims (3)

A process of extracting control structure information related to at least one of a function calling relationship, a repetition structure, and a conditional branch structure included in a program source code;
A process of predicting a specific area that is repeatedly executed at a high frequency when the program is executed from the control structure information;
A process for checking whether there is a call to a specific function given in advance for the specific area, and ranking and displaying the specific function that has existed based on the predicted execution frequency of the specific area;
A source code problem prediction program that causes a computer to execute. The source code problem prediction program according to claim 1,
Predicting by measuring the number of each of the repeated structure and the conditional branch structure included in the function call sequence, and multiplying the measured value of each number by a weight based on predefined weight definition information The computer program further causes the computer to execute a process for calculating the execution frequency. The source code problem prediction program according to claim 1,
Extracting the function that performs recursive call, and predicting the processing within the function as the specific region with high execution frequency,
A process of extracting a class group having an inheritance relationship in an object-oriented program and assigning an execution frequency inversely proportional to the number of classes for the function having the same name declared in each class;
For variables and constants that are the condition values of the conditional branch structure, the character string representation of the variables and constants is compared with a character string that represents a predefined error process. A process that assigns a low execution frequency to the processing area,
A process of measuring the number of exception processes included in the function call sequence and assigning an execution frequency inversely proportional to the number of exception processes to each of the functions;
A process of accepting a weight definition from a user for a specific function and assigning an execution frequency to each of the functions using the weight definition;
A source code problem prediction program that causes the computer to execute at least one of the following.