JP7469999B2 - Search device, search method, and search program - Google Patents

Description

The present invention relates to a search device, a search method, and a search program for searching information.

When a malfunction occurs in a system, a "similarity review" is sometimes performed to check whether a similar malfunction occurs in other parts of the system or in other systems. If a similar review finds that there is a possibility of a similar malfunction occurring, the similar malfunction is corrected, improving the quality of the system. However, because the types of malfunctions that are subject to review are diverse, mechanical support is difficult, and so a similarity review is performed manually. Manual similarity reviews require a huge amount of work, which is problematic. Patent Document 1 is an example of prior art that mechanizes similarity reviews.

Patent Document 1 discloses a vulnerability auditing device that detects only those places where a vulnerable library is not used appropriately. This vulnerability auditing device reads a vulnerability-related judgment rule from a storage unit that stores the judgment rule, which is a predefined judgment rule that associates a function name with the position of the argument of the function where an invalid value may be set, performs syntax analysis of the audited program, extracts variables whose values are input from outside in the audited program that has been subjected to the syntax analysis, tracks them along the processing flow, and, if the tracked variable is used in a function defined in the judgment rule and in the position of the argument of the function, judges whether the variable is used in a conditional expression including a comparison operator, and if the judgment is negative, generates a warning message and outputs it to a screen or file.

JP 2011-150716 A

In Patent Document 1, the similarity review that can be mechanized is limited. In addition, because it is not possible to identify parts with data dependency or control dependency, parts necessary for determining whether a similar defect occurs must be individually located manually. Furthermore, if there are multiple similar review parts, the technology must be implemented multiple times, and the number of similar review parts may reach several hundred. The same is true when searching for any part, not just similar review parts.

The present invention aims to improve search efficiency.

A search device according to one aspect of the invention disclosed in this application is a search device having a processor and a storage device accessible to the processor, wherein the processor executes the following steps: a search process for searching for candidate locations for correction from source code based on candidate conditions for searching for candidate locations for correction within the source code; an input process for accepting input of programmatic dependencies with the candidate conditions and attributes to be assigned to candidate locations for correction that match the candidate conditions or candidate locations that do not match the candidate conditions; a sorting process for assigning an attribute to candidate locations for correction that match the sorting conditions input by the input process if the attribute has been input, and for candidate locations for correction that do not match the sorting conditions for dependency input by the input process if the attribute has been input to be assigned to candidate locations for correction that do not match the sorting conditions; and an output process for outputting the sorting results obtained by the sorting process.

According to a representative embodiment of the present invention, it is possible to improve search efficiency. Problems, configurations, and effects other than those described above will become clear from the explanation of the following examples.

FIG. 1 is an explanatory diagram showing an example of a source code similar defect location. FIG. 2 is an explanatory diagram showing an example of a support system for searching for similar defect locations in source code. FIG. 3 is a block diagram illustrating an example of a hardware configuration of the search device. FIG. 4 is an explanatory diagram illustrating an example of source code. FIG. 5 is an explanatory diagram showing an example of search conditions given to the search device. FIG. 6 is a flowchart of an example of a search process procedure performed by the search device according to the first embodiment. FIG. 7 is an explanatory diagram showing a first example of a search result. FIG. 8 is an explanatory diagram showing a second example of the search results. FIG. 9 is a flowchart of an example of a search process procedure performed by the search device according to the second embodiment. FIG. 10 is an explanatory diagram showing an example of an input screen for candidate conditions. FIG. 11 is an explanatory diagram showing Example 1 of the sorting condition input screen. FIG. 12 is an explanatory diagram showing Example 2 of the sorting condition input screen.

<Source code similar defects>
1 is an explanatory diagram showing an example of a similar defect location in source code. Here, a case is taken as an example in which a developer D0 developing source code SC0 of case 0 discovers a defect in common process AA in source code SC0 and creates a similarity review investigation request 100. The similarity review investigation request 100 may be, for example,
"When common process AA is called with a second argument of 10, a problem occurs.
For similar review, please check below.
1. Are you using common processing AA? (Check item 101)
2. Is there a case where common process AA is called with the second argument set to 10? (Confirmation item 102)
The content is distributed to each developer D1 to Dn. If each developer D1 to Dn were to manually review and investigate similar defects in this way, the review man-hours would increase and development efficiency would decrease. Therefore, it is necessary to efficiently detect similar source code defects.

<Example of support for searching for similar source code defects>
2 is an explanatory diagram showing an example of a source code similar defect location search support. A source code SCi includes a common process AA and is a source code that is a target of a source code similar defect location search support by the search device 200. i is an integer that satisfies 1≦i≦n.

The search device 200 accepts common process AA of confirmation item 101 from developer Di as a candidate condition for the part to be corrected, searches for lines including common process AA (hereinafter referred to as hit lines) from source code SCi (step S200), and outputs search result R200. The search result R200 includes correction candidate parts identified by the line number # of the hit line and the description content of the hit line.

