JP7029915B2 - Source code analyzer and source code analysis method - Google Patents

Description

The present invention relates to a source code analysis device and a source code analysis method, and more particularly to a source code analysis device and a source code analysis method suitable for analyzing the presence or absence of factors that reduce maintainability in source code in software development.

In recent software development, derivative development that develops new software by extending or modifying the developed parent software is the mainstream. In the development of derivative software, the readability of the source code tends to decrease due to the complexity of the software due to repeated enhancements or changes over many years. Software refactoring is commonly used to solve this situation. Refactoring is to improve the internal structure of software without changing its behavior. Appropriate refactoring of program components (hereinafter referred to as "program elements") such as functions, classes, and files that are not maintainable makes it easier for software to extend or change.

An important concept in refactoring is "anti-patterns". An anti-pattern is a collection of features of a program element with low maintainability (hereinafter referred to as "problem feature") and a pattern of refactoring method of the program element having the problem feature. In the software to be refactored, if a program element having a problem characteristic as shown by the anti-pattern can be identified, it can be refactored by applying the anti-pattern.

For example, Patent Document 1 describes a method of measuring metrics from a source code, a configuration management system, or an operation log and evaluating whether or not an anti-pattern of the source code is applicable. This makes it possible to identify source code that truly needs refactoring without extracting complex source code that does not require refactoring.

Japanese Unexamined Patent Publication No. 2016-143107

In the method described in Patent Document 1, whether or not the program element has problematic features by using the feature amount of the program element obtained by program analysis of the source code (hereinafter referred to as "software metric"). Is determined. However, among the problem features shown by anti-patterns, it is difficult to determine whether or not a program element has the problem features only by using software metrics. Here, two such anti-patterns, Shotgun surgery and The Blob, will be described as an example.

Shotgun surgery is a pattern for refactoring a program element that has the problem feature that when the program element is extended or changed, many other program elements are also extended or changed at the same time. Since the problem characteristics shown by Shotgun surgery are not the characteristics of the program element itself but the characteristics related to the change of the program element, it is difficult to identify the program element having the problem characteristic by using software metrics.

The Blob is a pattern for refactoring program elements that have the problematic feature that multiple functions are implemented together in one place. Since the program elements with the problematic characteristics shown by The Blob tend to be large or complicated, the software metric of the scale or complexity of the program elements is effective for identifying them. However, since the scale and complexity of a program element in which a single function is implemented may increase, noise tends to appear in the judgment result, and the judgment result tends to lack reliability. On the other hand, a program element with the problematic characteristics indicated by The Blob is often expanded or changed at the same time when multiple functions implemented by the program element are expanded or changed, and it is not possible to deal with The Blob. Often it is a particularly important issue.

How to manage changes in program elements is especially important for proper refactoring. However, in the technique described in Patent Document 1, software metrics are taken into consideration in order to determine whether or not the program element has the problematic feature indicated by the anti-pattern. Is not considered.

An object of the present invention is to provide a source code analysis device that determines whether or not a program element has a problem feature by using a change history of the program element and displays an analysis result.

The configuration of the source code analysis device of the present invention is preferably a source code analysis device that points out a problem regarding the maintainability of the source code of the program to be analyzed, and is related to the change history of the program to be analyzed and the change of the program. The logical coupling analysis unit that inputs the threshold value of the index and outputs the change dependency rule of the program element, and the program element after the change from the node of the program element before the change and the node of the program element before the change based on the change dependency rule. As the directed side toward the node of the element, the logical coupling generator that generates the logical coupling graph expressing the change dependency of the program element, the generated logical coupling graph, and the generated logical coupling graph are defined for each program element. An anti-pattern detector that detects a program element with low maintainability in a logical coupling graph based on information about graph parameters and makes it an anti-pattern graph that emphasizes the nodes of the program element with low maintainability, and an anti-pattern graph. It consists of an anti-pattern display unit to be displayed.

According to the present invention, it is possible to provide a source code analysis device that determines whether or not a program element has a problem feature by using a change history of the program element and displays an analysis result.

It is a block diagram which shows the functional structure of the source code analysis apparatus of Embodiment 1. FIG. It is a block diagram which shows the hardware software structure of the source code analysis apparatus of Embodiment 1. FIG. It is a figure which shows an example of the program element change history. It is a figure which shows an example of the basket analysis threshold table. It is a figure which shows an example of the change dependency rule table. It is a figure which shows an example of a logical coupling graph. It is a figure which shows an example of the graph pattern matching logic. It is a figure which shows an example of the program element information of Embodiment 1. FIG. It is a figure which shows an example of a graph parameter threshold value. It is a figure which shows an example of the parameter logical expression of Embodiment 1. FIG. It is a figure which shows an example of the anti-pattern graph of Embodiment 1. FIG. It is a figure which shows an example of the anti-pattern graph of The Blob. It is a figure which shows an example of the anti-pattern graph of Shotgun surgery. It is a flowchart which shows the process of a logical coupling analysis part. It is a flowchart which shows the process of the logical coupling graph generation part of Embodiment 1. It is a flowchart which shows the logical coupling graph generation process of S1303 of FIG. It is a flowchart which shows the generation process of the program element information of S1304 of FIG. It is a flowchart explaining the process of the anti-pattern detection part. It is a block diagram which shows the functional structure of the source code analysis apparatus of Embodiment 2. It is a block diagram which shows the hardware software configuration of the source code analysis apparatus of Embodiment 2. It is a figure which shows an example of the software metric acquisition logic. It is a figure which shows an example of software metric information. It is a figure which shows an example of the program element information of Embodiment 2. It is a figure which shows an example of a software metrics threshold table. It is a figure which shows an example of the parameter logical expression of Embodiment 2. It is a figure which shows an example of the anti-pattern graph of Embodiment 2. It is a flowchart explaining the process of a program analysis part. It is a flowchart explaining the process of the logical coupling graph generation part of Embodiment 2. It is a flowchart which shows the generation process of the program element information of S1304 of FIG. It is a block diagram which shows the functional structure of the source code analysis apparatus of Embodiment 3. It is a block diagram which shows the hardware software configuration of the source code analysis apparatus of Embodiment 3. It is a figure which shows the system parameter update screen.

