JP7799580B2 - Source code analysis device, source code analysis method, and source code analysis program - Google Patents

Description

The present invention relates to a source code analysis device, a source code analysis method, and a source code analysis program.

In recent years, software has become increasingly complex due to repeated functional expansions and changes over many years of derivative development. Software complexity can lead to a decrease in source code readability. Refactoring is used to resolve this situation. Refactoring means changing the internal structure of software without changing its behavior. By appropriately refactoring program components such as methods, classes, and files (hereafter referred to as program elements) that are difficult to maintain, software complexity can be more easily reduced.

One refactoring technique is element splitting. This is a technique in which complex processing written in functions or methods is broken down into smaller units of processing, and then separated into other independent functions or methods. Element splitting makes it possible to break down complex, long, and difficult-to-read source code into simpler, shorter, and more readable source code. This reduces the amount of work required to create unit test cases, modify or change source code, or perform maintenance, and improves the maintainability of the software.

Patent Document 1 describes a method for suggesting where each module should be divided based on source code and module division rule data. This makes it possible to identify where division should be performed from complex source code.

Japanese Patent Application Laid-Open No. 2007-219586

The technique in Patent Document 1 uses source code and module division rule data to determine whether a program corresponds to a location that should be divided, and if so, presents the source code location.

However, the presented division points are not evaluated for source code maintainability using features of program elements obtained by program analysis of the source code (hereinafter referred to as source code metrics). Therefore, it is thought that the method of Patent Document 1 may result in a decrease in source code maintainability when division is performed.

Furthermore, to maintain the readability of source code for developers in the development field, there is a need to avoid splitting existing processing within a certain program element into other elements (hereinafter referred to as developer readability needs). For example, a development practice may be to use conditional branch statements in the source code, but there may be a section where the actual processing is sequential, and the developer would like to describe that section within a single function and understand it as a single function. To meet these developer readability needs, it is necessary to leave the sections that developers do not want split unsplit and split the remaining program elements into elements. In order to split elements while meeting developer readability needs, the method described in Patent Document 1 requires multiple changes to module splitting rule data and repeated source code analysis until the developer in the development field is satisfied. This repetitive work is cumbersome and requires a lot of man-hours.

Furthermore, while improving source code maintainability and developer readability are both important for development, there is often a trade-off between them. If program elements are divided too much in order to improve source code maintainability, developer readability needs may not be met. On the other hand, if an attempt is made to meet all developer readability needs, program elements may not be divided appropriately, which may result in a decrease in source code maintainability.

In this disclosure, we believe that developer readability needs lie in the parts of a program that are frequently executed and that are organized into processes. We address developer readability needs by leaving the parts that are frequently executed in the program as parts that are not split into elements, while at the same time evaluating the maintainability of the source code using source code metrics to indicate where program elements should be split into elements to improve source code maintainability.

In this case, the unit of program element can be any portion of source code with a certain length, such as part of a function, a class, a module, or a structure.

A source code analysis device according to one aspect of the present disclosure is a source code analysis device that analyzes source code corresponding to a program, and includes: a source code metrics calculation unit that calculates source code metrics for each program element included in the program from the source code to be analyzed; a maintainability index calculation unit that calculates a maintainability index for each program element from the source code metrics; a split candidate element generation unit that generates a split candidate element list recording program elements that are candidates for splitting based on the maintainability index and a maintainability index threshold; and a split candidate element generation unit that generates a split candidate element list recording program elements that are candidates for splitting based on the source code, the program, and test cases for the program, and calculates a split candidate element list corresponding to the test cases for each program element included in the split candidate element list. The program includes a program processing tracing unit that generates a dynamic information list that records execution paths, which are portions of the source code corresponding to the processing that is executed when the program is executed based on the dynamic information list; a basic path generation unit that generates, from the dynamic information list and an overlap threshold, a basic path list that records portions of the source code in each of the program elements included in the splitting candidate element list, where the proportion of test cases that include said portions in the execution paths shown in the dynamic information list is equal to or greater than the overlap threshold; and a split path generation unit that generates, from the splitting candidate element list and the basic path list, a split path list that records portions of each of the program elements included in the splitting candidate element list that are not included in the basic path list.

A source code analysis method according to one aspect of the present disclosure is a method for analyzing source code corresponding to a program, executed by an apparatus having a processor and a storage device, which calculates source code metrics for each program element included in the source code to be analyzed from the source code, calculates a maintainability index for each of the program elements from the source code metrics, generates a splitting candidate element list recording program elements that are candidates for splitting based on the maintainability index and a maintainability index threshold, and generates a splitting candidate element list for each program element included in the splitting candidate element list from the source code, the program, and test cases for the program. a dynamic information list that records execution paths that are portions of the source code corresponding to the processing that is executed when the program is executed based on the above; a basic path list that records, from the dynamic information list and an overlap threshold, portions of the source code for each program element included in the splitting candidate element list where the proportion of test cases that include said portions in the execution paths shown in the dynamic information list is equal to or greater than the overlap threshold; and a split path list that records portions of each program element included in the splitting candidate element list that are not included in the basic path list from the splitting candidate element list and the basic path list.

A source code analysis program according to one aspect of the present disclosure is a source code analysis program that analyzes source code corresponding to a program, and is configured to: calculate source code metrics for each program element included in the program from the source code to be analyzed; calculate a maintainability index for each of the program elements from the source code metrics; generate a split candidate element list that records program elements that are candidates for splitting based on the maintainability index and a maintainability index threshold; and, based on the source code, the program, and test cases for the program, perform splitting for each of the program elements included in the split candidate element list based on the test cases. a dynamic information list that records execution paths that are portions of the source code corresponding to processes that are executed when the program is executed; a basic path list that records, from the dynamic information list and an overlap threshold, portions of the source code for each program element included in the splitting candidate element list, for which the proportion of test cases that include said portions in the execution paths shown in the dynamic information list is equal to or greater than the overlap threshold; and a split path list that records, from the splitting candidate element list and the basic path list, portions of each program element included in the splitting candidate element list that are not included in the basic path list.