Next, the search device 200 accepts from the developer Di a first sorting condition for narrowing down the line closest to the line in which the second argument of the common process AA of the confirmation item 102 appears, sorts the candidate correction parts of the search result R200 of the candidate parts (step S201), and outputs the first sorting result R201. The first sorting result R201 is a sorting result in which the most recent line is added to the candidate correction parts of the search result R200. Specifically, for example, each hit line of the first sorting result R201 includes the most recent line (underlined character string). In addition, the first sorting result R201 is data in which the column "target" indicating whether or not the line is to be corrected is added to the search result R200. Here, all lines are marked with "?", meaning that it is not possible to distinguish whether they are to be corrected or not, and therefore further subdivision is required.

Next, the search device 200 accepts a second sorting condition for hit lines in the first sorting result R201 that do not satisfy some of the confirmation items 102, sorts the correction candidate parts of the first sorting result R201 (step S202), and outputs the second sorting result R202. The second sorting condition is, for example, a sorting condition that "lines whose second argument contains a constant other than '10' are excluded from the target."

In the second sorting result R202, the hit line in line number #1 and the line immediately preceding it cause the second argument in line number #1 to be filled with the constant "11" rather than "10". Therefore, the correction candidate part in line number #1 satisfies the second sorting condition, so the target is set to "X" (meaning not to be corrected). On the other hand, the correction candidate parts in line numbers #2 and #YY do not satisfy the second sorting condition, so the target is set to "?" (meaning subdivision).

Next, the search device 200 accepts a third sorting condition for hit lines in the second sorting result R202 that do not satisfy some of the confirmation items 102, sorts the correction candidate parts of the second sorting result R202 (step S203), and outputs the third sorting result R203. The third sorting condition is, for example, a sorting condition that "lines that have a control process that is executed only when the second argument is not "10" are excluded from the target."

In the third sorting result R203, due to the hit line of line number #YY and the line immediately preceding it, line number #YY is a line with a control process that is executed only if the second argument is not "10". Therefore, the correction candidate part of line number #YY satisfies the third sorting condition, so the target is set to "X". On the other hand, the correction candidate part of line number #2 does not satisfy the second exclusion condition, so the target remains "?".

Developer Di refers to the third sorting result R203 and visually determines whether line number #2 is a line that corresponds to confirmation items 101 and 102. If it is determined that line number #2 is a line that corresponds to confirmation items 101 and 102, the search device 200, through the operation of developer Di, changes the target of line number #2 in the third sorting result R203 from "?" to "O" (indicating a target for correction).

In this way, a mechanical search for similar review is possible, which allows for a collective search for a variety of defects while also taking into account data dependency and control dependency. This makes it possible to reduce the man-hours required for similar review, and to efficiently narrow down similar defect locations in source code SCi. This will be described in detail below in Examples 1 and 2. Examples 1 and 2 are applicable to the case where any location is searched, not limited to similar review locations.

Example 1 is an example in which search conditions including the above-mentioned candidate conditions and one or more sorting conditions connected to the candidate conditions in the order of execution are set in advance, and the search device searches using the search conditions.

<Example of Hardware Configuration of Search Device 200>
3 is a block diagram showing an example of a hardware configuration of the search device 200. The search device 200300 has a processor 301, a storage device 302, an input device 303, an output device 304, and a communication interface (communication IF) 305. The processor 301, the storage device 302, the input device 303, the output device 304, and the communication IF 305 are connected by a bus 306. The processor 301 controls the search device 200. The storage device 302 is a working area for the processor 301. The storage device 302 is a non-temporary or temporary recording medium that stores various programs and data. Examples of the storage device 302 include a ROM (Read Only Memory), a RAM (Random Access Memory), a HDD (Hard Disk Drive), and a flash memory. The input device 303 inputs data. The input device 303 may be, for example, a keyboard, a mouse, a touch panel, a numeric keypad, or a scanner. The output device 304 outputs data. The output device 304 may be, for example, a display, a printer, or a speaker. The communication IF 305 connects to a network and transmits and receives data.

<Source code>
Fig. 4 is an explanatory diagram showing an example of source code. For the sake of convenience, the source code SCi in Fig. 4 has different contents from the source code SCi shown in Figs.

<Search conditions>
5 is an explanatory diagram showing an example of search conditions given to the search device 200. The search conditions 500 start with a candidate condition 501, followed by zero or more sorting conditions 510A, 510B, ... (when no distinction is made between these, the sorting condition 510 is simply written). The candidate condition 501 is a condition for searching for candidates for a portion to be corrected from the source code SCi, and is a condition that can mechanically extract a statement (also called a command) from the source code SCi, such as "a statement containing the character string "XXX"" or "a statement calling the function func1". The statement extracted by the candidate condition 501 is called the portion to be corrected.

