JP2016143107A - Source code evaluation system and method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an efficient program analysis method for specifying a source code in which factoring is truly necessary, without extracting a complicated source code in which refactoring is unnecessary.SOLUTION: A program analysis method includes steps of: measuring metrics from a source code/configuration management system/operation log; evaluating whether the source code is applicable to an anti pattern using the metrics measurement result; and calculating and presenting priority of refactoring on each source code using the metrics measurement result.SELECTED DRAWING: Figure 1

Description

  The present invention relates to evaluation of enterprise systems (business systems). Among them, it relates to source code evaluation for improving maintainability of applications.

  Enterprise system applications may become complicated over time due to the addition of ad hoc functions. When it becomes complicated, it becomes easy for an operator to introduce defects when adding or correcting functions in the system. The structure of the source code that makes it easy to insert defects is called “anti-pattern”. The anti-pattern compiles without any problem in the programming grammar.

  However, readability and maintainability deteriorate, and the structure is such that the operator may make a mistake in understanding the processing flow written in the source code, or induce omission of work for adding or correcting functions. Anti-patterns do not cause system failures immediately, but if left unchecked, they can cause system failures later.

  There are dozens of anti-patterns that are known only for their characteristics. For example, an anti-pattern “one method is too long” or an anti-pattern “too many arguments”. Each anti-pattern classified into these features is called an “anti-pattern factor”.

  Modifying the anti-pattern factor that exists in the source code is called refactoring. In the refactoring work, a large amount of source code is read, anti-pattern factors are extracted, and refactoring is performed according to the characteristics of the anti-pattern factors. This not only takes a lot of man-hours, but also requires high skills for refactoring workers.

  Therefore, research on a technique for automatically extracting features of anti-pattern factors existing in source code and performing anti-pattern extraction / refactoring operations with a small number of man-hours has been conducted. For example, Patent Documents 1 and 2 use metrics that quantitatively evaluate source code complexity such as cyclomatic complexity and the number of code lines, and extract and present modules with high complexity from the measurement results. Furthermore, the priority of refactoring is presented according to the degree of complexity and the cost due to the complexity.

WO2008 / 020468 JP2014-032466

  In the above patent documents, it is often difficult to deal with complicated source code. Here, there are two main reasons why the source code is complicated. One is that the processing flow itself is complicated and the structure of the source code must be complicated. The other was source code with a simple structure at the beginning of operation, but there was a complicated structure due to repeated addition of functions on an ad hoc basis. The former need not be refactored and the latter needs to be refactored.

  The above Patent Documents 1 and 2 focus only on the complexity of the source code. Therefore, not only complicated source code that needs refactoring but also complicated source code that does not require refactoring is extracted, and the efficiency of the refactoring work cannot be improved.

  In order to solve the above problems, the present invention extracts source code that needs to be refactored, in other words, source code having a complicated structure. Furthermore, a refactoring method is proposed based on the characteristics of the extracted anti-pattern factor of the source code, and the refactoring priority for each module is presented from the viewpoint of the refactoring effect and cost. It is also an aspect of the present invention to acquire a plurality of types of metrics / information from a plurality of resources such as system logs and to evaluate whether various anti-pattern factors exist by combining them.

  Furthermore, in a desirable aspect of the present invention, metrics acquisition means in each module (class) unit of the source code from the configuration management system, a difference between each version of the source code, and metrics acquisition means for the difference unit, Metric acquisition means for configuration management system log, metrics measurement means for operation log, means for evaluating whether or not it corresponds to various anti-pattern factors from the obtained metric values, and refactoring from the types of applicable anti-pattern factors A means for proposing a method, a means for calculating refactoring priority, and a refactoring means / priority are displayed on the screen.

  According to the present invention, an anti-pattern factor existing in a large-scale source code can be extracted more efficiently and efficiently.

