-Restructuring is an important activity to improve software internal structure. Even though there are many restructuring approaches, very few consider the refactoring impact on the software quality. In this paper, we propose an semiautomatic software restructuring approach based on quality attributes. We rely on the measurements of the Quality Model for Object Oriented Design (QMOOD) to recommend Move Method refactorings that improve software quality. In a nutshell, given a software system S, our approach recommends a sequence of refactorings R1, R2, . . . , Rn that result in system versions S1, S2, . . . , Sn, where quality(Si+1) > quality(Si). We empirically calibrated our approach to find the best criteria to measure the improvement of quality. In our preliminary evaluation on three open-source systems, our approach achieved an average recall of 57%.
The refactoring process changes the code to improve the
internal structure without compromising its external
behavior [
In this paper, on the context of a search-based software
engineering research, we propose an semi-automatic software
restructuring approach based on software quality metrics. We
rely on the measurements of the Quality Model for Object
Oriented Design (QMOOD) [
We empirically calibrated our approach to find the best criteria to assess software quality improvement. First, we modified the JHotDraw system by randomly moving a subset of its methods to other classes. Second, we verified if our approach would recommend the moved methods to return to their original place. After testing five different calibration criteria, we calibrated the approach with the one that achieved the best f-score (38%), which corresponds to a precision of 27% and a recall of 65%.
We implemented QMove, a prototype plug-in for Eclipse IDE that supports our proposed restructuring approach with our current calibration. The plug-in receives as input a Java system and outputs the better sequence of Move Method refactorings that improves the overall software quality.
Finally, we evaluated our approach on three open-source systems: FreeMind, Maven, and WCT. Similar to our calibration method, we modified the original systems by randomly moving a subset of their methods to other classes. Next, we verified if our approach recommended the moved methods to return to their original classes. As result, QMove could move back 57% of the methods, on average.
The remainder of this paper is organized as follows. Section II presents the basic concepts to better understand our approach. Section III describes and calibrates our proposed approach. Section IV evaluates our approach. Finally, Section V discusses the related work and Section VI concludes.
Refactoring is basically restructuring applied to
objectoriented programming [
From the several types of refactoring, we highlight the Move Method, which is used in our proposed restructuring approach. A Move Method refactoring consists in moving a method from one class to another. The move can even occur to classes in different packages. There are many reasons to move a method to a different class to improve the software quality. A common scenario for this refactoring is when we realize that a method depends more from members from another class than its own (a bad smell named Feature Envy).
Bansiya and Davis [
We propose an semi-automatic restructuring approach by using Move Method refactoring and six quality attributes defined by QMOOD (Table II). First, the approach calculates the six quality attributes for the analyzed software. Second, we detect every method that could be moved automatically to another class. Third, for each method, we move it to a different class, recalculate the quality attributes, and return it to its original place. Fourth, we include the refactoring that achieved better quality measurements to the recommendation list and repeat the third step for the remaining methods. After we processed every method, we present a recommendation list showing the sequence of Move Method refactorings ordered by their quality results (highest to lowest).
This section illustrates a Move Method refactoring scenario where our approach could be performed. Suppose a small Java system S with two classes: A and B. Class A has two methods: methodA1 and methodA2. For this example, we highlight method methodA2 (Listing 1) that receives a B object as a formal parameter. The code inside the method accesses only the attribute from class B by using the object b (lines 2-3). More specifically, the method prints class B attribute if its value is not zero (lines 3) and “Empty” otherwise (line 5). Therefore, we can deduce that it would be more appropriate if we moved this method to class B, which creates a new system version S0. Figure 1 shows a UML diagram of the classes described in our example, before and after we move the aforementioned method.
When we apply our approach to system S, first we compute the QMOOD quality attributes for S. Then, we detect methodA2 as a method that could be moved to another class. The method is moved to class B creating the new system version S0. We recompute the quality metrics for S0 and then we return the method to class A, which is its original place. In this particular case, since there are only two classes, our approach finishes its analysis. However, if other classes did exist, then our approach would repeat the process by moving the method to another class and recalculating the quality metrics again.
Table III shows the QMOOD quality attributes for S and S0, and the difference between S0 and S. Even though, flexibility, effectiveness, and extendibility remain the same, the values for the other three quality attributes (reusability, functionality, understandability) improve. Since it shows better quality attributes, our approach would recommend methodA2 to be moved to class B (as previous illustrated in Figure 1).
TABLE III: Quality Attributes for our Example
Reusability Flexibility Understandability Functionality Extendibility Effectiveness
S 1.4375 -0.1250 0.2000 0.2500 0.6900 -1.4025
S’ 1.5000 -0.1250 0.2000 0.2500 0.7200 -1.3190
S’ - S 0.0625 0.0000 0.0000 0.0000 0.0300 0.0835
Algorithm 1 describes our proposed approach in a highlevel abstraction. It is worth noting that before we execute the algorithm, we make a copy of the analyzed system, and the algorithm is executed in this copy (and not the actual system).
The algorithm receives as input a list containing all methods with their respective class from the analyzed system. The output is a sequence of Move Method refactorings that resulted in better quality metrics, ordered from highest to lowest according to the quality measurements.
First, it calculates the current six QMOOD quality metrics for the analyzed system (line 5). Second, it determines which methods of the system (m) that can be automatically moved to other classes (C) (lines 6-10) and store the pairs (m, C) in the list of potential refactorings (line 8).
Algorithm 1: Proposed Approach Algorithm end /* find the refactoring with the best metrics */ bestRefactoring := maxMetrics(candidates) applyRefactoring(bestRefactoring) potRefactor := potRefactor - {bestRefactoring} recommendations := recommendations + {bestRefactoring} currentMetrics := bestRefactoring.metrics
The next loop (lines 13-27) finishes when the list containing the methods for potential refactoring is empty. Now, each method in the potential refactoring list is moved (line 15), the quality metrics are recalculated after moving the method (line 16), and the method returns to its original class (line 17). If the quality measurements are better than the current ones (line 18), then the method is added to our list as a candidate for refactoring (line 19).
After we measure every method, we select the one that achieved the best quality metric improvement (line 22). The best refactoring is applied to the system copy (line 23), removed from the potential refactoring list (line 24), and added to the recommendations (line 25). The new calculated metrics for the best refactoring is used to as the system baseline now (line 26).
After the execution of Algorithm 1, the sequence of Move Method refactorings is recommended to the user. The larger the number of refactorable methods, the higher the execution time. We argue that performance is not critical since our approach is designed to be performed as part of night builds.
Our calibration is related to the fitness function from Algorithm 1 (line 18). The fitness function defines how we compare the quality attributes to determinate if they are an improvement according to our requirements. Our objective is to identify the best set of requirements for the fitness to make our approach recommend better refactoring options.
We chose the JHotDraw1 software as the baseline for our calibration process. Our main reason for using JHotDraw in our calibration is due its methods are likely to be in their 1JHotDraw is a Java framework for graphic objects, and its design relies on well-known design patterns. http://www.jhotdraw.org/, verified 2017-10-22. proper classes, since it is developed and maintained by a small number of expert developers. We used version 4.6, which is composed of 674 classes, 6,533 methods, and 80,536 lines of code. For the calibration, we randomly moved 20 methods from JHotDraw to other classes. The information about these methods and classes (original and newly moved), we called Gold Set. We employ the Gold Set to verify if our algorithm recommends moving those methods back to their original place. In theory, the fitness function that recommends more methods from the Gold Set performs better.
Table IV summarizes the calibrations showing the description, the total number of recommended methods, the recommendations from the Gold Set (GS), and we also calculated precision, recall, and f-score.
In the first calibration, our criterion was the more simplistic where we verified if none of the quality attributes decreased and at least one attribute increased. We used such criteria for our fitness function. Then, we executed our algorithm to the modified JHotDraw and we got 28 methods recommended. However, only two methods belonged to the Gold Set. Therefore, we investigated why the 18 remaining methods in the Gold Set where not recommended by our algorithm. We discovered that the effectiveness value would get worse for most the Gold Set, which discarded those methods from the recommendations.
In the second calibration, since the effectiveness rarely changed in the first calibration, we adjusted the fitness function to disregard this quality attribute, while maintaining the other criteria from the first calibration. This resulted in our algorithm to recommend five methods from the Gold Set.
In the third calibration, our criterion was as simplistic as the first one where we compare the overall sum of all six quality attributes. By using this new fitness function, we managed to find 11 methods from the Gold Set but the total number of recommendations increased to 56.
In the fourth calibration, we modified the fitness function
based on the following two observations: (i) in the second
calibration, flexibility, understandability, and extensibility
improved but the remaining attributes (reusability and
functionality) decreased; and (ii) Mkaouer et al. [
In the fifth calibration, we used the following three design metrics (Table I): CAM (cohesion), DCC (coupling), and CIS (messaging). We chose these metrics because they are the QMOOD design metrics that usually change when a method is moved. We then establish the criteria for the fitness function that cohesion, coupling, and messaging cannot decrease. This calibration resulted in 45 recommended methods in which only five belonged to the Gold Set.
When we consider the f-score values, the fourth calibration achieved the best results. Recall is also very important, and # Description 1 (i) no quality attribute decreases; (ii) improve at least one attribute 2 Same as #1 but using five attributes, i.e., ignore the attribute effectiveness 3 The sum of quality attributes > the sum of the previous measured attributes 4 Same as #1 but using only flexibility, understandability, and extensibility 5 Cohesion, coupling, and messaging cannot decrease the fourth calibration also achieved the best recall result. Therefore, our fitness function uses the criteria defined by the fourth calibration, i.e., the quality attributes of flexibility, understandability, and extensibility cannot decrease and at least one of them should increase.
This section evaluates our proposed restructuring approach through QMove, a prototype plug-in for Eclipse IDE we implemented to support our proposed restructuring approach.2 We chose three open-source systems (Table V) that possess a welldefined architecture and present a similar number of classes JHotDraw does. We can assume, differently of JHotDraw, that most methods of these systems are likely to be in proper classes and hence we only evaluate recall.
Similarly to our calibration using JHotDraw, we modified the subject systems by randomly moving ten methods of each to other classes. Those methods compose our Gold Set, and our evaluation consists in verifying if Gold Set methods are recommended back to their original place by our approach. Table VI reports the evaluation results for each system, the total number of recommended methods, the recommendations from the Gold Set, and the achieved recall.
Our evaluation results shows a 57% average recall for methods in the Gold Set. This result is quite lower than the calibration, where we achieved 65% recall for the JHotDraw system (Table IV). The FreeMind and Maven systems performed closer to our calibration (60% recall for both systems). Therefore, we claim that we still need to improve the approach to achieve better results. Although our approach considerably improved the quality of these systems, we cannot guarantee similar results in low-quality systems (further work).
In this section, we highlight and discuss four studies that are closely related to our proposed restructuring approach.
Mkaouer et al. [
Moghadam and Cinne´ide [
Napoli et al. [
Griffith et al. [
In this paper, we proposed a search-based approach, to recommend Move Method refactorings based on QMOOD quality attributes. We calibrated our approach by testing five different criteria on the JHotDraw system. The best calibration achieved a f-score of 38%, which corresponds to a precision of 27% and a recall of 65%. Finally, we evaluated our approach in three open-source systems by randomly moving ten methods each. On average, our approach could move 57% of the methods back to their original class.
Future work includes: (i) fine-grained calibration strategies to increase the f-score; (ii) other evaluation metrics used for recommendation systems, such as likelihood, recall rate@k, and feedback; (iii) other types of refactorings, such as Extract Class and Extract Method; and (iv) work with normalized values of the QMOOD quality attributes.