On the other hand, the sorting conditions 510 are conditions for sorting the correction candidate parts extracted based on the candidate conditions 501. The sorting conditions 510 include conditions for narrowing down the correction candidate parts, or for searching for related parts immediately before and/or after the part. Here, the related parts are parts related through data dependencies or control dependencies.

A data dependency is a relationship between a statement and a statement that calculates the value of another variable that is used to calculate the value of a variable whose value is updated in that statement. In other words, it is a relationship in which data used in a previous instruction is used to execute a later instruction, and there is a possibility that the results will change if those instructions are executed interchangeably. For example, "the first argument in a function call is "a"" shows a data dependency.

A control dependency is a relationship between a statement and a conditional branch statement that determines whether or not the statement is executed. In other words, it is a relationship between a branch instruction and a subsequent instruction, in which whether or not the instruction following the branch instruction is executed is not determined until execution of the branch instruction is completed and the branch destination address is determined. For example, "there is a conditional branch regarding variable Y" indicates a data dependency.

In addition, sorting results 502A-502D (simply sorting result 502 when no distinction is made between the cases where the conditions are met and where the conditions are not met) are associated with the sorting conditions 510. There are at least three types of sorting results 502: "subject to correction," "not subject to correction," and "subdivision," and when sorting result 502 is "subdivision," another sorting condition 510 is associated with it.

"To be corrected" refers to areas that should be corrected. "Not to be corrected" refers to areas that should not be corrected. "Subdivision" means that it is not known at this point whether or not something should be corrected, and further detailed analysis is required using classification criteria.

In other words, the search conditions 500 have a tree structure in which the candidate conditions 501 are the only root and the sorting conditions 510 are linked. For example, when the conditions are met (solid arrow), the sorting result 502 is a subdivision (sorting result 502A), so sorting condition 510B is further associated with sorting condition 510A. Note that a type such as "individual investigation" may be set for the sorting result 502, and correction candidate parts classified into that type may be clearly classified by the user as to be corrected or not to be corrected manually after using the search device 200.

The CID is identification information that identifies the candidate condition 501 or sorting condition 510 for which the sorting result 502 has been finalized.

<Search support processing procedure>
6 is a flowchart showing an example of a search support process procedure by the search device 200 according to the first embodiment. The source code SCi and the search condition 500 are provided to the search device 200. The search device 200 analyzes the source code SCi (step S601). This analysis can obtain syntax elements, syntax trees, data dependencies, control dependencies, and function call relationships. This analysis can be realized by the same technology as existing compilers and static analysis tools.

Next, the search device 200 searches the source code SCi using the candidate conditions 501 of the search conditions 500, and extracts candidate correction portions (step S602). Then, the search device 200 repeatedly selects unselected sorting conditions 510 until there are no unselected sorting conditions 510 (step S603). Here, as an example, it is assumed that the sorting conditions 510 are selected in the tree structure of the search conditions 500 in order from the root to the ends.

The search device 200 searches for potential correction locations based on the sorting conditions 510 selected in step S603 (step S604). Specifically, for example, the search device 200 searches for candidate conditions 501 that are the immediate parents of the sorting conditions 510, or potential correction locations obtained from the sorting conditions 510. For example, if the selected sorting conditions 510 are sorting conditions 510A, the immediate parent candidate conditions 501 are searched for as potential correction locations. Also, if the selected sorting conditions 510 are sorting conditions 510B, the sorting results 502A (subdivisions) obtained as a result of sorting using the sorting conditions 510A are searched for as potential correction locations.

When there are no unselected sorting conditions 510, the search device 200 ends the search in step S604 (step S605) and outputs the search results (step S606). Here, a specific example of the search results will be described.

<Example of search results>
Fig. 7 is an explanatory diagram showing a search result example 1. Fig. 8 is an explanatory diagram showing a search result example 2. A search result 700A in Fig. 7 and a search result 700B in Fig. 8 (when there is no need to distinguish between them, they are simply referred to as search result 700) include at least a correction candidate portion to be corrected and a line number 702 indicating the position of the correction candidate portion in the source code SCi.

Specifically, for example, search result 700 includes item number 701, line number 702, correction candidate location 703, and attribute 704. In search result 700A of FIG. 7, in the entry with item number 701 of "1", for function func1 of candidate condition 501, "func1("a", "b")" with line number 702 of "3" in source code SCi is the correction candidate location 703. Since "func1("a", "b")" satisfies sorting condition 510A and sorting condition 510B, its attribute 704 is the "subject to correction" indicated by sorting result 502C.

In addition, in the entry with item number 701 "2", for function func1 of candidate condition 501, "x="c"" with line number 702 in source code SCi of "3" and "func1("x", "b")" with line number 702 of "14" are candidate correction locations 703. "x="c"" and "func1("x", "b")" satisfy sorting condition 510B but do not satisfy sorting condition 510A. Therefore, attribute 704 is "not to be corrected" as indicated by sorting result 502D.