Hereinafter, each embodiment of the present invention will be described with reference to FIGS. 1 to 32.

[Embodiment 1]
Hereinafter, Embodiment 1 of the present invention will be described with reference to FIGS. 1 to 18.
First, the configuration of the source code analysis apparatus of the first embodiment will be described with reference to FIGS. 1 and 2.

As shown in FIG. 1, the source code analysis device 10 includes a logical coupling analysis unit 101, a logical coupling graph generation unit 103, an anti-pattern detection unit 104, an information storage unit 105, and an anti-pattern display unit 119. It has a functional part.

These functions are realized, for example, by the processor 11 reading and executing a program stored in the main storage device 12 and the auxiliary storage device 13. Further, these functions are realized by, for example, hardware (ASIC (Application Specific Integrated Circuit) or the like) included in the source code analysis device 10.

The information storage unit 105 stores the change dependency rule table 114, the logical coupling graph 116, and the program element information 117 in the auxiliary storage device 13. In addition to these information, the information storage unit 105 stores information such as information that is appropriately referred to or generated by the logical coupling analysis unit 101, the logical coupling graph generation unit 103, and the anti-pattern detection unit 104. The information storage unit 105 manages the information stored in the auxiliary storage device 13 by, for example, a file system or a DBMS (DataBase Management System). Specific examples of these data will be described in detail later.

The logical coupling analysis unit 101 is a functional unit that receives the program element change history 106 of the source code to be analyzed and the basket analysis threshold table 107 and generates the change dependency rule table 114 in the source code analysis.

The logical coupling graph generation unit 103 is a functional unit that receives the change dependency rule table 114 and the graph pattern matching logic and generates the logical coupling graph 116 and the program element information 117.

The anti-pattern detection unit 104 is a functional unit that receives the logical coupling graph 116 and the program element information 117 and generates the anti-pattern graph 118.

The anti-pattern display unit 119 is a functional unit that displays the anti-pattern graph 118.

Next, the hardware / software configuration of the source code analysis device of the first embodiment will be described with reference to FIG.

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

As shown in FIG. 2, the source code analysis device 10 has a processor 11, a main storage device 12, an auxiliary storage device 13, an input device 14, an output device 15, and a communication device 16 connected by a bus 5 so as to be able to communicate with each other. It has become.

The processor 11 is configured by using, for example, a CPU (Central Processing Unit) or an MPU (Micro Processing Unit). When the processor 11 reads and executes the program stored in the main storage device 12, various functions of the source code analysis device 10 are realized. The main storage device 12 is a device for storing programs and data, and is, for example, a ROM (Read Only Memory), a RAM (Random Access Memory), a non-volatile semiconductor memory (NVRAM (Non Volatile RAM)), and the like.

The auxiliary storage device 13 includes, for example, an HDD (Hard Disk Drive), an SSD (Solid State Drive), an optical storage device (CD (Compact Disc), DVD (Digital Versatile Disc), etc.), a storage system, and an IC card. , A reading / writing device for a recording medium such as an SD memory card or an optical recording medium, a storage area for a cloud server, and the like. The programs and data stored in the auxiliary storage device 13 are loaded and executed in the main storage device 12 at any time.

In this embodiment, in addition to an OS (Operating System) and various utilities (not shown), a logical coupling analysis program 1301, a logical coupling graph generation program 1302, an anti-pattern detection program 1303, and an anti-pattern display program 1304 are installed. The logical coupling analysis program 1301, the logical coupling graph generation program 1302, the anti-pattern detection program 1303, and the anti-pattern display program 1304 are the logical coupling analysis unit 101, the logical coupling graph generation unit 103, and the anti-pattern detection unit, respectively. 104, a program for executing each function of the anti-pattern display unit 119.

Further, the auxiliary storage device 13 has a program element change history 106, a basket analysis threshold table 107, a graph pattern match logic 110, a graph parameter threshold table 112, a parameter logic expression 113, a change dependency rule table 114, and a logical coupling graph 116. , Program element information 117, and anti-pattern graph 118 are stored. The details of various data will be described in detail later.

The input device 14 is, for example, a keyboard, a mouse, a touch panel, a card reader, a voice input device, or the like. The output device 15 is a device for realizing a user interface that provides various information such as processing progress and processing results to the user, and is, for example, a screen display device (liquid crystal monitor: LCD (Liquid Crystal Display)), a graphic card, and the like. Audio output devices (speakers, etc.), printing devices, etc. In addition, for example, the source code analysis device 10 may be configured to input and output information to and from another device via the communication device 16.