According to one aspect of the present disclosure, it is possible to present areas for improvement where element splitting is required for program elements while meeting developer readability needs.

FIG. 1 is a conceptual diagram illustrating an example of a hardware configuration of a source code analyzing device. 1 is a conceptual diagram showing functions provided in a source code analyzing device and data stored in the source code analyzing device; FIG. 10 is a diagram illustrating an example of source code to be analyzed. FIG. 10 is a diagram illustrating an example of source code metrics. FIG. 10 is a diagram illustrating an example of a maintainability index. FIG. 10 is a diagram illustrating an example of a division candidate element list. FIG. 10 is a diagram illustrating an example of a dynamic information list. FIG. 10 is a diagram illustrating an example of a basic path list. FIG. 10 is a diagram illustrating an example of a divided path list. 10 is a flowchart illustrating an example of processing by a source code metrics calculation unit. 10 is a flowchart illustrating an example of processing by a maintainability index calculation unit. 10 is a flowchart illustrating an example of processing by a division candidate element generation unit. 10 is a flowchart illustrating an example of processing by a program processing tracing unit. 10 is a flowchart illustrating an example of processing by a basic path generation unit. 10 is a flowchart illustrating an example of processing by a divided path generating unit. FIG. 10 is a conceptual diagram illustrating functions provided in a source code analyzing device and data stored in the source code analyzing device according to a second embodiment. FIG. 10 is a diagram illustrating an example of a basic path maintainability index. FIG. 11 is a diagram illustrating an example of a divided path list according to the second embodiment. 10 is a flowchart illustrating an example of the operation of a basic path maintainability index calculation unit. 10 is a flowchart illustrating an example of the operation of a divided path generating unit. FIG. 11 is a conceptual diagram illustrating functions provided in a source code analyzing device and data stored in the source code analyzing device according to a third embodiment. 10 is a flowchart illustrating an example of the operation of a basic path generation unit. FIG. 10 is a conceptual diagram illustrating functions provided in a source code analyzing device and data stored in the source code analyzing device according to a fourth embodiment. 10 is a flowchart illustrating an example of the operation of a division portion mapping unit. FIG. 10 is a diagram illustrating an example of source code in which division locations are indicated. 1 is a conceptual diagram illustrating an example of screen transitions of a source code analyzing device. FIG. 10 is a conceptual diagram illustrating an example of an analysis target selection screen. FIG. 10 is a conceptual diagram illustrating an analysis result list screen. FIG. 10 is a conceptual diagram illustrating a division portion display screen.

The following describes embodiments of the present disclosure with reference to the drawings. Note that the embodiments described below do not limit the scope of the invention as claimed. Furthermore, not all of the elements and combinations thereof described in the embodiments are necessarily essential to the solution of the invention.

Figure 1 is a conceptual diagram showing an example of the hardware configuration of a source code analysis device.

The source code analysis device 100 is an information processing device used for the development and maintenance of software systems. The source code analysis device 100 may be realized virtually, such as a cloud server provided by a cloud system.

As shown in FIG. 1, the source code analysis device 100 includes a processor 101, a main memory device 102, an auxiliary memory device 103, an input device 104, an output device 105, and a communication device 106. These are connected to each other so that they can communicate with each other via communication means such as a bus (not shown).

The processor 101 is composed of, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), an FPGA (Field-Programmable Gate Array), etc. The processor 101 reads and executes various programs, such as a source code analysis program, stored in the main memory device 102 or the auxiliary memory device 103, thereby realizing various functions of the source code analysis device 100.

The main memory device 102 is a device that stores programs and data, and may be, for example, Random Access Memory (RAM), Read Only Memory (ROM), or non-volatile semiconductor memory (Non-Volatile RAM (NVRAM)).

The auxiliary storage device 103 is, for example, a reading and writing device for recording media such as a hard disc drive (HDD), solid state drive (SSD), storage system, integrated circuit (IC) card, secure digital (SD) memory card, or optical recording media (compact disc (CD), digital versatile disc (DVD), etc.), or a storage area of a cloud server.

The input device 104 is a device that accepts information input by the user. The input device 104 is, for example, a keyboard, a mouse, a touch panel, a card reader, or a voice input device.

The output device 105 is a device that provides various information such as processing progress and results to the user. Examples of the output device 105 include a screen display device (such as a Liquid Crystal Display (LCD) or a Head Mounted Display (HMD)), an audio output device, or a printing device.

Furthermore, the source code analysis device 100 may input and output information to and from other devices via the communication device 106.

The communication device 106 is a wired or wireless communication interface that enables communication with other devices via communication lines such as a local area network (LAN) or the Internet. The communication device 106 is, for example, a network interface card (NIC), a wireless communication module, a universal serial interface (USB) module, or a serial communication module.

Figure 2 is a conceptual diagram showing the functional configuration of a source code analysis device.

The source code analysis device 100 includes a source code metrics calculation unit 201, a maintainability index calculation unit 202, a division candidate element generation unit 203, a program processing tracking unit 204, a basic path generation unit 205, and a division path generation unit 206.

Each of these units is realized, for example, by the processor 101 reading and executing a program stored in the main memory device 102 or the auxiliary memory device 103. Furthermore, each of these units may also be realized, for example, by hardware (such as an Application Specific Integrated Circuit (ASIC)) included in the source code analysis device 100.

The source code analysis device 100 further includes an information storage unit 207. The information storage unit 207 stores information. The information storage unit 207 is composed of at least one of the main memory device 102 and the auxiliary memory device 103. The information storage unit 207 stores source code metrics 213. The information storage unit 207 also records information referenced or generated as appropriate by the source code metrics calculation unit 201, maintainability index calculation unit 202, division candidate element generation unit 203, program processing tracking unit 204, basic path generation unit 205, and division path generation unit 206. The information storage unit 207 may manage the information stored in at least one of the main memory device 102 and the auxiliary memory device 103 in the form of, for example, a file system or a database management system (DBMS).