In addition, in FIG. 8, in the search result 700B, the correction candidate portion 703 further has a matching condition 705 indicating whether the condition is matched/not matched in each sorting condition 510, and the attribute 704 has a CID that identifies the candidate condition 501 or sorting condition 510 for which the sorting result 502 has been confirmed.

For example, in an entry with item number 701 of "1", for function func1 in candidate condition 501, "func1("a", "b")" with line number 702 of "3" in source code SCi is the correction candidate location 703. "func1("a", "b")" satisfies candidate condition 501 specified by CID00 of match condition 715 (indicated by a circle), satisfies sorting condition 510A specified by CID01 of match condition 715 (indicated by a circle), and satisfies sorting condition 510BA specified by CID02 of match condition 715 (indicated by a circle). Therefore, its attribute 704 becomes the "target for correction" indicated by sorting result 502C.

In the entry with item number 701 "2", for function func1 in candidate condition 501, "x="c"" in line number 702 "3" in source code SCi and "func1("x", "b")" in line number 702 "14" are candidate correction locations 703. "func1("x", "b")" satisfies CID00 to CID01 in matching condition 715 (indicated by a circle), but "x="c"" and "func1("x", "b")" do not satisfy CID02 in matching condition 715. Therefore, its attribute 704 is "not to be corrected" as indicated by classification result 502D.

In this way, by including the candidate conditions 501 or sorting conditions 510 for which the sorting results 502 have been finalized in the search results 700B, the user can use them, for example, in a review to confirm that the similarity review has been performed correctly. Note that whether or not to include the matching conditions 705 in the search results 700 is set in advance in the search device 200.

Here, we will explain why the search device 200 can support similarity review. In similarity review, the functions, data types, variables, constants, etc. that caused the malfunction are identified in advance, and the conditions under which the malfunction occurs are also clearly defined. Therefore, in similarity review, in the system that is the subject of similarity review, the search device 200 checks whether all the places that use the functions, data types, variables, constants, etc. of interest meet the conditions under which the malfunction occurs.

In order to ensure that the conditions for a bug to occur are not met at the point of use of the function, data type, variable, constant, etc. that caused the bug, the state in which the bug will occur must not have occurred immediately before the point of use when the program is executed. The state at the point of use is determined at a point (called the state determination point) immediately before the point of use where there is a relationship such as data dependency or control dependency. Therefore, a bug will occur if no effort is made to prevent the state at the state determination point from becoming a state in which the bug will occur. In other words, similarity review identifies the point of use, identifies the state determination point, and checks whether appropriate effort has been made at the state determination point.

The search device 200 mechanically identifies the use location using the candidate conditions 501, and identifies the status determination location using the sorting conditions 510, and mechanically determines whether or not there is a valid innovation at the status determination location, making it possible to search for similar revisions.

Next, Example 2 will be described. The search device 200 according to Example 2 is an example in which candidate conditions 501 and sorting conditions 510 are input sequentially, and search results and sorting results are output. The user refers to the search results and sorting results, and inputs the next sorting result to the search device 200. In Example 2, the differences from Example 1 will be mainly described, and therefore the same contents as in Example 1 will not be described.

In general, there are a wide variety of ways to prevent defects from occurring, so it is difficult to create search conditions 500 that correspond to all similarity reviews. Therefore, in order to be able to create search conditions 500 while taking into account the actual measures in the system to be similarly revised, it is necessary to input and display search conditions and display search results 700.

When the search device 200 accepts input of candidate conditions 501 through user operation and displays the search results 700, the process of displaying the search results 700 continues each time the user sequentially accepts input of new sorting conditions, until no more sorting conditions 510 are input by the user.

<Search processing procedure>
9 is a flowchart showing an example of a search process procedure by the search device 200 according to the second embodiment. The search device 200 analyzes the source code (step S901) in the same manner as in step S601, and receives input of candidate conditions 501 by a user operation (step S902). Here, an example of input of the candidate conditions 501 will be described.

Figure 10 is an explanatory diagram showing an example of an input screen for candidate conditions 501. Input screen 1000 is a screen that accepts input of candidate conditions 501 that mechanically extract statements from source code SCi. In the example of Figure 10, input screen 1000 has an element type input field 1001, a role input field 1002, and a search string input field 1003.

The element type input item 1001 is an item that accepts the selection of the type of syntax element to be searched for via a pull-down menu. The type of syntax element to be searched for is, for example, an element that can be an identifier of the programming language to be searched for, such as a constant, function, variable, class, or type.

The role input item 1002 is an item that accepts the selection of the role of a syntax element via a pull-down menu. The role of a syntax element is the function assigned to various syntax elements in the source code SCi, such as declaring, defining, initializing, updating, and referencing variables, and declaring, defining, and calling functions.