The communication device 16 is a wired or wireless communication interface that realizes communication with other devices via a communication means such as LAN or the Internet. For example, a NIC (Network Interface Card) or wireless communication. Modules, USB (Universal Serial Interface) modules, serial communication modules, etc.

Next, the data structure used in the source code analysis apparatus of the first embodiment will be described with reference to FIGS. 3 to 13.

The program element change history 106 shown in FIG. 3 records the history of changes that have occurred in the program to be analyzed as the change history record 303 each time a change occurs. The change history record 303 is composed of a change number 301 and a field of the above change program element name 302. The change number 301 is a field for storing an identifier uniquely assigned to identify the change history record 303. The change program element name 302 is a field for storing one or more change program element names that have been changed at the same time when the program change corresponding to the change history record 303 occurs. Program elements are program components such as functions, classes, and files, as described above.

For example, when a change corresponding to the change history record 303 in which the change number 301 is "1" occurs, the program elements of "program element A, program element B, program element C" described in the change program element name 302 are changed at the same time. ing.

For the program element change history 106, for example, the change history information of the version control system that manages the version of the program to be analyzed may be used. In this case, since version control is performed on a file-by-file basis in a general version control system, the type of program element to be analyzed is a file. Alternatively, the program element change history 106 may be converted from the change history information into change history information in class units or file units based on the program structure information. In this case, the type of program element to be analyzed is a class or a file.
Further, the update date of the program element may be added as the change history.

The basket analysis threshold table 107 shown in FIG. 4 records the thresholds used when performing basket analysis in the logical coupling analysis unit 101. Here, "basket analysis" is a term for data analysis, and is named by assuming that a program element that is changed at the same time is a product in a basket in a supermarket or the like. The basket analysis threshold table 107 has fields of the rule evaluation value name 401 and the threshold 402. The threshold value 402 stores a threshold value of 0 or more and 1 or less when evaluating the rule evaluation value described in the rule evaluation value name 401.

There are three rule evaluation values of the present embodiment, a support degree 403, a certainty degree 404, and a lift value 405, and a threshold value of 0 or more and 1 or less is described for each of them. The application of each rule evaluation value and its threshold value will be described in detail later.

The change dependency rule table 114 shown in FIG. 5 records the ordered pair of program elements that are easily changed at the same time as the change dependency rule record 504. The change dependency rule table 114 is a table that stores information obtained as a result of performing basket analysis by the logical coupling analysis unit 101 as a change dependency rule.

Here, the ordered pair of the ordered pair of program elements represents a rule that when the first program element of the ordered pair is changed, the second program element of the ordered pair is also likely to be changed at the same time. .. The change dependency rule record 504 has fields of rule number 501, change target program element name 502, and simultaneous change program element name 503.

Rule number 501 stores an identifier uniquely assigned to identify the change dependency rule record 504. The program element name 502 to be changed stores the first program element in the ordered pair of program elements. The simultaneous change program element name 503 stores the second program element in the above ordered pair.

It is assumed that the change dependency rule table 114 is initialized to a state in which no record is registered before the basket analysis is performed by the logical coupling analysis unit 101.

The logical coupling graph 116 shown in FIG. 6 is a directed graph in which the program element is the vertex 701 and the ordered pair of the program elements that are easily changed at the same time is the directed side 702. The logical coupling graph 116 is created by the logical coupling graph generation unit 103, and is output to the user by using the output device 15. By looking at the logical coupling graph 116, the user can confirm what kind of simultaneous changeable relationship is between the program elements. It is assumed that the logical coupling graph 116 is initialized to a state in which the vertices and the directed edges are not registered before the logical coupling creation process is performed by the logical coupling graph generation unit 103.

The graph pattern matching logic 110 shown in FIG. 7 records a logic for acquiring a graph parameter value in which a value is determined for each vertex of the graph of the logical coupling graph 116 shown in FIG. The graph pattern matching logic 110 is created for each type of graph parameter value to be acquired, and is composed of a graph parameter name 601 and a graph pattern matching logic main body 602. The graph parameter name 601 is a parameter representing the characteristics of the graph, and is, for example, the input degree and the output degree of the vertices of the directed graph. Further, as the graph parameter, other values generally defined by graph theory may be used. The graph pattern matching logic body 602 may use its own logic description language, or may be described by an executable programming language or script.

The program element information 117 shown in FIG. 8 records the graph parameter values for the vertices 701 of the logical coupling graph 116 shown in FIG. 6 for each program element. The program element information 117 is created for each program element, and is composed of a program element name 801 and a parameter table 802 corresponding to the program element. The parameter table 802 has each field of the graph parameter name 803 and the parameter value 804 for each parameter record 805. The graph parameter name 803 stores the graph parameter name defined by the graph pattern matching logic 110. The parameter value 804 stores the value of the parameter corresponding to the graph parameter name 803. In the value of the parameter value 804, the graph parameter value acquired by using the graph pattern matching logic main body 602 defined by the corresponding graph pattern matching logic 110 shown in FIG. 7 is recorded. This program element information 117 is output to the user using the output device 15. By looking at the program element information 117, the user can confirm what kind of graph parameter value the graph element corresponding to the program element has. It is assumed that the program element information 117 is initialized to the uncreated state before the program element information creation process is performed by the logical coupling graph generation unit 103.