The maintainability index threshold 211, the source code to be analyzed 208, the program to be analyzed 209, the test cases 210, and the duplication threshold 212 are input information to the source code analysis device 100. This input information may be stored in advance in the main memory device 102 or the auxiliary memory device 103. In addition, the source code analysis device 100 may acquire input data stored in an external device via the communication device 106.

(Source code analysis process)
The source code metrics calculation unit 201 acquires the analysis target source code 208 and calculates source code metrics 213. As described above, source code metrics are feature quantities of program elements obtained by program analysis of the source code.

The maintainability index calculation unit 202 acquires the source code metrics 213 and calculates the maintainability index 214. Specific examples of the maintainability index will be described later with reference to Figures 5 and 11, etc.

The division candidate element generation unit 203 obtains the maintainability index 214 and the maintainability index threshold 211, and generates a division candidate element list 215 for the program. The division candidate element list 215 will be described later with reference to Figures 6 and 12, etc.

The program processing tracking unit 204 acquires the analysis target source code 208, the analysis target program 209, and test cases 210 for the analysis target program 209, and generates a dynamic information list 216. The dynamic information list 216 will be described later with reference to Figures 7 and 13, etc.

The basic path generation unit 205 obtains the dynamic information list 216 and the overlap threshold 212 and generates the basic path list 217. The basic path list 217 will be described later with reference to Figures 8 and 14, etc.

The split path generation unit 206 obtains the split candidate element list 215 and the basic path list 217 and generates the split path list 218. Split path lists will be described later with reference to Figures 9 and 15, etc.

The source code analysis device 100 generates a list of program elements to be divided according to the maintainability index 214 and dynamic information list 216 based on the source code to be analyzed 208, the program to be analyzed 209, the test cases 210, the maintainability index threshold 211, and the overlap threshold 212.

The analysis target source code 208 is input information that records the source code to be analyzed by the source code analysis device 100.

Figure 3 shows an example of source code to be analyzed. The source code to be analyzed 208 is composed of a set 301 of source code segments for each program element of the program to be analyzed. Here, the unit of program element can be any unit of source code of a certain length, such as part of a function, a class, a module, or a structure. A source code segment refers to at least a portion of the source code corresponding to a program element. A source code segment may also be all of the source code corresponding to a program element. In the example of Figure 3, funcA and funcB are program elements. funcA is program element A, and funcB is program element B. Program element A includes the following segments: process A, process B, process C, process D, and process E. Program element B includes the following segments: process F, process G, process H, process I, and process J.

The analysis target program 209 is an executable program generated by building the analysis target source code 208. The source code analysis device 100 analyzes the analysis target source code 208 corresponding to the analysis target program 209.

Test cases 210 are information that records various test cases for the analysis target program 209.

The maintainability index threshold 211 refers to the threshold of the maintainability index 214 used by the division candidate element generation unit 203 when determining whether each program element is low in maintainability, i.e., whether each program element should be divided. For example, the maintainability index threshold 211 is set to 20. However, the value of the maintainability index threshold 211 may be other than 20.

The overlap threshold 212 is a recorded percentage threshold used by the basic path generation unit 205 when determining whether each element of source code included in the dynamic information list 216 appears frequently throughout the dynamic information list 216. For example, the overlap threshold 212 is set to 0.7 (70%). However, the value of the overlap threshold 212 may be a value other than 0.7.

Figure 4 is a diagram showing an example of source code metrics. The source code metrics 213 are recorded as a source code metrics record 400, with various metric values calculated by the source code metrics calculation unit 201 using the source code 208 to be analyzed as input. The source code metrics record 400 is composed of a program element name 401 that records the program element of the program that is the target of the source code metrics record calculation, and source code metrics 402 that records the metric values of the various source code metrics 213 for that program element name. Note that the metric value is not limited to one. Figure 4 shows an example in which the source code metrics record 400 includes at least two metric values, Metric 1 and Metric 2. The source code metrics 402 may be calculated using a calculation method known to those skilled in the art.

Figure 5 is a diagram showing an example of a maintainability index. The maintainability index 214 is a maintainability index calculated by the maintainability index calculation unit 202 using the source code metrics 213 as input, and recorded as a maintainability index record 500. The maintainability index record 500 is composed of a program element name 501 that records the program element for which the maintainability index record is calculated, and a maintainability index 502 that records the maintainability index 214 of that program element. A calculation method known to those skilled in the art may be used to calculate the maintainability index 502. For example, a calculation method may be used in which the larger the value of the maintainability index 502, the higher the maintainability of the program element.

Figure 6 is a diagram showing an example of a splitting candidate element list. The splitting candidate element list 215 uses the maintainability index 214 as input and records, as splitting candidate element records 600, program elements that the splitting candidate element generation unit 203 has determined to correspond to program elements that should be split. The splitting candidate element records 600 are composed of program element names 601 that correspond to program elements that should be split. In the example of Figure 6, program element A and program element B are splitting candidate elements.

The splitting candidate element list 215 corresponds to the analysis results obtained by the source code analysis device 100 statically analyzing the analysis target source code 208 using maintainability indicators based on source code metrics.

Next, we will explain the dynamic analysis of the source code to be analyzed.

Figure 7 shows an example of a dynamic information list. The dynamic information list 216 records the execution paths generated by the program processing tracking unit 204 as dynamic information records 700 using the analysis target source code 208, analysis target program 209, and test case 210 as input.

Dynamic information record 700 is composed of program element name 701, which is the name of the program element of the program that is the target of calculation of that dynamic information record; test case name 702, which is the name of the test case 210 used during program execution of analysis target program 209; and execution path 703, which records the execution path corresponding to that program element and that test case. In the example of Figure 7, in test case A-I, processes A, C, D, and E in program element A are executed. In test case A-II, processes A, C, and D in program element A are executed. In test case B-I, process G in program element B is executed. Execution paths will be described later with reference to Figure 13.