The search string input field 1003 is an input field that accepts input of a search string that narrows down the syntax elements to be searched. Note that if a search string is only entered into the search string input field 1003, there is a possibility that comments in the source code SCi will also be hit, so by selecting an element type or role, it is possible to reduce the number of hits from comments.

The input screen 1000 may have at least one of the element type input field 1001, the role input field 1002, and the search string input field 1003. In addition to the element type input field 1001, the role input field 1002, and the search string input field 1003, the input screen 1000 may also have an input field for selecting a matching method for the search string (exact match, forward match, backward match, regular expression, etc.).

The input screen 1000 may also have an input field that can be given any name so that the candidate conditions 501 and sorting conditions 510 of the search conditions 500 can be distinguished. Furthermore, the input screen 1000 may have a button or the like that takes into consideration the case where similarity review is completed using only the candidate conditions 501. In addition, the input screen 1000 may have a field that allows the type name, etc. to be used in the search, and may have a field that allows the search string to be selected from the identifier names included in the source code SCi.

Returning to FIG. 9, the search device 200 searches the source code SCi with the candidate condition 501 input from the input screen 1000, and extracts the correction candidate portion 703 (step S903). The search device 200 then outputs the search result 700B1 of step S903 (step S904). The search result 700B1 is displayed, for example, on a display that is an example of the output device 304 of the search device 200, or on a display of a computer that can communicate with the search device 200. In the search result 700B1 of FIG. 10, the line number 702 of the line containing "func1" in the source code SCi and the correction candidate portion 703 are displayed as hit lines.

Next, the search device 200 accepts input of sorting conditions 510 from the user until no more sorting conditions 510 are input (step S905).

Figure 11 is an explanatory diagram showing Example 1 of the input screen for sorting conditions 510. The input screen 1100 for sorting conditions 510 is a screen used when checking whether or not a specific element is present in a correction candidate portion. In addition to the element type input field 1001, role input field 1002, and search string input field 1003 described above, the input screen 1100 for sorting conditions 510 also includes a focus target selection field 1101, a search direction selection field 1102, a range restriction selection field 1103, a matching attribute selection field 1104, and a non-matching attribute selection field 1105.

The focus target selection item 1101 is an item that accepts the selection of the focus target via a pull-down menu. In sorting based on the sorting conditions 510, attention is paid to at least one of the sentences included in the correction candidate section 703, and a mechanical investigation is performed to determine whether or not the condition is met for that sentence or the sentences before and after that sentence. The input item for selecting this focus sentence (focus target) is the focus target selection item 1101.

The focus selection item 1101 allows the user to select any candidate condition 501 or sorting condition 510 that is closer to the parent in the tree structure of the search conditions 500. However, the only sorting conditions 510 that can be selected are sorting results 502 that match the conditions.

Search direction selection item 1102 is an item that accepts the selection of the search direction via a pull-down menu. The pull-down menu of search direction selection item 1102 includes, for example, "Same statement/control condition," "Forward," and "Backward." "Same statement/control condition" indicates that the search destination of sorting condition 510 is the target of interest. "Forward" indicates that the search destination of sorting condition 510 is the sentence ahead of the target of interest.

Note that the "forward" sentence is not limited to the sentence immediately preceding the target of interest, but may be a predetermined number of sentences, two or more, that are set in advance. "Backward" indicates that the sorting condition 510 searches for a sentence that is later than the target of interest. Note that the "backward" sentence is not limited to the sentence immediately following the target of interest, but may be a predetermined number of sentences, two or more, that are set in advance.

The range restriction selection item 1103 is an item used when you want to focus on another sentence in addition to the sentence of interest selected in the focus target selection item, and specify conditions for the sentence between the two sentences. Therefore, if the search direction is "same statement/control condition", this item is invalid. When selecting a sentence to focus on in the range restriction selection item 1103, the user can select one of the candidate conditions 501 or sorting conditions 510 that are closer to the parent in the tree structure of the search conditions 500, just like the focus target.

The match attribute selection item 1104 is an item for selecting a match attribute. A match attribute is an attribute that is assigned to a sorting result 502 that matches the sorting conditions when searched for by sorting conditions. The mismatch attribute selection item 1105 is an item for selecting a mismatch attribute. A mismatch attribute is an attribute that is assigned to a sorting result 502 that does not match the sorting conditions when searched for by sorting conditions.

In the matching attribute selection item 1104 and the mismatching attribute selection item 1105, "Subject to correction" is an option for displaying in the search results that the correction candidate portion should be corrected. "Not subject to correction" is an option for displaying in the search results that the correction candidate portion should be excluded from the correction candidate portions. "Refine" is an option for displaying in the search results that it is not known at this point whether the correction candidate portion should be corrected or not, and therefore further detailed analysis is required using sorting criteria. "Individual investigation" is an option for displaying in the search results that the search results should be visually investigated individually.