The graph parameter threshold table 112 shown in FIG. 9 is a table in which a threshold value for determining that the parameter value is abnormal is recorded as a graph parameter threshold record 905 for the graph parameter name 601 defined by the graph pattern match logic 110. Is. The graph parameter threshold record 905 is composed of a graph parameter identifier 901, a graph parameter name 902, a graph parameter threshold value 903, and a field of graph parameter determination condition 904.

The graph parameter identifier 901 stores an identifier uniquely assigned to identify the graph parameter threshold record 905. The name of the graph parameter is stored in the graph parameter name 902. The graph parameter threshold value 903 stores a threshold value for determining an abnormality. The graph parameter determination condition 904 stores, for example, a determination condition for determining what value the graph parameter value corresponding to the graph parameter takes as compared with the graph parameter threshold value 903 to be regarded as abnormal.

Here, the graph parameter determination condition 904 describes a relational operator for comparing the graph parameter value and the graph parameter threshold value 903. The result of evaluating the graph parameter value using the graph parameter determination condition 904 and the graph parameter threshold value 903 is referred to as a determination result for the graph parameter value.

The parameter logical formula 113 shown in FIG. 10 is a logical formula for comprehensively evaluating the determination results for a plurality of parameter values and determining whether or not the set of the parameter values is abnormal. The parameter formula 113 is described using general characters and symbols used in logic, and its truth value can be evaluated by a general inference rule. For example, the parameter logical formula 113 is described using a graph parameter identifier 901, a logical operation symbol (& or |), a parenthesis symbol ((or)), and the like. Here, the truth value of the graph parameter identifier 901 in the graph parameter threshold table 112 is the true / false value of the logical expression obtained by using the logical operation symbol with the graph parameter identifier 901 as the primitive logical expression as the determination result for the graph parameter value 804. False values shall follow the general rules of reasoning in logic.

In the example shown in FIG. 10, it is shown that the logical expressions G1 and G2 represented by the graph parameter identifier 901 in the graph parameter threshold table 112 are true when they are G1 or G2. That is, this means that it is true when taken with (graph parameter A ≧ 4) OR (graph parameter B ≧ 6).

The anti-pattern graph 118 shown in FIG. 11 emphasizes the vertex 703 having a problematic feature in the vertex 701 of the logical coupling graph 116. Whether or not the vertex 701 of the logical coupling graph 116 is the vertex 703 having the problem feature is determined by using the parameter value 804 and the graph parameter threshold table 112 recorded in the program element information 117 of the program element corresponding to the vertex 703. Judgment is made based on the truth value evaluated by the method defined in the parameter logical expression 113. Here, if the truth value is true, it is determined that the vertex is a vertex 703 having a problem feature, and if the truth value is false, it is determined that the vertex is a vertex 703 having a problem feature. do. As a method of expressing the vertex 703 having the problem feature, a method such as coloring, emitting light, blinking, or enlarging the vertex may be adopted. The anti-pattern graph 118 is output to the user by the anti-pattern display unit 119 using the output device 15. By looking at the anti-pattern graph 118, the user can see what kind of simultaneous changeable relationships are between the program elements.

Here, an example of the anti-pattern graph of The Blob taken as an example is shown in FIG. The degree of the vertex 703a is extremely large. That is, it means that the program element indicated by the vertex 703a has a problem feature that a plurality of functions are collectively implemented in one place.

Further, an example of an anti-pattern graph of Shotgun surgery is shown in FIG. The order of the vertices 703b is extremely large. That is, it means that the program element indicated by the vertex 703b has a problem feature that when the program element is expanded or changed, many other program elements are also expanded or changed at the same time.

Next, the processing of the source code analysis apparatus of the first embodiment will be described with reference to FIGS. 14 to 18.

First, the processing of the logical coupling analysis unit 101 will be described with reference to FIG.
First, the logical coupling analysis unit 101 reads the program element change history 106 shown in FIG. 3 (S1201). Next, the basket analysis threshold table 107 is read (S1202).

The logical coupling analysis unit 101 generates all ordered pairs of program elements from the read program element change history 106, and executes the following processes S1203 to S1209 for each ordered pair (E1, E2) (S1203). ).

The degree of support for ordered pairs (E1, E2) is calculated (S1204). Here, the support degree for the ordered pair (E1, E2) is a value of 0 or more and 1 or less indicating the ease of simultaneous change of the program elements E1 and E2, and the change including E1 and E2 in the change program element name 302. It is a value obtained by dividing the number of history records 303 by the number of all change history records 303.

That is, the degree of support for the ordered pair (E1, E2) is a value represented by the following (Equation 1).

Next, the conviction for the ordered pair (E1, E2) is calculated (S1205). Here, the conviction for the ordered pair (E1, E2) is a value of 0 or more and 1 or less indicating the ease of change of E2 when the program element E1 is changed, and E1 and E2 are changed program element names. It is a value obtained by dividing the number of change history records 303 included in 302 by the number of change history records 303 including E1 in the change program element name 302.

That is, the conviction for the ordered pair (E1, E2) is a value represented by the following (Equation 2).