Figure 8 shows an example of a basic path list. The basic path list 217 records the basic paths generated by the basic path generation unit 20 as basic path records 800. The basic path record 800 is composed of a program element name 801 that records the program element of the program that is the target of calculation for the basic path record, and a basic path 802 that records the basic path of that program element. In the example of Figure 8, the basic path of program element A includes processes A, C, and D. Furthermore, the basic path of program element B includes process G.

Figure 9 is a diagram showing an example of a split path list. The split path list 218 records the split paths generated by the split path generation unit 206 as split path records 900. The split path record 900 is composed of a program element name 901 determined to be split, and a split path 902 that records the split path of that program element. In the example of Figure 9, the split path of program element A includes processes B and E that were not included in the basic path shown in Figure 8. Furthermore, the split path of program element B includes processes F, H, and I that were not included in the basic path shown in Figure 8.

(Processing contents of each processing block)
FIG. 10 is a flowchart illustrating an example of processing by the source code metrics calculation unit.

The source code metrics calculation unit 201 reads the source code 208 to be analyzed (1001).

The source code metrics calculation unit 201 executes the processing of step 1003 for each program element E contained in the acquired analysis target source code 208 (steps 1002-1004).

In step 1003, the source code metrics calculation unit 201 calculates the source code metrics 213.

The source code metrics calculation unit 201 calculates source code metrics such as those used by the maintainability index calculation unit 202. Examples of source code metrics that are calculated include the Halsted Volume in the Maintainability Index (MI), cyclomatic complexity, and the number of lines of source code excluding comment lines.

Figure 11 is a flowchart showing an example of the processing performed by the maintainability index calculation unit.

The maintainability index calculation unit 202 executes steps 1102 and 1103 for each program element E (steps 1101-1104).

The maintainability index calculation unit 202 reads the source code metrics 213 (1102). The maintainability index calculation unit 202 uses the read source code metrics 213 to calculate the maintainability index 214 (1103).

A maintainability index is a metric that indicates the ease of software maintenance. An example of a maintainability index is the Maintainability Index (MI) shown in the following equation (1):

Maintainability index=max(0, (171 - 5.2*ln(HV) - 0.23*C - 16.2*ln(L))*100/171) …(1)

Here, HV stands for Halsted Volume. C stands for Cyclomatic Complexity. L stands for the number of lines of source code excluding comment lines. ln stands for the natural logarithm.

The maintainability index 214 is not limited to the maintainability index described above, but may be any index related to the maintainability of the program.

Figure 12 is a flowchart showing an example of the processing performed by the division candidate element generation unit.

The division candidate element generation unit 203 reads the maintainability index threshold 211 (1201). The read maintainability index threshold is denoted as A.

The division candidate element generation unit 203 executes steps 1203-1205 for each program element E (steps 1202-1206).

The division candidate element generation unit 203 reads the maintainability index 214 (1203). The read maintainability index is denoted as H.

The division candidate element generation unit 203 determines whether the maintainability index H is less than the maintainability index threshold A (1204). If the maintainability index H is less than the maintainability index threshold A (step 1204: YES), processing proceeds to step 1205. If the maintainability index H is not less than the maintainability index threshold A (step 1204: NO), step 1205 is skipped.

In step 1205, the division candidate element generation unit 203 adds the program element to the division candidate element list 215.

The above shows an example of processing when a maintainability index is used in which the larger the value, the higher the maintainability of the program element. If a maintainability index is used in which the smaller the value, the higher the maintainability of the program element, then in step 1204, if the maintainability index 214 is greater than the maintainability index threshold 211, processing transitions to step 1205.

Figure 13 is a flowchart showing an example of processing by the program processing tracking unit.

The program processing tracing unit 204 reads the analysis target source code 208 (1301). The program processing tracing unit 204 reads the analysis target program 209 (1302). The program processing tracing unit 204 reads the test case 210 corresponding to the analysis target program 209 (1303).

The program processing tracking unit 204 executes steps 1305-1308 for each program element E included in the analysis target program 209 (steps 1304-1309). Here, an example is shown in which steps 1305-1308 are executed for all program elements E included in the analysis target program 209, but as another example, steps 1305-1308 may be executed for all program elements E included in the splitting candidate element list 215.

The program processing tracking unit 204 executes steps 1306-1307 for each test case T included in the test case 210 (steps 1305-1308).

The program processing tracing unit 204 executes the analysis target program 209 based on test case T (1306).

The program processing tracking unit 204 extracts from the source code 208 a set of source code portions corresponding to the executed processing for the program element E (1307). The set of source code portions executed for the test case is referred to as an execution path. This execution path will be included in the dynamic information record 700 of the dynamic information list 216 described with reference to Figure 7.

The order in which the analysis target source code 208 (step 1301), the analysis target program 209 (step 1302), and the test case 210 (step 1303) are read does not matter.

Figure 14 is a flowchart showing an example of processing by the basic path generation unit.

The basic path generation unit 205 reads the overlap threshold 212 (1401). The read overlap threshold is denoted as B.

The basic path generation unit 205 executes steps 1403-1409 for each program element E (1402-1410).

The basic path generation unit 205 reads the dynamic information list 216 (1403).

The basic path generation unit 205 executes steps 1405-1407 for each portion S of source code included in program element E (1404-1408). Note that a portion S of source code included in program element E is referred to as a source code fragment.

For the source code fragment S in the program element E, the basic path generation unit 205 calculates the percentage R of test cases whose execution paths indicated in the dynamic information list include the source code fragment S (1405).

The basic path generation unit 205 determines whether the ratio R is greater than or equal to the overlap threshold B (1406). If the ratio R is greater than or equal to the overlap threshold B (step 1406: YES), processing proceeds to step 1407. If the ratio R is not greater than or equal to the overlap threshold B (step 1406: NO), step 1407 is skipped.

In step 1407, the basic path generation unit 205 adds the source code fragment S to the basic path (1407). Note that the set of source code fragments S formed by performing the processing of step 1407 on one program element is referred to as a basic path.