Figure 12 is an explanatory diagram showing example 2 of an input screen for sorting conditions 510. The input screen 1200 in Figure 12 is a screen that can also take into account the syntax tree of the correction candidate portion. The input screen 1200 is a screen for searching, for example, when the name of the first argument of a function that is a candidate condition is unknown during the search, and the first argument of the function appears, for example, forward.

The input screen 1200 has an element type input field 1001, a role input field 1002, a focus selection field 1101, a search direction selection field 1102, a range restriction selection field 1103, a matching attribute selection field 1104, and a non-matching attribute selection field 1105, as well as a first structure selection field 1201, a second structure selection field 1202, a third structure selection field 1203, a first specification field 1204, a first detailed specification field 1205, a second specification field 1206, and a second detailed specification field 1207.

The first structure selection item 1201 to the third structure selection item 1203 are items that accept selections from a pull-down menu of variations of the syntax tree of the sentence selected in the focus target selection item 1101, in increasing detail starting from the root of the syntax tree. For example, if the focus target sentence contains "a=1", "b=func1()", "b=func2(1,2)", and "func2(2,func1())", and if variables are represented by "Vn", functions by "Fn", and constants by "Cn", the options for the first structure selection item 1201 are "V1=V2", "V1=F1()", and "Not specified".

At this time, if the user selects "V1 = V2" in the first structure selection item 1201, the second structure selection item 1202 is added, and the options are "V1 = C1", "V1 = F1()", and "Not specified".

Here, if the user selects "V1=F1()" in the second structure selection item 1202, a third structure selection item 1203 is added, and its options become "V1=F1()", "V1=F2(V2, V3)", and "Not specified".

The first specified item 1204, the first detailed specified item 1205, the second specified item 1206, and the second detailed specified item 1207 correspond to the variables and functions included in the last selected item other than "No specification" (in the case of Figure 12, the second structure selection item 1202) among the first structure selection item 1201 to the third structure selection item 1203.

For example, the first specified item 1204 and the first detailed specified item 1205 correspond to "F1" of the second structure selection item 1202, and the second specified item 1206 and the second detailed specified item 1207 correspond to "V1" of the second structure selection item 1202.

The first specification item 1204 and the second specification item 1206 are items that accept specification of whether to directly specify a search string as a condition such as a variable or function, or to select a syntax element in one of the sorting conditions 510 that is closer to the parent in the tree structure of the search conditions 500. When specifying a search string directly, the user inputs any string that the user wants to target in the first detailed specification item 1205. When selecting a syntax element, the user specifies in the first detailed specification item 1205 a syntax element included in the sorting condition 510 specified in the second specification item 1206.

For example, the first specified item 1204 specifies "func1" as the search string, and the second specified item 1206 specifies "the same variable as the variable "V1" in the structure selection for the sorting condition 510 named "CID01."

Returning to FIG. 9, the search device 200 searches for the parts to be corrected based on the sorting conditions 510 entered on the input screens 1100, 1200 as shown in FIG. 11 or 12 (step S906) and outputs the search results (step S907). The user refers to the search results, and if sorting is desired, the user re-enters the sorting conditions 510 (step S905), and if sorting is not desired, the search device 200 ends the series of processes.

In this way, according to the second embodiment, instead of creating search conditions 500 that correspond to all similarity reviews, it is possible to create search conditions 500 one by one while taking into account the actual state of the innovations to be corrected. Therefore, by performing such a step-by-step search, it is possible to easily create search conditions that identify areas where defects may occur.

The above-mentioned search device 200 can also be configured as follows (1) to (10).

(1) The above-mentioned search device has a processor and a storage device accessible to the processor, and the processor executes a search process that searches for candidate correction locations from the source code based on candidate conditions for searching for candidate correction locations in the source code, a sorting process that sorts the candidate correction locations found by the search process into one of a number of attributes indicating a sorting type based on sorting conditions related to program dependencies with the candidate conditions, and an output process that outputs the sorting results of the sorting process.

This allows you to check how each of the correction candidates should be sorted, improving the efficiency of searching for correction candidates.

(2) In the search device of (1) above, search conditions consisting of the candidate conditions and a series of sorting conditions with different dependencies that are applied sequentially from the candidate conditions are accessible, and in the sorting process, the processor sorts the correction candidate parts into one of the multiple attributes based on a subsequent sorting condition that is in accordance with the sorting result of the previous sorting condition.

This allows you to efficiently narrow down correction candidates with a single search using candidate conditions and multiple sorting conditions.

(3) In the search device of (2) above, the multiple attributes include at least one of a first attribute indicating that the correction candidate portion is to be corrected, a second attribute indicating that it is not to be corrected, or a third attribute indicating that the correction candidate portion requires individual investigation, and in the sorting process, the processor does not sort the correction candidate portion for which the sorting result is the first attribute, the second attribute, or the third attribute.