It is a functional block diagram in one embodiment of this invention. It is a functional block diagram in one embodiment of the present invention. It is a figure which shows the example of the sensor metric value table in the function in one embodiment of this invention. It is a figure which shows an example of the data stored in the difference code metric value table in one embodiment of this invention. It is a figure which shows an example of the data stored in the source code metric value table in one embodiment of this invention. It is a figure which shows the processing flow of the anti-pattern evaluation in one embodiment of this invention It is a figure which shows the characteristic of the anti-pattern factor 1 used by one embodiment of this invention. It is a figure which shows an example of the anti-pattern evaluation logic definition file corresponding to the anti-pattern factor 1 used by one embodiment of this invention. It is a figure which shows an example of the anti-pattern evaluation utilization metrics threshold value definition file corresponding to the anti-pattern factor 1 used by one embodiment of this invention. It is a figure which shows the characteristic of the anti-pattern factor 2 used by one embodiment of this invention. It is a figure which shows an example of the anti-pattern evaluation logic definition file corresponding to the anti-pattern factor 2 used by one embodiment of this invention. It is a figure which shows an example of the anti-pattern evaluation utilization metrics threshold value definition file corresponding to the anti-pattern factor 2 used by one embodiment of this invention. It is a figure which shows an example of the data stored in the anti-pattern determination table in one embodiment of this invention. It is a figure which shows an example of the data stored in the anti-pattern refactoring procedure table in one embodiment of this invention. It is a figure which shows an example of the data stored in the refactoring technique plan list table in one embodiment of this invention. It is a figure which shows an example of the refactoring method and priority list screen in one embodiment of this invention. It is a figure which shows the logic of the effective sensor execution in view of the anti-pattern evaluation logic definition file in one embodiment of this invention.

  Hereinafter, an embodiment of the present invention will be described with reference to the drawings. First, FIG. 1 shows a functional configuration diagram of a source code evaluation system according to the present embodiment. The computer 1 includes a memory 10, an HDD 11, a CPU 12, a display device 13, and an input device 14. The memory 10 includes a differential code metrics acquisition unit, a source code metrics acquisition unit, a configuration management log metrics acquisition unit, an operation log metrics acquisition unit, an anti-pattern evaluation unit, a refactoring method proposal unit, a refactoring method / priority list. A screen display unit. In other words, the processing program stored in the HDD 11 is expanded on the memory 10, and the CPU 12 performs calculations to realize each function. The HDD 11 includes a source code storage unit 111, an operation log storage unit 112, a differential code metrics value table storage unit 113, a source code metrics value table storage unit 114, an anti-pattern evaluation logic definition file storage unit 115, and an anti-pattern evaluation A usage metrics threshold value definition file storage unit 116, an anti-pattern determination table storage unit 117, an anti-pattern refactoring procedure table storage unit 118, and a refactoring technique list table storage unit 119 are provided. These indicate that each part of the memory 10 described above, that is, various data used for each function of the program is held in the HDD 11.

FIG. 2 shows a functional block diagram of the source code evaluation system according to the embodiment of the present invention. That is, an overview of each function of the above-described program will be described.
The source code storage unit 111 is a software configuration management system. Source code version management and change recording. The difference code metrics acquisition unit 101 acquires a source code class of a certain version and a class of the previous version from the source code storage unit 111, and calculates the presence / absence of a difference. When there is a difference, metrics such as the number of code lines and the number of nesting are measured, and the result is output to the difference code metrics value table storage unit 113. Further, the source code metrics acquisition unit 102 acquires each class of each version from the source code storage unit 111, performs metrics measurement, and outputs the result to the source code metrics value table storage unit 114. The configuration management log metrics acquisition unit 103 acquires information related to the change history such as the source code modification date, and outputs the result to the source code metrics value table storage unit 114.

The operation log storage unit 112 stores a history log of system operation status such as the load of system resources and system failures. The operation log metrics acquisition unit 104 acquires an operation log from the operation log storage unit 112, extracts information such as the date of failure, and outputs the result.
The differential code metrics acquisition unit 101, the source code metrics acquisition unit 102, the configuration management log metrics acquisition unit 103, and the operation log metrics acquisition unit 104 are functions that take information necessary for anti-pattern evaluation from system resources. These are collectively defined as “sensor unit”. The individual functions for acquiring various metrics and information are called “sensors”.

  FIG. 3 shows an example of a sensor, parameters necessary for the sensor, and a format of a value output from the sensor. The type of metrics and information to be acquired is described in the sensor column. The parameter column describes the information format of the source code necessary for executing the sensor. The value column describes the format of the value output as a result of sensor execution. The column of the acquisition means describes which function the sensor 101, 102, 103, 104 is from.

  FIG. 4 shows an example of the format of a table output from the differential code metrics acquisition unit 101 and stored in the differential code metrics value table storage unit 113. A table is created for each class of source code. A “version difference” line in a table of a class indicates which version and which version of the class are taken, and the metric value of the difference part is stored.