The lift value for the ordered pair (E1, E2) is calculated (S1206). Here, the lift value for the ordered pair (E1, E2) is uncorrelated when the value is 1 and positive correlation when the value is larger than 1, regarding the correlation between the change of the program element E1 and the change of E2. When it is small, it is a value of 0 or more indicating that there is a negative correlation. The lift value for the ordered pair (E1, E2) is a value represented by the following (Equation 3).

Next, it is determined whether all of the support, certainty, and lift values for the ordered pair (E1, E2) exceed the threshold 402 of each rule evaluation value 401 given in the basket analysis threshold table 107. (S1207).

When the support level, the certainty level, the lift value, and the lift value all exceed the threshold value (S1207: YES), the change dependency rule table 114 shown in FIG. 5 is given a unique rule number 501. The new change dependency rule record 504 is added, and the program element E1 is recorded in the change target program element name 502 of the change dependency rule record 504, and the program element E2 is recorded in the simultaneous change program element name 503 (S1208).

If any of the support, certainty, lift value, and lift value does not exceed the threshold value (S1207: NO), nothing is done.
The above is carried out for all ordered pairs (E1, E2) (S1203 to S1209).

Next, the processing of the logical coupling graph generation unit 103 will be described with reference to FIG.
First, the logical coupling graph generation unit 103 reads the change dependency rule table 114 shown in FIG. 5 (S1301).
Next, the graph pattern matching logic shown in FIG. 7 is read (S1302).
Next, a logical coupling graph generation process is performed (S1303). The logical coupling graph generation process will be described as a subroutine next with reference to FIG.
Next, the program element information generation process is performed (S1304). The program element information generation process will be described later as a subroutine with reference to FIG.

Next, the logical coupling graph generation process (S1303 in FIG. 15) will be described with reference to FIG.
The logical coupling graph generation unit 103 performs the following processing on all the program elements E (S1401 to S1404). Vertex N corresponding to the program element E is added to the logical coupling graph 116 shown in FIG. 6 (S1402). The logical coupling graph generation unit 103 creates the program element information 117 of FIG. 8 corresponding to the vertex N, and records the program element E as the program element name in the program element name 801 (S1403).
The above is carried out for all program elements E (S1401 to S1404).

Next, the following processing is performed for all ordered pairs (E1, E2) of the program elements (S1405 to S1407).
Next, a directed edge with E1 as the starting point and E2 as the ending point is added to the logical coupling graph 116 (S1406).
The above is carried out for all ordered pairs (E1, E2) of the program elements (S1405 to S1407).

Next, the program element information generation process (S1304 in FIG. 15) will be described with reference to FIG.
First, the following processing is performed on all the vertices N of the logical coupling graph 116 (S1501 to S1506).
The following processing is performed on all of the graph pattern matching logic L of the graph pattern matching logic 110 shown in FIG. 7 (S1502 to S1504).
Using the graph pattern matching logic main body 602 of the graph pattern matching logic L, the parameter value corresponding to the graph pattern matching logic L of the vertex N is acquired (S1503).
The above is carried out for all graph pattern matching logic L (S1502 to S1504).

Then, the graph parameter value of the vertex N is added to the program element information 117 of the vertex N (S1505).
The above is carried out for all the vertices N of the logical coupling graph (S1501 to S1506).

Next, the process of the anti-pattern detection unit 104 will be described with reference to FIG.
First, the parameter formula 113 shown in FIG. 10 is read (S1601).

Next, the following processing is performed on all the vertices N of the logical coupling graph (S1602 to S1606).
The graph parameter and its value of the program element information 117 for the vertex N shown in FIG. 8 and the threshold value and condition of the graph parameter are read from the graph parameter threshold table shown in FIG. 9, and the truth value of the parameter logical formula is calculated. (S1603). Then, it is determined whether the truth value is true or false (S1604). If the truth value is true (S1604: true), the vertex N in the anti-pattern graph 118 is set to be highlighted as a vertex corresponding to the abnormal program element (S1605). If the boolean value is false, do nothing. This indicates that the program element corresponding to the vertex N has a problem feature.
The above is carried out for all the vertices N of the logical coupling graph (S1601 to S1606).

In this way, by visualizing the program element having the problem feature as the vertex 703 having the problem feature in the anti-pattern graph 118, whether or not the program element has the problem feature indicated by the anti-pattern is shown in the change history of the program element. It can be determined based on.

[Embodiment 2]
Hereinafter, Embodiment 2 of the present invention will be described with reference to FIGS. 19 to 29.

In the first embodiment, the program element having the problematic feature for generating the anti-pattern graph is specified by the change history of the program element.
In addition to that, the present embodiment attempts to identify a program element having a problematic feature based on software metrics. In this embodiment, the points different from those in the first embodiment will be mainly described.

First, the configuration of the source code analysis apparatus of the second embodiment will be described with reference to FIGS. 19 and 20.
It is a lock diagram.
As shown in FIG. 19, the source code analysis device 10 of the present embodiment includes a program analysis unit 102 in addition to the case of the first embodiment shown in FIG.

In addition to the case of the first embodiment, the information storage unit 105 stores the software metric information 115 in the auxiliary storage device 13. In addition to these information, the information storage unit 105 stores information and the like that are appropriately referred to or generated by the program analysis unit 102.