In step 1409, the basic path generation unit 205 adds the basic path to the basic path list 217.

Here, we will explain the loop processing of steps 1404-1408 in more detail.

Referring to Figures 2 and 7, the dynamic information list 216 contains a set of parts of the source code 208 executed by the program processing tracing unit 204 for the test case 210. This corresponds to the execution path in Figure 7. The basic path generation unit 205 adds to the basic path parts of the source code 208 whose proportion in the set of parts of the source code 208 executed by the program processing tracing unit 204 for the test case 210 is equal to or greater than the overlap threshold 212 (steps 1405-1407), thereby generating a basic path list 217 from the dynamic information list 216 and the overlap threshold 212.

As mentioned above, in order to maintain the readability of source code for developers in the development field, it is assumed that there is a developer readability need to avoid splitting typical processing within a certain program element into other elements. If a source code fragment whose inclusion rate in the execution path is equal to or exceeds the overlap threshold is added to the base path, the typical processing with high execution frequency becomes the base path and is not subject to splitting (step 1505, described below with reference to Figure 15). This has the advantage that typical processing with high execution frequency that developers would want to read as a single piece of source code will not be split against the developer's intention.

Figure 15 is a flowchart showing an example of processing by the split path generation unit.

The division path generation unit 206 reads the division candidate element list 215 (1501).

The split path generation unit 206 executes steps 1503-1507 for each program element E (1502-1508).

The split path generation unit 206 determines whether program element E is included in the split candidate element list 215 (1503). If program element E is included in the split candidate element list 215 (step 1503: YES), processing proceeds to step 1504. If program element E is not included in the split candidate element list 215 (step 1503: NO), steps 1504-1507 are skipped.

In step 1504, the split path generation unit 206 reads the basic path list 217.

The split path generation unit 206 extracts source code portions (source code fragments) from program element E that are not included in the basic path list 217 (1505). Note that the set of source code fragments that are not basic paths extracted by executing step 1505 for one program element is referred to as a split path.

The split path generation unit 206 determines whether the split path is empty (1506). If the split path is not empty (step 1506: YES), processing proceeds to step 1507. If the split path is empty (step 1506: NO), step 1507 is skipped.

The split path generation unit 206 adds the split path to the split path list (1507).

As described above, program elements to be divided can be found and listed using the maintainability index 214 obtained by statically analyzing the source code to be analyzed and the dynamic information list 216 containing the execution paths obtained by running the program to be analyzed corresponding to the source code to be analyzed based on test cases.

This embodiment shows a case in which the basic path generation unit 205 shown in embodiment 1 calculates the maintainability index of the basic path remaining after splitting a program element, and in addition to the program element name and split path corresponding to the split path, the pre-split maintainability index of the program element and the basic path maintainability index of the program element are also recorded in the split path record in the split path list.

In addition to the case of Example 1, the information storage unit 207 stores the base path maintainability index 1602 in at least one of the main memory device 102 and the auxiliary memory device 103. In addition to the case of Example 1, the information storage unit 207 also stores information other than the above information that is referenced or generated as appropriate by the base path maintainability index calculation unit 1601. The information storage unit 207 manages the information stored in at least one of the main memory device 102 and the auxiliary memory device 103 in the same way as in Example 1.

Figure 16 is a conceptual diagram showing the functions provided by the source code analysis device and the data stored by the source code analysis device in Example 2.

In addition to the configuration of Example 1, the source code analysis device 100 further includes a basic path maintainability index calculation unit 1601. The basic path maintainability index calculation unit 1601 calculates a basic path maintainability index 1602 from the basic path list 217. Furthermore, the split path generation unit 206 acquires the maintainability index 214 and the basic path maintainability index 1602 in addition to the split candidate element list 215 and the basic path list 217.

Figure 17 is a diagram showing an example of a basic path maintainability index. The basic path maintainability index 1602 is a metric value calculated by the basic path maintainability index calculation unit 1601 using the basic path list 217 as input, and recorded as a basic path maintainability index record 1700. The basic path maintainability index record 1700 is composed of a program element name 1701 that records the program element of the program that is the subject of the calculation of the basic path maintainability index record, and a basic path maintainability index 1702 that records the maintainability index of the basic path of that program element.

Figure 18 is a diagram showing an example of a split path list in Example 2. The split path list 218 in Example 2 records the split paths generated by the split path generation unit 206 as split path records 1800. The split path record 1800 is composed of the element name of a program element 1801 determined to be split, a split path 1802 recording the split path of the program element, a pre-split maintainability index 1803 recording the maintainability index of the program element, and a post-split maintainability index 1804 recording the maintainability index of the basic path of the program element. In addition to the list of program elements 1801 to be split, the source code analysis device 100 generates a list of the pre-split maintainability index 1803 and the post-split maintainability index 1804.

Figure 19 is a flowchart showing an example of the operation of the basic path maintainability index calculation unit.

The basic path maintainability index calculation unit 1601 reads the basic path list 217 (1901).

The basic path maintainability index calculation unit 1601 executes steps 1903-1904 for each program element E (1902-1905).

The basic path maintainability index calculation unit 1601 calculates the source code metrics of the basic path in program element E (1903). The source code metrics may be calculated using the same method as that used by the source code metrics calculation unit 201.

The basic path maintainability index calculation unit 1601 calculates the maintainability index of the basic path based on the source code metrics of the basic path (1904). The maintainability index calculation method may be the same as that used by the maintainability index calculation unit 202.

Figure 20 is a flowchart showing an example of the operation of the split path generation unit.

The flowchart shown in Figure 20 is basically the same as the flowchart shown in Figure 15, so detailed explanations of similar processes will be omitted.

The flowchart shown in Figure 20 adds steps 2001 and 2002 to the flowchart shown in Figure 15.

Furthermore, step 1507 in the flowchart shown in Figure 15 has been changed to step 2003 in the flowchart shown in Figure 20.