FIG. 5 shows an example of a table format output from the source code metrics acquisition unit 102, the configuration management log metrics acquisition unit 103, and the operation log metrics acquisition unit 104 and stored in the source code metrics value table storage unit 114. Show. A table is created for each class of source code. A version number is indicated in the “version” line in a table of a class, and a metric value in each version is stored.
The anti-pattern evaluation unit 105 has a function of evaluating whether each class corresponds to various anti-pattern factors.

  FIG. 6 shows a processing flow in the anti-pattern evaluation unit 105. It is executed from step 1051. In step 1051, an anti-pattern evaluation logic definition file corresponding to the anti-pattern factor to be evaluated is acquired from the anti-pattern evaluation logic definition file storage unit 115. In step 1052, the anti-pattern evaluation utilization metrics threshold value definition file corresponding to the anti-pattern factor to be evaluated is acquired from the anti-pattern evaluation utilization metrics threshold value definition storage unit 116. In step 1053, the metric value used for anti-pattern evaluation is grasped from the anti-pattern evaluation logic definition file acquired in step 1051, and it is acquired from the differential code metric value table storage unit 113 and the source code metric value table storage unit 114. . In step 1054, it is determined whether each class corresponds to an anti-pattern factor according to the logic described in the anti-pattern evaluation logic definition file acquired in step 1051. If it is determined in step 1055 that a certain class corresponds to the anti-pattern factor, “◯” is stored in the corresponding anti-pattern factor column of the anti-pattern determination table storage unit 117 in step 1056. If it is determined in step 1055 that a certain class does not correspond to the anti-pattern factor, “x” is stored in the corresponding anti-pattern factor column of the anti-pattern determination table storage unit 117 in step 1056.

Next, a specific example of processing for evaluating whether or not the anti-pattern factor 1 to be evaluated is applicable will be described with reference to FIGS.
First, FIG. 7 shows the characteristics of anti-pattern factor 1. Anti-pattern factor 1 is a class that has become huge by adding individual business processes to the business common class in an ad hoc manner. Therefore, the anti-pattern is complicated to follow the processing flow and the readability is deteriorated. This is because the code size is large, the new version source code adds a new difference compared to the old version source code, the difference is an if clause, the number of occurrences of differences between versions of the same class is large, the result of the current source code It has the feature that the number of nesting is large.
From the above, anti-pattern factor 1 has “code line count” of 100 or more, “code comparison” has a difference, “branch” has a difference of if clause, if clause has a difference of 5 or more, and current version If the number of nestings in the source code is 5 or more, the logic is that it corresponds.

FIG. 8 shows the above logic in a description language. FIG. 8 is stored in the anti-pattern evaluation logic definition file storage unit 115.
The logic described in FIG. 8 is as follows.

  First, a source code class for anti-pattern evaluation is declared (specified), and a past version code of the target class is declared using a sensor “past code”. Here, for each class and code, all of the target may be specified. The sensor “code comparison” is used to take the difference between versions of one class, and the sensor “branch” is used to determine whether each difference is a branch sentence. If it is a branch sentence, the judgment value is 1 and if it is a branch sentence, the judgment value is 0, and the sum of the branch sentence judgment values of each difference is derived. On top of that, the sum of branch statement judgment values is i or more, the number of code lines of the latest source code derived using sensor “number of code lines” is more than j, and the latest derived using sensor “nesting” If the source code nesting number is greater than or equal to k, it corresponds to anti-pattern factor 1. It should be noted that the values entering i, j, and k are set in the anti-pattern evaluation utilization metrics threshold value definition file storage unit 116. The contents will be described below.

  FIG. 9 defines metrics thresholds used in the above logic. FIG. 9 is stored in the anti-pattern evaluation utilization metrics threshold value definition file storage unit 116. The i, j, and k parameters set in the logic description language of FIG. 8 are the number of branch statement corrections, the maximum number of rows, and the maximum number of nestings, respectively. The threshold values for determining the anti-pattern factor 1 are set to 5 or more, 100 or more, or 4 or more for i, j, and k, respectively.