As already explained, software metrics are the feature quantities of program elements obtained by program analysis of source code. Specifically, the complexity of source code, the number of steps in source code, and the ease of maintenance of source code. The sex index, the number of arguments of functions and subroutines, the ratio of comments to be embedded in the source code, etc. can be considered.

In addition to the case of the first embodiment, the source code analysis device 10 includes a program analysis unit 102, and in source code analysis, the program analysis unit 102 includes a source code 108 to be analyzed and software metrics acquisition logic. It accepts 109 and generates software metric information 115. Further, in addition to the case of the first embodiment, the logical coupling graph generation unit 103 receives the software metric information 115 and generates the program element information 117 including the information about the software metric. Further, the anti-pattern detection unit 104 accepts the software metric threshold table 111 and generates an anti-pattern graph 118 in consideration of the software metric, in addition to the case of the first embodiment.

The operation of the logical coupling analysis unit 101 is the same as that of the first embodiment.
Further, the operation of the anti-pattern detection unit 104 is the same as that of the first embodiment.

Next, the hardware / software configuration of the source code analysis apparatus of the second embodiment will be described with reference to FIG.
The source code analysis device 10 of the present embodiment has the same hardware configuration as the source code analysis device 10 of the first embodiment.

In addition to the program of the first embodiment, the program analysis program 1305 is installed in the auxiliary storage device 13. The program analysis program 1305 is a program that executes the function of the program analysis unit 102.

Further, in the auxiliary storage device 13, in addition to the data of the first embodiment, the source code 108, the software metric acquisition logic 109, and the software metric information 115 are stored. Details of these data will be described later.

Next, the data structure used in the source code analysis apparatus of the second embodiment will be described with reference to FIGS. 21 to 26.
The software metric acquisition logic 109 shown in FIG. 21 records the logic for acquiring the software metric value whose value is determined for each program element. The software metric acquisition logic 109 is created for each type of software metric value to be acquired, and is composed of a software metric name 1801 and a software metric acquisition logic main body 1802. Here, the software metric name 1801 may be a value that is generally evaluated by program analysis, such as the scale and complexity of program elements. Further, the software metric acquisition logic main body 1802 may use its own logic description language, or may be described by an executable programming language or script.

The software metric information 115 shown in FIG. 22 records the value of each program element of the software metric defined in the software metric acquisition logic 109 as a metric record 1903. The metric record 1903 consists of a field with a program element name 1901 and a software metric value 1902.

The program element name 1901 stores the name of the program element for which the metric is to be acquired. The software metric value 1902 stores the software metric value for each software metric name 1901 defined by the software metric acquisition logic 109.

It is assumed that the software metric information 115 is initialized to a state in which the metric record 1903 is not registered before the program analysis unit 102 performs the program analysis.

The program element information 117 shown in FIG. 23 takes into account information about software metrics in addition to the first embodiment. In the program element information 117, in addition to the case of the first embodiment, the software metric value 1904 relating to the program element is recorded as the parameter record 805 of the parameter table 802 of the program element information 117 corresponding to the program element.

The program element information 117 is output to the user by using the output device 15. The user can confirm what kind of software metrics the program element has by looking at the program element information 117.

The software metric threshold table 111 shown in FIG. 24 records the threshold value for determining that the software metric value 1904 is abnormal with respect to the software metric name 1902 recorded in the software metric information 115 as the software metric threshold record 2105. It was done. The software metric threshold record 2105 includes fields of a software metric identifier 2101, a software metric name 2102, a software metric threshold 2103, and a software metric determination condition 2104.

The software metric identifier 2101 stores an identifier uniquely assigned to identify the software metric threshold record 2105. The software metric name 2102 stores the name of the software metric. The software metric threshold 2103 stores the threshold value corresponding to the software metric. The software metric determination condition 2104 stores a condition for determining what value the software metric value 1904 takes as compared with the software metric threshold value 2103 to be regarded as abnormal.

Here, in the software metric determination condition 2104, for example, a relational operator for comparing the software metric value 1904 and the software metric threshold value 2103 is described. The result of evaluating the software metric value 1904 using the software metric determination condition 2104 and the software metric threshold value 2103 is referred to as a determination result for the software metric value.

The parameter formula 113 shown in FIG. 25 takes into account information about software metrics in addition to Embodiment 1.

In addition to the case of the first embodiment, the parameter logical expression 113 may be described by using the software metric identifier 2101 or the like. Here, the truth value of the software metric identifier 2101 is the determination result for the software metric value 804, and the truth value of the logical expression obtained by using the logical operation symbol with the software metric identifier 2101 as the primitive logical formula is the logic. It shall follow the general reasoning rules of.

In the example shown in FIG. 25, the logical formula S1 represented by the software metric identifier 2101 of the software metric threshold table 111 and the logical formulas G1 and G2 represented by the graph parameter identifier 901 of the graph parameter threshold table 112 (same as the first embodiment) are used. On the other hand, when it is S1 and (G1 or G2), it indicates that it is true. That is, this means that it is true when taken by (software metric A <25) AND ((graph parameter A ≧ 4) OR (graph parameter B ≧ 6)).