In step 2001, the split path generation unit 206 reads the maintainability index 214. In step 2002, the split path generation unit 206 reads the base path maintainability index 1602. In step 2003, the split path generation unit 206 adds the split path, the maintainability index 214, and the base path maintainability index 1602 to the split path list.

In this way, by presenting the split path along with the maintainability indicators before and after element splitting, it is possible to show how the element splitting proposed in this embodiment improves the maintainability of the source code being analyzed.

This embodiment shows a case in which the basic path generation unit 205 shown in Embodiments 1 and 2 uses a maintainability index target value as an input in addition to the input shown in Embodiment 1, and the threshold setter changes the overlap threshold to change the generated basic path.

Figure 21 is a conceptual diagram showing the functions provided by the source code analysis device and the data stored by the source code analysis device in Example 3.

In addition to the cases of Examples 1 and 2, the source code analysis device 100 inputs the maintainability index target value 2101. Furthermore, the basic path generation unit 205 inputs the maintainability index target value 2101 in addition to the dynamic information list 216 and overlap threshold 212.

The maintainability index target value 2101 is a record of the target value of the maintainability index 214 used by the basic path generation unit 205 when the threshold setter determines whether the basic path of each program element is appropriate. For example, 40 is set as the maintainability index target value 2101. However, a value other than 40 may also be used.

Figure 22 is a flowchart showing an example of the operation of the basic path generation unit. In the flowchart shown in Figure 22, detailed explanations of processes that are the same as those in the flowchart shown in Figure 14 will be omitted.

In Example 3, steps 2201, 2203, 2204, 2205, 2206, and 2207 are added. Note that steps 2202 and 2208 represent the loop processing from steps 1403 to 2207. Step 2209 is the same processing as step 1409 in the flowchart shown in Figure 14, so a detailed explanation will be omitted.

In step 2201, the basic path generation unit 205 reads the maintainability index target value 2101. The read maintainability index target value is denoted as M.

In step 2203, the basic path generation unit 205 calculates source code metrics for the basic path.

In step 2204, the basic path generation unit 205 calculates the maintainability index of the basic path. If the basic path maintainability index calculation unit 1601 is provided, the basic path maintainability index calculation unit 1601 may calculate the maintainability index of the basic path as described based on Example 2. If the basic path maintainability index calculation unit 1601 is not provided, the basic path generation unit 205 may calculate the maintainability index of the basic path in a similar manner. The calculated basic path maintainability index is denoted as K.

In step 2205, the basic path generation unit 205 determines whether the maintainability index K of the basic path is less than the maintainability index target value M. If the maintainability index K of the basic path is less than the maintainability index target value M (step 2205: YES), processing transitions to step 2206. If the maintainability index K of the basic path is not less than the maintainability index target value M (step 2205: NO), processing transitions to step 2209.

Step 2206 is a human judgment. A user, such as a threshold setter, determines whether the generated basic path is appropriate. If the user judges that the generated basic path is appropriate (step 2206: YES), the loop of steps 2202-2208 is exited and processing transitions to step 2209. If the user judges that the generated basic path is inappropriate (step 2206: NO), processing transitions to step 2207.

In step 2207, the user changes the overlap threshold B. Processing then returns to step 1403, where the basic path list is regenerated based on the new overlap threshold B (2202, 2208). Here, by increasing the value of the overlap threshold B, it is advisable to narrow down the basic paths and increase the basic path maintainability index K.

In step 2209, the basic path generation unit 205 adds the basic path to the basic path list 217 and completes the generation of the basic path for the program element (step 2208).

As described above, in Example 3, when generating a basic path, it is determined whether the maintainability index of the basic path is less than the maintainability index target value 2101. In addition, the basic path list is regenerated based on the overlap threshold whose value has been changed. This allows the user to flexibly determine whether the generated basic path meets the developer's readability needs, while also presenting locations where program elements should be split to improve source code maintainability.

In Example 4, after generating the split path list shown in Example 2 or Example 3, source code is generated that further indicates the split locations.

Figure 23 is a conceptual diagram showing the functions provided by the source code analysis device and the data stored by the source code analysis device in Example 4.

The source code analysis device 100 according to the fourth embodiment further includes a division location mapping unit 2301 in addition to the components of the second or third embodiment.

The division point mapping unit 2301 acquires the analysis target source code 208 and the division path list 218, and generates source code 2302 in which the division points are shown in a manner that makes them distinguishable from other parts.

Figure 24 is a flowchart showing an example of the operation of the division point mapping unit.

The division location mapping unit 2301 reads the analysis target source code 208 (2401). The division location mapping unit 2301 reads the division path list 218 (2402). Note that the order of steps 2401 and 2402 does not matter.

The division point mapping unit 2301 executes steps 2404-2406 for each program element E (steps 2403-2407).

The division location mapping unit 2301 determines whether program element E is included in the division path (2404). If program element E is included in the division path (step 2404: YES), processing transitions to step 2405. If program element E is not included in the division path (step 2404: NO), processing transitions to step 2406.

In step 2405, the division point mapping unit 2301 maps the division paths to the source code to be analyzed, generating source code 2302 in which the division points are indicated. There are no particular limitations on how the division points are indicated.

In step 2406, the division portion mapping unit 2301 extracts the unmapped portions of the source code to be analyzed as the post-division source code (2406).

As described above, the source code analysis device 100 indicates the split locations of the source code after generating the split path list. This can assist the person modifying the source code in their source code modification work.

Example 5 shows the division points in the source code shown in Example 4, specifically in units of program lines or tokens.

Figure 25 shows an example of source code showing the division points.

Source code 2500 showing the division points is composed of source code 2501 of the program element, one or more division target points 2502 in source code 2501 of the program element, source code 2503 of the program element after division, maintainability index 2504 of the program element, and maintainability index 2505 of the source code of the program element after division.

As described above, by indicating the division locations in units of program lines or tokens, the source code analysis device 100 can clearly indicate the changes in the source code before and after division in units of lines or tokens. This makes it easier for users, such as those who modify the source code, to understand the results of the element division.