Further, a specific example of processing for evaluating whether or not the anti-pattern factor 2 is applicable will be described with reference to FIGS.
First, FIG. 10 shows the characteristics of anti-pattern factor 2. Anti-pattern factor 2 is obtained by adding the same processing to multiple places with if statements when adding functions. Therefore, when the additional portion is corrected, it is necessary to correct other similar processing portions, which is an anti-pattern that may cause a correction error. This is because the new version source code has a new difference compared to the old version source code, there are multiple differences between versions of the same class, the difference is an if clause, and the difference is the code from other source code. It is a clone.

  From the above, anti-pattern factor 2 is applicable if there is a difference in “code comparison”, if there is an if clause in “branch”, if there is a difference in if clause more than once, and the difference is a clone Use logic.

Next, FIG. 11 shows the above logic in a description language. FIG. 11 is stored in the anti-pattern evaluation logic definition file storage unit 115.
The logic described in FIG. 11 is as follows.
First, declare the source code class for anti-pattern evaluation, and declare the past version of the target class using the sensor “past code”. Here, for each class and code, all of the target may be specified.

  First, the difference between each version of one class is obtained using the sensor “code comparison”, and it is determined whether each difference is a branch sentence using the sensor “branch”. If it is a branch sentence, the judgment value is 1 and if it is a branch sentence, the judgment value is 0, and the sum of the branch sentence judgment values of each difference is derived. Further, it is checked whether each difference is a code clone using a sensor “clone”. In addition, if the sum of branch sentence determination values is m or more and the difference is a clone, it corresponds to anti-pattern factor 2. Note that the value entering m is set in the anti-pattern evaluation utilization metrics threshold value definition file storage unit 116. These will be described below.

FIG. 12 defines a metric threshold used in the logic. FIG. 12 is stored in the anti-pattern evaluation utilization metrics threshold definition file storage unit 116. The parameter m set in the logic description language of FIG. 11 is the number of code corrections. The threshold for determining that the anti-pattern factor is 1 is set such that m is 2 or more.
FIG. 13 shows an example of a table output from the anti-pattern evaluation unit 105 and stored in the anti-pattern determination table storage unit 117. “○” is stored if each class corresponds to various anti-pattern factors, and “X” is stored otherwise.

Next, FIG. 14 shows an example of a table of a refactoring procedure for each anti-pattern factor and a refactoring estimated man-hour per 1 Kstep calculated from past results. This table is stored in the anti-pattern refactoring procedure table storage unit 118. Here, the refactoring method proposing unit 106 includes the anti-pattern determination table storage unit 117 to the table of FIG. 13 and the anti-pattern refactoring procedure table storage unit 118 of FIG. The table 14 and the number of failure occurrences of each class are acquired from the source code metric value table storage unit 114, and a refactoring element list table is created.