The anti-pattern graph 118 shown in FIG. 26 takes into account information about software metrics. In the anti-pattern graph 118, some of the vertices that were the vertices 703 having the problematic feature in the first embodiment are the normal vertices 702. This is because it is determined whether or not the program element has a problem feature by considering the determination result for the software metric value in addition to the determination result for the graph parameter value. In the judgment result for the graph parameter value, it was judged that the program element had a problem feature, but in the judgment result for the software metric value, it was judged that the program element did not have the problem feature, and such a program element was a problem. It is a normal vertex 702 instead of a characteristic vertex 703.

Next, the processing of the source code analysis apparatus of the second embodiment will be described with reference to FIGS. 27 to 29.
First, the program analysis unit 102 reads the source code 108 (S2401).
Next, the software metric acquisition logic 109 is read (S2402).
Next, the following processing is performed for all the program elements E (S2403 to S2408).
Next, the following processing is performed for all software metrics acquisition logic L (S2406 to S2404).

Using the software metric acquisition logic main body 1802 of the software metric acquisition logic L shown by the software metric acquisition logic 109 of FIG. 21, software metrics corresponding to the software metric acquisition logic L of the program element E are acquired (S2405).
The above is carried out for all software metrics acquisition logic L (S2404 to S2406).

The metric value of the program element E is added to the software metric information 115 of FIG. 22 (S2407).
The above is carried out for all program elements E (S2408).

The operation of the program analysis unit 102 may be performed by a program analysis tool sold as a commercial tool or a program analysis tool published as open source.

Next, the processing of the logical coupling graph generation unit 103 will be described with reference to FIG. 28.
In the present embodiment, a process of first reading software metrics (S1305) is added to the process of the logical coupling graph generation unit 103 shown in FIG. 15 of the first embodiment. Further, in the generation of program element information (S1304), the processing related to the software metrics shown in the flowchart of FIG. 29 is added.

The processing other than the above is the same as the processing of the logical coupling graph generation unit 103 shown in FIG. 15 of the first embodiment.

Next, the program element information generation process (S1304 in FIG. 28) will be described with reference to FIG. 29.

In the present embodiment, as compared with the case of the program element information generation processing shown in FIG. 17 of the first embodiment, the following processing is performed at the beginning of the processing (S1501) performed for all the vertices N of the logical coupling graph. Has been added.

The following processing is performed for all program elements E (S1507 to S1509).
The software metric value of the program element E corresponding to the vertex N is added to the program element information of the vertex N (S1508).
The above is carried out for all program elements E (S1507 to S1509).

The processing other than the above is the same as the program element information generation processing shown in FIG. 17 of the first embodiment.

As described above, according to the present embodiment, it is possible to determine with higher accuracy whether or not the program element has the problematic feature indicated by the anti-pattern by considering not only the change history of the program element but also the software metric. It will be like.

[Embodiment 3]
Hereinafter, the third embodiment according to the present invention will be described with reference to FIGS. 30 to 32.

In the first embodiment, a source code analysis device that generates an anti-pattern graph based on the change history of past program elements, and in the second embodiment, in addition to the functions of the first embodiment, source code and software metrics information are added. , A source code analyzer that generates anti-pattern graphs has been described.

The present embodiment displays the information of the software metric threshold table 111, the graph parameter threshold table 112, and the parameter logic expression 113 in the first embodiment or the second embodiment, and displays the information of the software metric threshold table 111, the graph parameter threshold table 112, and the graph parameter threshold table 112. The data of the parameter logical expression 113 is input from the user, and the output of the anti-pattern graph 118 accompanying the change in the value is interactively performed on the user interface.

In this embodiment, the points different from those of the first and second embodiments will be mainly described.
First, the configuration of the source code analysis apparatus of the second embodiment will be described with reference to FIGS. 30 and 31.

As shown in FIG. 30, the source code analysis device 10 of the present embodiment includes a system parameter input / output unit 120 in addition to the case of the second embodiment shown in FIG. T.

The system parameter input / output unit 120 is a functional unit that inputs / outputs to the software metric threshold table 111, the graph parameter threshold table 112, and the parameter logical formula 113. These inputs and outputs are performed by the system parameter update screen 2700 described later.

The source code analysis device 10 of the present embodiment has the same hardware configuration as the source code analysis device 10 of the first and second embodiments.

In addition to the program of the second embodiment, the system parameter input / output program 1306 is installed in the auxiliary storage device 13. The system parameter input / output program 1306 is a program that executes the function of the system parameter input / output unit 120.

Next, the user interface of the source code analyzer will be described with reference to FIG. 32.
The user displays the system parameter update screen 2700, displays the information of the software metric threshold table 111, the graph parameter threshold table 112, and the parameter logical formula 113 on the output device 15 such as a display, and inputs and updates the data. be able to.

The system parameter update screen 2700 is composed of a software metric threshold input field 2701, a graph parameter threshold input field 2702, and a parameter logical formula input field 2703.

The software metric threshold input field 2701 includes one or more software metric threshold element input fields 2704. The software metric threshold element input field 2704 includes a software metric identifier display field 2705, a software metric name display field 2706, a software metric threshold input field 2707, a software metric determination condition input field 2708, and a software metric threshold input slider 2709.

The software metric identifier display column 2705 is a column in which the software metric identifier 2101 is displayed. The software metric name display column 2706 is a column in which the software metric name 2102 is displayed. The software metric threshold input field 2707 is a field for inputting the software metric threshold 2103 in the software threshold table 111 shown in FIG. 24. The software metric determination condition input field 2708 is a field for inputting the software metric determination condition 2104. The software metric threshold input slider 2709 is a field for visually inputting the software metric threshold 2103.