Example 6 shows an example of a screen display by the source code analysis device in Example 5.

Figure 26 is a conceptual diagram illustrating screen transitions in the source code analysis device. The screen is displayed on the output device 105 of the source code analysis device 100. However, the screen may also be displayed on a display device communicatively connected to the source code analysis device 100. For example, the screen may be displayed on a display device provided in a client terminal communicatively connected to the source code analysis device 100. The following describes an example in which the screen is displayed on the output device 105.

The screen configuration of the source code analysis device 100 consists of an analysis target selection screen 2601, an analysis result list screen 2602, and a division location display screen 2603. It is possible to transition between the analysis target selection screen 2601 and the analysis result list screen 2602 in both directions. It is possible to transition between the analysis result list screen 2602 and the division location display screen 2603 in both directions. It is possible to transition from the division location display screen 2603 to the analysis target selection screen 2601.

Figure 27 is a conceptual diagram illustrating an example of the analysis target selection screen. The analysis target selection screen 2601 has an analysis target selection tab 2701 and a start analysis button 2702.

The analysis target selection tab 2701 has an analysis target source code selection section 2703 for selecting the analysis target source code 208, an analysis target program selection section 2704 for selecting the analysis target program 209, a test case selection section 2705 for selecting the test case 210, a maintainability index threshold selection section 2706 for selecting the maintainability index threshold 211, and an overlap threshold selection section 2707 for selecting the overlap threshold 212.

The user of the source code analysis device 100 selects each piece of data using the analysis target source code selection unit 2703, the analysis target program selection unit 2704, the test case selection unit 2705, the maintainability index threshold selection unit 2706, and the overlap threshold selection unit 2707, and presses the analysis start button 2702 to begin the analysis.

When the user presses the analysis start button 2702, the source code metrics calculation unit 201, maintainability index calculation unit 202, division candidate element generation unit 203, program processing tracking unit 204, basic path generation unit 205, if provided, basic path maintainability index calculation unit 1601, division path generation unit 206, and if provided, division point mapping unit 2301 within the source code analysis device 100 each perform the processing described above. The screen then transitions to the analysis result list screen 2602.

Figure 28 is a conceptual diagram illustrating an example of the analysis result list screen. The analysis result list screen 2602 has an analysis result list tab 2801 and a button 2802 for returning to analysis target selection.

The analysis result list tab 2801 has a split path list display section 2803. The split path list display section 2803 displays the contents of the split path list 218. In this example, the names of the program elements to be split in the split path record 1800, the values of the pre-split maintainability index, and the values of the post-split maintainability index are displayed in the split path list display section 2803.

When the user of the source code analysis device 100 presses the name of a program element that has been determined to be split in each split path record 1800 in the split path list display section 2803, the split point mapping section 2301 performs the above-mentioned processing. The screen then transitions to the split point display screen 2603.

When the user presses the "Return to analysis target selection" button 2802, the screen transitions to the analysis target selection screen 2601.

Figure 29 is a conceptual diagram illustrating the division point display screen. The division point display screen 2603 has a division point display tab 2901, a button 2902 for returning to analysis target selection, and a button 2903 for returning to the analysis results list.

The division location display tab 2901 has a source code display section 2904. The source code display section 2904 displays source code 2500 in which the division locations are distinguishable from other parts. The source code display section 2904 displays the maintainability indexes before and after the program division, along with source code 2500 in which the division locations are distinguishable from other parts. By viewing the division location display screen 2603, a user of the source code analysis device 100 can learn the division locations of the source code and the maintainability indexes before and after the division.

When the user presses the Return to Analysis Target Selection button 2902, the screen transitions to the analysis target selection screen 2601. When the user presses the Return to Analysis Results List button 2903, the screen transitions to the analysis results list screen 2602.

The above-described embodiments of the present invention are illustrative examples of the present invention and are not intended to limit the scope of the present invention to these embodiments alone. Those skilled in the art may implement the present invention in various other forms without departing from the scope of the present invention.

As described above, the source code analysis device 100, which analyzes source code 208 corresponding to program 209, includes a source code metrics calculation unit 201 that calculates source code metrics 213 from the source code 208 to be analyzed. The source code analysis device 100 includes a maintainability index calculation unit 202 that calculates a maintainability index 214 from the source code metrics 213. The source code analysis device 100 includes a division candidate element generation unit 203 that generates a division candidate element list 215 for the program based on the maintainability index 214 and a maintainability index threshold 211. The source code analysis device 100 includes a program processing tracking unit 204 that generates a dynamic information list 216 from the source code 208, program 209, and test cases 210 for program 209. The source code analysis device 100 includes a basic path generation unit 205 that generates a basic path list 217 from the dynamic information list 216 and overlap threshold 212. The source code analysis device 100 includes a split path generation unit 206 that generates a split path list 218 from a split candidate element list 215 and a basic path list 217. The source code analysis device 100 generates a list of program elements to be split according to a maintainability index 214 and a dynamic information list 216 based on source code 208, a program 209, test cases 210, a maintainability index threshold 211, and an overlap threshold 212. This makes it possible to present areas for element splitting as areas for improvement for program elements to be split while meeting the developer's readability needs. As a result, typical frequently executed processes that a developer would want to read together as a single source code are not split against the developer's intention.

The source code analysis device 100 further includes a basic path maintainability index calculation unit 1601 that generates a basic path maintainability index 1602 from the basic path list 217, and generates a list of program elements 1801 to be divided, as well as a list of maintainability indexes before element division 1803 and maintainability indexes after element division 1804. This makes it possible to present the effect of how much the maintainability of the source code being analyzed will be improved by element division.

The basic path generation unit 205 determines whether the maintainability index of the basic path is less than the maintainability index target value, and regenerates the basic path list based on the modified overlap threshold value. This allows the user to flexibly determine whether the generated basic path meets the developer's readability needs, while also presenting locations where program elements should be split to improve source code maintainability.