Next, FIG. 15 shows an example of the refactoring element list table created by the refactoring method proposing unit 106 and stored in the refactoring element list table storage unit. What refactoring method to use based on the type of anti-pattern factor that corresponds to each class, the column that shows whether each class falls under various anti-pattern factors, the column that shows the number of failures per year for each class, and There is a column for indicating whether or not to be calculated, and a column for calculating and indicating the refactoring man-hours of each class according to the number of steps of each class.
FIG. 16 shows an example of contents displayed on the refactoring technique / priority list screen display unit 107. The screen has a field for entering the planned operation period of the project, a field for entering the cost for one fault correction in the project, a field for indicating the refactoring priority ranking number, and a class name. A table having a column, a column indicating the type of anti-pattern factor existing in each class, a column indicating a refactoring technique to be taken by each class, and a column indicating a refactoring priority evaluation value is displayed.
The refactoring priority evaluation value is derived by the following formula.
Refactoring Priority evaluation value = Refactoring effect-Refactoring man-hours
= {Number of annual average failures (times / 365 days)
× Operation period (days)
× Costs required for correcting one failure (person month / time)}
− Estimated man-hours for refactoring (person month)… (Equation 1)
In the refactoring priority ranking, a class having a large refactoring effect with respect to the refactoring man-hour, that is, a class having a large refactoring priority evaluation value is ranked and displayed so as to have a high priority.

  FIG. 17 shows a processing flow for efficiently executing the sensor units 101, 102, 103, and 104. It is executed from step 1001. In step 1001, the anti-pattern evaluation logic definition file is read from the anti-pattern evaluation logic definition file storage unit 115, and the metric type necessary for the anti-pattern evaluation is acquired. In step 1002, the metrics threshold value determination conditions necessary for the anti-pattern factor evaluation are acquired from the anti-pattern evaluation utilization metrics threshold definition file storage unit 116. In step 1003, the metrics that can be determined whether or not the anti-pattern is only the function 102 are listed from the obtained metrics. In step 1004, the metrics of each class are measured. In step 1005, threshold determination is performed on the metric value obtained in step 1004 using the threshold determination condition obtained in step 1002.

In step 1006, if the result of the threshold determination is that the determination condition is met, the class is determined to be a metric measurement target in step 1007 and becomes a measurement target in the anti-pattern evaluation unit 105. On the other hand, if it is determined in step 1006 that the threshold value does not match the determination condition, it is determined in step 1008 that the class is not subject to metrics measurement, and the anti-pattern evaluation unit 105 does not measure it.
In addition, by using the above-described sensor execution process flow, the anti-pattern evaluation unit 105 can narrow down the number of target classes, which is efficient.

  As described above, according to an embodiment of the present invention, it is possible to extract an anti-pattern factor with a small number of steps and with high accuracy. Moreover, even if the operator of anti-pattern factor extraction / refactoring is not an expert, it can be performed easily.

DESCRIPTION OF SYMBOLS 1 ... Computer, 10 ... Memory, 11 ... HDD, 12 ... CPU, 13 ... Display apparatus, 14 ... Input device, 101 ... Difference code metrics acquisition part, 102 ... Source code metrics acquisition part, 103 ... Configuration management log metrics acquisition part , 104 ... Operation log metrics acquisition unit, 105 ... Anti-pattern evaluation unit, 106 ... Refactoring method proposal unit, 107 ... Refactoring method / priority list screen display unit, 111 ... Source code storage unit, 112 ... Operation log storage unit, 113 ... difference code metrics value table storage unit, 114 ... source code metrics value table storage unit, 115 anti-pattern evaluation logic definition file storage unit, 116 ... anti-pattern evaluation utilization metrics threshold definition file storage unit, 117 ... anti-pattern determination table storage unit , 118 ... Anne Pattern refactoring procedure table storage unit, 119 ... refactoring element list table storage unit

Claims (5)

In a source code evaluation system that analyzes a program used in the system and extracts an anti-pattern of the program,
Means for measuring metrics from information about operation including source code of the system;
Means for evaluating, using the measured metrics, an index indicating the complexity of whether or not the source code is an anti-pattern;
A source code evaluation system comprising means for calculating and presenting a priority of refactoring of the source code for the evaluated result The source code evaluation system according to claim 1,
The source code evaluation system further comprising means for describing the anti-pattern using the metrics item as an element. The source code evaluation system according to claim 1,
Means for obtaining a difference between each version of the source code and obtaining a metric for the obtained difference;
The source code evaluation system further comprising means for evaluating whether or not the source code corresponds to an anti-pattern using the acquired difference. The source code evaluation system according to claim 1,
A source code evaluation system further comprising means for estimating an effect of reducing the occurrence of failure by performing refactoring and man-hours for performing refactoring, and posting a refactoring priority from the estimated result. The source code evaluation system according to claim 1,
The source further comprising means for narrowing down metrics satisfying a specific condition based on the metrics measured from the source code, and determining whether or not other metrics can be acquired based on the narrowed metrics. Code evaluation system.

Images