The graph parameter threshold input field 2702 includes one or more graph parameter threshold element input fields 2710. The graph parameter threshold element input field 2710 includes a graph parameter identifier display field 2711, a graph parameter name display field 2712, a graph parameter threshold input field 2713, a graph parameter determination condition input field 2714, and a graph parameter threshold input slider 2715.

The graph parameter identifier display column 2711 is a column in which the graph parameter identifier 901 is displayed. The graph parameter name display column 2712 is a column in which the graph parameter name 902 is displayed. The graph parameter threshold value input field 2713 is a field for inputting the graph parameter threshold value 903. The graph parameter determination condition input field 2714 is a field for inputting the graph parameter determination condition 904. The graph parameter threshold value input slider 2715 is a field for visually inputting the graph parameter threshold value 903.

The parameter logical formula input field 2703 is a field for inputting the parameter logical formula 113 shown in FIGS. 10 and 25.

The user can use such a software metric threshold input field 2707, a software metric judgment condition input field 2708, a software metric threshold input slider 2709, a graph parameter threshold input field 2707, a graph parameter judgment condition input field 2708, and a graph parameter threshold input slider 2709. By inputting the software metric threshold, the graph parameter threshold, and the parameter logical expression using the parameter logical expression input field 2703 and confirming the output anti-pattern graph 118, the interactive input of the software metric value becomes possible.

5 ... Bus, 10 ... Source code analyzer, 11 ... Processor, 12 ... Main storage device, 13 ... Auxiliary storage device, 14 ... Input device, 15 ... Output device, 16 ... Communication device,
101 ... Logical coupling analysis unit, 102 ... Program analysis unit, 103 ... Logical coupling graph generation unit, 104 ... Anti-pattern detection unit, 105 ... Information storage unit, 119 ... Anti-pattern display unit, 120 ... System parameter input / output unit ,
108 ... Source code, 109 ... Software metric acquisition logic, 114 ... Change dependency rule table, 115 ... Software metric information, 116 ... Logical coupling graph, 117 ... Program element information

Claims (8)

A source code analysis device that points out problems related to the maintainability of the source code of the program to be analyzed.
A logical coupling analysis unit that inputs the change history of the program to be analyzed and the threshold value of the index related to the program change and outputs the change dependency rule of the program element.
Based on the change dependency rule, a logical coupling generator that generates a logical coupling graph that expresses the change dependency of a program element, with the program element as a node and the ordered pair of program elements that are easily changed at the same time as directed edges. When,
Based on the generated logical coupling graph and the information about the graph parameters defined for each program element, the program element with low maintainability is detected in the logical coupling graph, and the node of the program element with low maintainability is detected. An anti-pattern detector that makes an emphasized anti-pattern graph,
A source code analysis device including an anti-pattern display unit that displays the anti-pattern graph. Further, a program analysis unit that inputs the source code of the program to be analyzed and the software metric acquisition logic that defines the software metric logic for each software metric, and outputs the software metric information that defines the software metric value for each program element. Have,
The anti-pattern detection unit has low maintainability of the logical coupling graph based on the generated logical coupling graph, information on graph parameters defined for each program element, and information on software metrics. The source code analysis device according to claim 1, wherein the anti-pattern graph emphasizes the nodes of the program element. The source code analysis apparatus according to claim 1, further comprising means for inputting a value relating to the graph parameter, a determination condition relating to the graph parameter, and a logical expression for determining the graph parameter. The source code analysis apparatus according to claim 2, further comprising means for inputting a value related to the software metric, a determination condition related to the software metric, and a logical expression for determining the software metric. It is a source code analysis method that points out problems related to the maintainability of the source code of the program to be analyzed.
A logical coupling analysis step that outputs the change dependency rule of the program element by inputting the change history of the program to be analyzed and the threshold value of the index related to the change of the program.
Based on the change dependency rule, the logical coupling generation step to generate a logical coupling graph expressing the change dependency of the program element by using the program element as a node and the ordered pair of the program elements that are easily changed at the same time as the directed edge. When,
Based on the generated logical coupling graph and the information about the graph parameters defined for each program element, the program element with low maintainability is detected in the logical coupling graph, and the node of the program element with low maintainability is detected. An anti-pattern detection step with an emphasized anti-pattern graph,
A source code analysis method comprising an anti-pattern display step for displaying the anti-pattern graph. Further, a program analysis step in which the source code of the program to be analyzed and the software metric acquisition logic that defines the software metric logic for each software metric are input, and the software metric information that defines the software metric value for each program element is output. Have,
The anti-pattern detection step makes the logical coupling graph less maintainable based on the generated logical coupling graph, information about graph parameters defined for each program element, and information about software metrics. The source code analysis method according to claim 5, wherein the anti-pattern graph emphasizes the nodes of the program element. The source code analysis method according to claim 5, further comprising a step of inputting a value relating to the graph parameter, a determination condition relating to the graph parameter, and a logical expression for determining the graph parameter. The source code analysis method according to claim 6, further comprising a step of inputting a value relating to the software metric, a determination condition relating to the software metric, and a logical expression for determining the software metric.

Images