The source code analysis device 100 further includes a division location mapping unit 2301 that generates source code 2302 indicating the division locations from the source code 208 and the division path list 218. This makes it possible to support the source code modification work by the person modifying the source code.

The division location mapping unit 2301 generates source code 2302 in which the division locations are indicated in units of program lines or tokens. By indicating the division locations in units of program lines or tokens, the source code analysis device 100 can clearly show the changes in the source code before and after division in units of lines or tokens. This makes it possible to present the division locations to users, such as those modifying the source code, in a way that makes it easy to understand the results of the element division.

The source code analysis device 100 displays the source code 2500 showing the division locations. This allows the user to know the division locations of the source code.

The source code analysis device 100 displays the maintainability indexes before and after program division along with the source code 2500 showing the division locations. This allows the user to know the division locations of the source code and the maintainability indexes before and after division.

1...processing device, 100...source code analysis device, 101...processor, 102...main storage device, 103...auxiliary storage device, 104...input device, 105...output device, 106...communication device, 201...source code metrics calculation unit, 202...maintainability index calculation unit, 203...division candidate element generation unit, 204...program processing tracking unit, 205...basic path generation unit, 206...division path generation unit, 207...information storage unit, 208...analysis target source code, 209...analysis target program, 210...test case, 211...maintainability index threshold, 212...overlap threshold, 213...source code metrics, 214...maintainability index, 215...division candidate element list, 216...dynamic information list, 217...basic Main path list, 218... split path list, 1601... basic path maintainability index calculation section, 1602... basic path maintainability index, 2301... split location mapping section, 2601... analysis target selection screen, 2602... analysis result list screen, 2603... split location display screen, 2701... analysis target selection tab, 2702... analysis start button, 2703... analysis target source code selection section, 2704... analysis target program selection section, 2705... test case selection section, 2706... maintainability index threshold selection section, 2707... overlap threshold selection section, 2801... analysis result list tab, 2802, 2902, 2903... buttons, 2803... split path list display section, 2901... split location display tab, 2904... source code display section

Claims (9)

A source code analysis device that analyzes source code corresponding to a program,
a source code metrics calculation unit that calculates source code metrics of each program element included in the program from the source code to be analyzed;
a maintainability index calculation unit that calculates a maintainability index for each of the program elements from the source code metrics;
a division candidate element generating unit that generates a division candidate element list that records program elements that are candidates for division based on the maintainability index and a maintainability index threshold;
a program processing tracing unit that generates, for each program element included in the division candidate element list, a dynamic information list that records an execution path that is a portion of the source code corresponding to a process that is executed when the program is executed based on the test case, from the source code, the program, and a test case for the program; and
a basic path generation unit that generates, from the dynamic information list and an overlap threshold, a basic path list that records portions of the source code in each of the program elements included in the splitting candidate element list, where the proportion of test cases that include the portions in the execution paths shown in the dynamic information list is equal to or greater than the overlap threshold;
a division path generating unit that generates a division path list from the division candidate element list and the basic path list, the division path list recording parts of each of the program elements included in the division candidate element list that are not included in the basic path list,
Source code analyzer. a basic path maintainability index calculation unit that generates, from the basic path list, a basic path maintainability index that is a maintainability index for a basic path of a program element included in the division candidate element list,
The source code analysis device according to claim 1 . the basic path generation unit increases the overlap threshold and regenerates the basic path list if the basic path maintainability index is less than a maintainability index target value;
The source code analysis device according to claim 2 . a division point mapping unit that generates, from the source code and the division path list, source code in which parts included in the division path list are shown so as to be distinguishable from other parts,
The source code analysis device according to claim 1 . the division portion mapping unit generates source code in which the portions included in the division path list are indicated in units of program lines or tokens.
The source code analysis device according to claim 4. displaying the source code in which the parts included in the split path list are distinguishable from other parts;
6. The source code analysis device according to claim 4 or 5. displaying maintainability indicators before and after dividing the program together with source code in which the parts included in the divided path list are shown so as to be distinguishable from other parts;
The source code analysis device according to claim 6. A method for analyzing source code corresponding to a program, executed by a device having a processor and a storage device, comprising:
Calculating source code metrics for each program element included in the program from the source code to be analyzed;
calculating a maintainability index for each of the program elements from the source code metrics;
generating a division candidate element list that records program elements that are candidates for division based on the maintainability index and a maintainability index threshold;
generating a dynamic information list for each program element included in the division candidate element list from the source code, the program, and test cases for the program, the dynamic information list recording an execution path that is a portion of the source code corresponding to a process that is executed when the program is executed based on the test cases;
From the dynamic information list and the overlap threshold, generate a basic path list that records, among the portions of the source code in each of the program elements included in the splitting candidate element list, portions of the test cases in which the proportion of test cases that include the portions in the execution paths shown in the dynamic information list is equal to or greater than the overlap threshold;
A source code analysis method for generating a split path list from the split candidate element list and the basic path list, the split path list recording parts of each program element included in the split candidate element list that are not included in the basic path list. A source code analysis program that analyzes source code corresponding to a program,
An apparatus having a processor and a storage device,
Calculating source code metrics for each program element included in the program from the source code to be analyzed;
calculating a maintainability index for each of the program elements from the source code metrics;
generating a division candidate element list that records program elements that are candidates for division based on the maintainability index and a maintainability index threshold;
generating a dynamic information list for each program element included in the division candidate element list from the source code, the program, and test cases for the program, the dynamic information list recording an execution path that is a portion of the source code corresponding to a process that is executed when the program is executed based on the test cases;
From the dynamic information list and the overlap threshold, generate a basic path list that records, among the portions of the source code in each of the program elements included in the splitting candidate element list, portions of the test cases in which the proportion of test cases that include the portions in the execution paths shown in the dynamic information list is equal to or greater than the overlap threshold;
A source code analysis program for executing the following: generating a split path list from the split candidate element list and the basic path list, the split path list recording the parts of each program element included in the split candidate element list that are not included in the basic path list.