As a result, if the correction candidate portion has the first attribute, the user knows that the correction candidate portion should be corrected. If the correction candidate portion has the second attribute, the user knows that the correction candidate portion should be excluded from correction. If the correction candidate portion has the second attribute, the user knows that the correction candidate portion needs to be individually investigated.

(4) In the search device of (2) above, the multiple attributes include a fourth attribute indicating that the correction candidate portion requires detailed sorting, and in the sorting process, the processor sorts the correction candidate portion for which the sorting result is the fourth attribute into one of the multiple attributes based on the sorting condition in the latter stage when the sorting result is the fourth attribute based on the sorting condition in the former stage.

As a result, if the correction candidate part is the fourth attribute, the user can input new sorting conditions and obtain the sorting results.

(5) In the search device of (1) above, the source code includes position information of sentences within the source code, and in the output process, the processor outputs the classification result including position information of the candidate correction locations.

This allows the user to see where in the source code the suggested corrections are located.

(6) In the search device of (1) above, the processor executes an input process to accept input of program dependencies with the candidate conditions and attributes to be assigned to candidate correction parts that match the candidate conditions or candidate correction parts that do not match the candidate conditions, and in the sorting process, the processor assigns an attribute to candidate correction parts that match the sorting conditions related to dependencies input by the input process if the attribute has been input, and assigns an attribute to candidate correction parts that do not match the sorting conditions related to dependencies input by the input process if the attribute has been input.

This allows the attributes entered in advance to be automatically assigned to the correction candidate parts sorted based on the candidate conditions. This allows the user to easily understand how to handle the sorted correction candidate parts in the future.

(7) In the search device of (1) above, the processor executes an input process to accept input of program dependencies with the candidate conditions and attributes to be assigned to candidate correction parts that match the sorting conditions or candidate correction parts that do not match the sorting conditions, and in the sorting process, the processor assigns an attribute to candidate correction parts that match the sorting conditions related to the dependencies input by the input process if the attribute has been input, and assigns an attribute to candidate correction parts that do not match the sorting conditions related to the dependencies input by the input process if the attribute has been input.

This allows the attributes entered in advance to be automatically assigned to the correction candidate parts that have been sorted based on the previous sorting conditions. This allows the user to easily understand how to handle the sorted correction candidate parts in the future.

(8) In the search device of (6) above, in the input process, the processor accepts input of the modification candidate location of interest, the search direction in the source code from the location of interest, and the type of syntax element as the dependency relationship.

This allows the search device to include lines of syntax elements that are located away from the focus point in the section to be corrected.

(9) In the search device of (6) above, in the input process, the processor accepts input of the modification candidate location of interest, the search direction in the source code from the location of interest, and a search string as the dependency.

This allows the search device to include lines of the search string that are located away from the focus area in the area to be corrected.

(10) In the search device of (6) above, in the input process, the processor accepts input of sorting conditions related to the syntax tree of the source code, and in the sorting process, for candidate correction parts that match the sorting conditions related to the dependencies and syntax tree input by the input process, the processor assigns the attribute to the candidate correction parts that match the sorting conditions if the attribute has been input, and for candidate correction parts that do not match the sorting conditions related to the dependencies and syntax tree input by the input process, the processor assigns the attribute to the candidate correction parts that do not match the sorting conditions if the attribute has been input.

This makes it possible to search for correction candidates that correspond to the syntax tree even if you cannot specifically identify the name of a syntax element.

The present invention is not limited to the above-described embodiments, but includes various modified examples and equivalent configurations within the spirit of the appended claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to having all of the configurations described. Furthermore, a portion of the configuration of one embodiment may be replaced with the configuration of another embodiment. Furthermore, the configuration of another embodiment may be added to the configuration of one embodiment. Furthermore, other configurations may be added, deleted, or replaced with part of the configuration of each embodiment.

Furthermore, each of the configurations, functions, processing units, processing means, etc. described above may be realized in part or in whole in hardware, for example by designing them as integrated circuits, or may be realized in software by a processor interpreting and executing a program that realizes each function.

Information such as programs, tables, and files that realize each function can be stored in a storage device such as a memory, hard disk, or SSD (Solid State Drive), or in a recording medium such as an IC (Integrated Circuit) card, SD card, or DVD (Digital Versatile Disc).

In addition, the control lines and information lines shown are those considered necessary for explanation, and do not necessarily represent all control lines and information lines necessary for implementation. In reality, it is safe to assume that almost all components are interconnected.

SCi source code 100 Investigation request 101, 102 Confirmation item 200 Search device 301 Processor 302 Storage device 303 Input device 304 Output device 500 Search conditions 501 Candidate conditions 502 Sorting result 510 Sorting conditions 1000, 1100, 1200 Input screen

