6.2 Searching for Refactoring Opportunities
6.2.3 Example
This section illustrates the search for refactoring opportunities through an example.
The source code of of the My SQL Connector J are used to search for refactoring oppor-tunities. This software application is a native Java driver, which converts JDBC calls to native MySQL calls (MYSQL, 2009). The model of Version5.0contains200classes and the respective source code has40.000lines of code.
The search is conducted for opportunities to apply theExtract Sub-Class refactoring pattern and discuss opportunities found for the Extract Class refactoring pattern while doing the search for opportunities for anExtract Sub-Classapplication. A subset of the possible scenarios in which the Extract Sub-Class refactoring pattern can be applied is evaluated. In the example, the extraction of2/3, 1/2, 1/3and 1/10of the methods to a new subclass are evaluated.
For this evaluation, the metric values for all the classes and subsequently the heuristic rule values are computed. For each class and each of the chosen scenarios, impact func-tions were applied to compute the predicted values of the heuristic rule in the My SQL Connector J models. Using the values one can see how the heuristic rule values change and which of the refactoring opportunities are more interesting that the others.
6.2.3.1 A Heuristic Rule for Simplicity and Reusability
This section shows an example of a heuristic rule definition, including the following activities: selecting quality attributes, selecting metrics, defining the heuristic rule and selecting the weights.
Selecting Quality Attributes.
First, the developer chooses the set of required quality attributes. The set of qual-ity attributes depends on the software process, the project and the problem domain. For example, in embedded systems, memory is an important attribute, while in real-time tems, the timing constraint is the most important quality attribute. In other kinds of sys-tems, such as information systems the main quality attributes can be reusability, usability and portability. The example uses simplicity and reusability to illustrate the approach, as both quality attributes are easy to understand and can be computed using traditional object-oriented complexity metrics.
Selecting Metrics.
Tsang et al. (TSANG; CLARKE; BANIASSAD, 2004) consider that reusability is the combination of weighted methods per class, depth of inheritance tree, number of children, coupling between objects, and lack of cohesion of methods. Fenton (FENTON;
PFLEEGER, 1997) suggests the use of Chidamber and Kemerer metrics (CHIDAMBER;
KEMERER, 1994) as indicators of software simplicity. This example uses three metrics to evaluatereusabilityandsimplicity:
• WMC.The weighted methods per class (wmc) metric counts the number of opera-tions in a given class (CHIDAMBER; KEMERER, 1994).
• DIT.The value fordepth of inheritance tree(dit) is given by the longest path from a module to the class hierarchy root (CHIDAMBER; KEMERER, 1994).
• NOC.Thenumber of children(noc) represents the number of direct sub-classes for a given class (CHIDAMBER; KEMERER, 1994).
Defining the Heuristic Rule.
The heuristic rule to be defined as example deals only with the metrics related to simplicity and reusability and can be defined as an aggregation function. To illustrate the process the weights0.4for simplicity and0.6to reusability were chosen for the heuristic rule, as follows:
f(x) = 0.4∗simplicity(x) + 0.6∗reusability(x) (6.1) The heuristic rule was normalised to return values in the [0,1] interval. The follow-ing set of assumptions was considered to define the heuristic rule used to illustrate the instantiation process:
• The smaller the values for wmc, ditand noc, the simpler is the design. This is in accordance with the view of Chidamber and Kemerer (CHIDAMBER; KEMERER, 1994) that states that the greater thenocvalue, the greater the likelihood of improper abstraction of the parent class.
• The higher the values for ditandnocgreater the reuse, since inheritance is a form or reuse (CHIDAMBER; KEMERER, 1994). The more operations a class has, the less reusable it is (CHIDAMBER; KEMERER, 1994). Therefore, high values of wmccontribute to decrease reuse.
The simplicity and reusability functions are defined as a sum of products between the weights and the metrics. To normalize the values of each metric, the values are divided by the maximum value for this metric in the evaluated software application, denoted as m(µ), whereµis the metric andmis the function that computes a maximum determinated value for this metric:
simplicity(x) = cw1∗(1−wmc(x)/m(wmc(x))) + cw2∗(1−dit(x)/m(dit(x))) + cw3∗(1−noc(x)/m(noc(x))) reusability(x) = rw1∗(1−wmc(x)/m(wmc(x))) +
rw2∗(dit(x)/m(dit(x))) + rw3∗(noc(x)/m(noc(x))) Selecting the Weights.
This section uses the Analytical Hierarchy Process (AHP) (SAATY, 1990) to select the weights for the heuristic rule components. AHP focuses on finding an optimal so-lution using qualitative and quantitative decision analysis. The approach uses a set of pairwise comparisons to describe the relationship between two criteria and convert these comparisons to a weights vector.
For reusability, the following pairwise comparisons are used:
• ditisslightly more importantthanwmc;
• ditandnochave thesame importance;
• nocisslightly more importantthanwmc.
Using the AHP approach to convert these pairwise comparisons to numerical values, the developer obtains the following weights vector: Vr =h0.2 0.4 0.4i. The reusability function can then be expressed as:
reusability(x) = 0.2∗(1−wmc(x)/m(wmc(x))) + 0.4∗(dit(x)/m(dit(x))) +
0.4∗(noc(x)/m(noc(x)))
The pairwise comparisons for simplicity are: (i)wmcisweakly more importantthan ditand thannocand (ii)ditisslightly more importantthannoc;
Converting these pairwise comparisons to a weights vector using AHP, gives the fol-lowing vector for the simplicity quality attribute: Vc0 = h0.5936 0.2493 0.1571i. The simplicity function can then be defined as:
simplicity(x) = 0.60∗(1−wmc(x)/m(wmc(x))) + 0.25∗(1−dit(x)/m(dit(x))) + 0.15∗(1−noc(x)/m(noc(x))) 6.2.3.2 Overview of the Refactoring Opportunities
The heuristic rule values before the refactoring and the heuristic rule values after the application of theExtract Sub-Classrefactoring pattern are compared. Figure 6.2 shows the values of the heuristic rule for the following functions: the original heuristic rule, the value of the heuristic rule if 2/3, 1/2, 1/3 and 1/10 of the methods of each class are extracted to a new class. Note that the x-axis represents each class occurrence and the y-axis is the value of the heuristic rule for that particular class.
0.2 0.3 0.4 0.5 0.6 0.7
0 50 100 150 200
Heuristic Function 2/3 of methods extracted 1/2 of methods extracted 1/3 of methods extracted 1/10 of methods extracted
Figure 6.2: Examples of values for the heuristic rule if a subclass is extracted. The x-axis represents each class occurrence and the y-axis is the value of the heuristic rule.
Note that the differences of applying the Extract Sub-Class refactoring pattern are higher for those classes with a low heuristic rule value. These classes can be seen as the ones with the worst values for the heuristic rule. The more methods are extracted to the new subclass, the lower are the values for the heuristic rule of the original class (as shown in Figure 6.2).
In the next step, the refactoring opportunities are prioritised and the application of refactoring patterns is suggested. A threshold can be defined to choose how many classes will be inspected and analysed. One possible strategy is to inspect the classes in which the difference in the heuristic rule values before and after the application of refactoring patterns is higher.
6.2.3.3 Analysing Trade-offs and Prioritising Refactoring Opportunities
The ten top ranked classes are analysed in two ordered rankings: (a) a ranking con-taining the classes with the lowest heuristic rule values and (b) a ranking with the classes with the biggest differences in the heuristic rule values (before and after the application of the refactoring pattern).
Table 6.1 shows the ten classes with the worst values for the heuristic rule and Table 6.2 shows the ten classes with the larger difference between the values of the heuristic rule before and after a possible application of theExtract Sub-Classrefactoring pattern.
The developer can follow both lists in order to apply the refactoring patterns.
Table 6.1: Classes ordered by the values of the heuristic rule
Class wmc dit noc H. Rule Value
Connection 313 1 0 0.19
ConnectionProperties 305 0 5 0.20
ResultSet 246 0 1 0.24
DatabaseMetaData 211 0 1 0.28
UltraDevWorkAround 154 0 0 0.34
CallableStatement 128 2 0 0.43
MysqlIO 69 0 0 0.44
Statement 66 0 1 0.45
PreparedStatement 89 1 2 0.46
UpdatableResultSet 79 1 0 0.46
Figure 6.3 is a zoom in Figure 6.2, showing only the differences in the heuristic rule values for the first ten classes.
0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6
0 2 4 6 8 10
Heuristic Function 2/3 of methods extracted 1/2 of methods extracted 1/3 of methods extracted 1/10 of methods extracted
Figure 6.3: Examples of values for the heuristic rule if a sub class is extracted. The x-axis represents each class occurrence and the y-axis is the value of the heuristic rule.
Table 6.2: Classes ordered in a descendent way by the difference between the value of the heuristic rule before and after the application of refactoring patterns
∆ changes in the heuristic rule values extracting x% of the methods
Class H. Rule Value x=2/3 x=1/2 x=1/3 x=1/10
Connection 0.19 126% 95% 63% 21%
ConnectionProperties 0.20 120% 90% 60% 20%
ResultSet 0.24 79% 63% 42% 13%
DatabaseMetaData 0.28 61% 46% 32% 11%
UltraDevWorkAround 0.34 35% 26% 18% 6%
CallableStatement 0.43 23% 19% 12% 5%
StatementRegressionTest 0.50 14% 11% 7% 2%
PreparedStatement 0.46 13% 9% 7% 2%
ResultSetRegressionTest 0.51 15% 13% 9% 4%
CallableStatementWrapper 0.51 15% 11% 9% 2%
In the analysed tables, the first six classes are the same in both tables: Connec-tion, ConnectionProperties, ResultSet, DatabaseMetaData, UltraDevWorkAround and CallableStatement. Other classes, such as MysqlIO, Statement and UpdatableResultSet appear as having low values for the heuristic rule. Although they do not appear in the top ten differences when applying theExtract Sub-Classrefactoring pattern, these classes can also be restructured by the application of refactoring patterns, improving their heuristic rule values. The StatementRegressionTest, ResultSetRegressionTest and CallableState-mentWrapperappear in the ten most benefited classes from the application of refactoring patterns in the list. Also, thePreparedStatementclass appear in the two lists.
Note that the refactoring opportunities with the higher potential to improve the se-lected quality attributes are those that improve the heuristic rule values most. In Table 6.2, the opportunities that bring the higher improvements are those focusing the extrac-tion of lots of methods and those applied to classes with a low value for the heuristic rule.
6.2.3.4 Inspecting the Top Ranked Refactoring Opportunities
Next, these classes are examined, looking for methods to be extracted to a new sub-class. Large classes usually encapsulate more than one concern. Breaking the class into two or more classes can be advantageous in this case. Consider, for example the Con-nectionclass. It has the worst value for the heuristic rule and can have its metric values improved from the application ofExtract Sub-Class.
Analysing this class, the developer can see that there is an inner class, named Ultra-DevWorkAround that has 154 methods. Extracting this class can improve the heuristic rule value. Note that when evaluating refactoring opportunities for theExtract Sub-Class pattern, sometimes the developer finds opportunities to applyExtract Class instead. In this case, it is useful to extract the inner class andpromoteit to a standalone class.
The second class detected as an opportunity for Extract Sub-Class is the Connec-tionProperties class. When looking at the class diagram, the first thing to note is that this class has inner classes. Figure 6.4 shows the class with the attributes and methods compartments hidden to better visualize both the inner classes and two of its sub classes:
PropertiesDocGeneratorandDocsConnectionPropsHelper.
Figure 6.4: Class diagram for theConnectionPropertiesclass and some of its subclasses In this case, several refactoring opportunities appear, not only to extract a class (or sub-class). Also, the dependency betweenConnectionPropertiesand the selected subclasses is very weak. The subclasses have only amainmethod and can be further inspected. As the source code of both classes is available, thePropertiesDocGeneratorclass is inspected:
1 p u b l i c c l a s s P r o p e r t i e s D o c G e n e r a t o r 2 e x t e n d s C o n n e c t i o n P r o p e r t i e s {
3 p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s) 4 t h r o w s S Q L E x c e p t i o n {
5 S y s t e m . o u t . p r i n t l n (new
6 P r o p e r t i e s D o c G e n e r a t o r ( ) . exposeAsXml ( ) ) ;
7 }
8 }
This class does not need to extend the ConnectionPropertiesclass. The inheritance dependency can be removed and an instance of the ConnectionProperties class can be created directly (instead of an instance ofPropertiesDocGenerator).
The inspection of DocsConnectionPropsHelper class and PropertiesDocGenerator classes shows that they are equal, except for its name. None of them are being used by other classes and they can be both deleted.
Also, the inner classes are quite large and can be extracted to new classes. This can reduce the size of the ConnectionPropertiesclass and reduce its complexity. Note that when one refactoring opportunity is found, other refactoring opportunities can be discov-ered by the developer by inspecting the models and the source code artefacts (if available).
The application of a refactoring pattern can create new classes (as occurs with theExtract Sub-Classpattern). The heuristic rule can be adapted to consider the number of classes as a metric to the expected quality attributes.
6.2.3.5 Applying Refactoring Patterns and Evaluating the Changes
A set ofExtract ClassandExtract Sub-Classrefactoring patterns was applied in two of the classes in the initial list of refactoring opportunities. Table 6.3 shows the differences in the heuristic rule value for the two classes. In this case, the heuristic values in the Connectionclass improved in 94.74%, according to the new heuristic rule value. For the ConnectionPropertiesclass the improvement is around 20%.
Table 6.3: The heuristic rule values after the application ofExtract Class/Sub-Class
Class before after ∆
Connection 0.19 0.37 +94.74%
ConnectionProperties 0.20 0.24 +20%
Note also that two classes were deleted (DocsConnectionPropsHelper and Proper-tiesDocGenerator) and five new classes were created. Table 6.4 shows the values for the metrics and the heuristic rule values for the new classes. These new classes do not have low values for the heuristic rules and are not in the top of the ranking when created.
The focus must continue on those refactoring opportunities with low heuristic rule values.
Opportunities for applying the refactoring patternsExtract ClassandExtract Subclassin these new classes can be computed and they can enter in the ranking of refactoring oppor-tunities regarding the difference between the values before and after a given refactoring pattern is applied.
Table 6.4: Metric and heuristic rule values for new classes
Class wmc dit noc heuristic rule
(+) ConnectionProperty 20 0 3 0.51
(+) BooleanConnectionProperty 7 1 0 0.54
(+) IntegerConnectionProperty 10 1 1 0.54
(+) MemorySizeConnectionProperty 3 2 0 0.57
(+) StringConnectionProperty 7 1 0 0.54
In those classes, the heuristic rule value of the original classes has improved. Two classes were deleted and five new classes were extracted from theConnectionProperties class. The new classes have good values for the heuristic rule (comparing with the ones in the refactoring opportunities lists). The approach is iterative, whenever the developer applies refactoring patterns to some classes, the heuristic rules can be automatically re-calculated and a new ranking of refactoring opportunities computed.
It is interesting to emphasize that, this example focuses on theExtract Sub-Classonly, but other refactoring patterns were also applied to the classes (Extract Classand Delete Class). When more refactoring patterns are analysed, the number of refactoring oppor-tunities increases and the rankings can help the developer to consider the most critical classes, instead of looking for all possible application of refactoring patterns. The use of the proposed mechanisms to automatically find the refactoring opportunities that are more suitable to the quality attributes he is interested is of great value. Additional heuristic rules can be used to evaluate the overall improvement of the application ofExtract Class.