Claims (9)

A search device having a processor and a storage device accessible to the processor,
The processor,
a search process for searching for candidate correction locations from the source code based on candidate conditions for searching for candidate correction locations in the source code;
an input process for receiving input of program dependencies with the candidate conditions and attributes to be assigned to candidate correction portions that match the candidate conditions or candidate correction portions that do not match the candidate conditions;
a sorting process for assigning an attribute to a correction candidate portion that matches a sorting condition related to a dependency relationship input by the input process if the attribute has been input, and for assigning an attribute to a correction candidate portion that does not match a sorting condition related to a dependency relationship input by the input process if the attribute has been input;
an output process for outputting a sorting result obtained by the sorting process;
A search device that executes the above. The search device according to claim 1,
In the input process, the processor receives, as the dependency relationship, an input of the correction candidate portion to be focused on, a search direction in the source code from the portion to be focused on, and a type of syntax element.
A search device comprising: The search device according to claim 1,
In the input process, the processor receives, as the dependency relationship, an input of the correction candidate portion to be focused on, a search direction in the source code from the portion to be focused on, and a search string.
A search device comprising: The search device according to claim 1,
In the input process, the processor receives an input of a classification condition regarding a syntax tree of the source code;
In the sorting process, the processor assigns an attribute to a correction candidate portion that matches the sorting conditions related to the dependency relationships and syntax trees input by the input process if the attribute has been input and assigns an attribute to a correction candidate portion that does not match the sorting conditions related to the dependency relationships and syntax trees input by the input process if the attribute has been input.
A search device comprising: A search device having a processor and a storage device accessible to the processor,
The processor,
a search process for searching for candidate correction locations from the source code based on candidate conditions for searching for candidate correction locations in the source code;
an input process for receiving input of program dependencies with the candidate conditions and attributes to be assigned to correction candidate portions that match or do not match the sorting conditions related to the dependencies;
a sorting process for assigning an attribute to a correction candidate portion that matches the sorting condition if the attribute has been input, and for assigning an attribute to a correction candidate portion that does not match the sorting condition if the attribute has been input;
an output process for outputting a sorting result obtained by the sorting process;
A search device that executes the above. A search method executed by a search device having a processor and a storage device accessible by the processor, comprising:
The search method includes:
The processor,
a search process for searching for candidate correction locations from the source code based on candidate conditions for searching for candidate correction locations in the source code;
an input process for receiving input of program dependencies with the candidate conditions and attributes to be assigned to candidate correction portions that match the candidate conditions or candidate correction portions that do not match the candidate conditions;
a sorting process for assigning an attribute to a correction candidate portion that matches a sorting condition related to a dependency relationship input by the input process if the attribute has been input, and for assigning an attribute to a correction candidate portion that does not match a sorting condition related to a dependency relationship input by the input process if the attribute has been input;
an output process for outputting a sorting result obtained by the sorting process;
A search method comprising: A search method executed by a search device having a processor and a storage device accessible by the processor, comprising:
The search method includes:
The processor,
a search process for searching for candidate correction locations from the source code based on candidate conditions for searching for candidate correction locations in the source code;
an input process for receiving input of program dependencies with the candidate conditions and attributes to be assigned to correction candidate portions that match or do not match the sorting conditions related to the dependencies;
a sorting process for assigning an attribute to a correction candidate portion that matches the sorting condition if the attribute has been input, and for assigning an attribute to a correction candidate portion that does not match the sorting condition if the attribute has been input;
an output process for outputting a sorting result obtained by the sorting process;
A search method comprising: The processor:
a search process for searching for candidate correction locations from the source code based on candidate conditions for searching for candidate correction locations in the source code;
an input process for receiving input of program dependencies with the candidate conditions and attributes to be assigned to correction candidate portions that match the candidate conditions or correction candidate portions that do not match the candidate conditions;
a sorting process for assigning an attribute to a correction candidate portion that matches a sorting condition related to a dependency relationship input by the input process if the attribute has been input, and for assigning an attribute to a correction candidate portion that does not match a sorting condition related to a dependency relationship input by the input process if the attribute has been input;
an output process for outputting a sorting result obtained by the sorting process;
A search program characterized by executing the above. The processor:
a search process for searching for candidate correction locations from the source code based on candidate conditions for searching for candidate correction locations in the source code;
an input process for receiving input of program dependencies with the candidate conditions and attributes to be assigned to correction candidate portions that match or do not match the sorting conditions related to the dependencies;
a sorting process for assigning an attribute to a correction candidate portion that matches the sorting condition if the attribute has been input, and for assigning an attribute to a correction candidate portion that does not match the sorting condition if the attribute has been input;
an output process for outputting a sorting result obtained by the sorting process;
A search program characterized by executing the above.

Images