Assess Refactoring Effects On Software Maintainability

Published Date: 02 Nov 2017

Software Maintenance is the process of modifying the software once it has been delivered which is inevitable due to many reasons such as to correct faults or to improve performance or to adapt to a changed environment. It is the most expensive phase for any software product life cycle and consumes almost 70 to 80% of time and effort. Software Maintainability is defined as the ease with which the software could be modified during maintenance phase. Refactoring is defined as the process in which the design of an object oriented software code is improved by various methods without affecting its behavior. It is an effort to improve the quality of the software either by improving design or by improving readability, and reducing bugs. Many refactoring methods have been suggested in the literature and each has a particular purpose and corresponding effect.

The objective of this empirical study is the investigation of the correlation between refactoring methods and maintainability of the code. Classification of refactoring methods is proposed based on their measurable effect on software maintainability using Object Oriented metrics proposed by Chidamber and Kemerer. Our empirical study was conducted on five real time systems who’s Object Oriented metrics are studied, calculated, evaluated and analyzed before and after application of refactoring methods. Few interesting findings were recorded that although refactoring results in corresponding increase in object oriented metrics suite and it should become more harder to maintain as per previous reports however it may not necessarily reflect in corresponding decline in maintainability on account of corresponding increase in the level of abstraction, better understandability and reusability which makes it more understandable and maintainable. Such a relationship, if identified can be utilized by the software developers to enable them in selection of refactoring methods to apply in order to optimize a software system with regard to its maintenance effort.

Keywords – Refactoring, Software Maintainability, Empirical Validation, Maintenance Efforts, Object Oriented Metrics.

1. Introduction

Software once delivered has to be evolved to accommodate enhancement, adaptation or modifications. Maintenance phase starts once the software is delivered to the customer and during this phase changes made in to software are inevitable. It not only affects developers in terms of cost and efforts associated but also determines how the customers perceived towards quality. Cost associated to maintain one line of source code is 10 times the cost of initial development of that line. Hence, software industry today strives hard to find ways and means to measure and improve "Ease of maintainability". During the maintenance phase, the code is modified many times and in this process the code quality deteriorates. Refactoring is a process in which the internal structure of the object oriented software system is improved and complexity of the code is reduced in such a way that it does not alter the external behavior of the system. The source code becomes simpler and easier to maintain as the changes made are very "Systematic" in nature. There are many methods of refactoring like dead code elimination, clone code removal, extract method, lazy classes, pull up method, push down method, hide methods, renaming etc and each method has its own effects on software quality attributes such as extensibility, modularity, reusability, complexity, maintainability and efficiency. As defined by Fowler et al. [1] in their book generally we do a good design and then code during the product life cycle, however in refactoring, we further improve the design after code has been written.

Various advantages of refactoring have been mentioned in Singh et al.[2] that it not only enhances new features but also improve understandability, readability and maintainability. During the maintenance phase we keep modifying the code and the code turns so bad that it really needs major refurbishment. Whether refactoring should be applied at this stage or not, the advantages and disadvantages of this technology really require substantial empirical investigation and in an effort to address this issue, the current study was undertaken wherein five refactoring methods on real life software were applied and their effects was observed on OO metrics which were further mapped to maintainability in an attempt to empirically validate repercussions of refactoring on maintainability. Five window and web based software systems developed in Microsoft Visual Studio (.NET) software using C# language were carefully selected. First two applications are small sized systems and later three are medium sized software. Values of OO metrics of source codes for the selected software were collected before and after refactoring method are applied. Change in values of OO metrics helped us in determining its overall effects on maintainability as there are very many studies which correlate these OO metrics to maintainability. This study would be helpful to developers and analysts as they can make some reasonable decisions regarding selection of refactoring method and corresponding improvement in maintainability. It would also guide project managers toward appropriate direction by providing help in judgment regarding what they should do and should not do.

The reminder of this paper is structured as follows: Section 2 discusses the related work already carried in this field. Section 3 describes general procedure of refactoring and selected methods in this study. Section 4 describes how to access the maintainability from internal software object oriented metrics. Section 5 describes the research methodology. Section 6 discusses threats to validity and finally section 7 concludes the paper.

2. Related Work

Term "Refactoring" was first introduced by Opdyke [3] in 1990. It is actually the process of restructuring software code in the context of object oriented paradigm. Compiled by Tom et al. [4] number of empirical studies have been conducted which investigate the effects of selected refactoring methods on various software quality attributes. Stroggylos et al. [6] have included four popular open source software systems in their study and analyzed the effect of refactoring on various software metrics. They conclude that although it is expected from refactoring process to improve quality but when it is measured through object oriented metrics on real life systems; the results are not as expected. Du Bois et al. [7] and [8] proposed the impact of refactoring on internal program quality in which they set few guidelines to be considered while refactoring the system and they observed effect of refactoring on coupling and cohesion while adhering to those guidelines. Fowler et al. [1] have specified 72 different refactoring methods in their book ranging from simple changes such as "Extract Local Variable" to more complex one such as "Extract Class". Kataoka et al. [9] studied effects of refactoring on coupling metrics in detail with an example program and compared its coupling status before and after the refactoring was applied. Moser et al. [10] strongly recommended refactoring as it improves reusability. They validated their statement through an empirical study in an XP-like development environment. Geppert et al. [11] empirically investigated the impact of refactoring on changeability while considering three factors: customer reported defect rates, effort, and scope of changes. Wilking et al.[12] also did an empirical study to evaluate the effects of refactoring on maintainability and modifiability. Although, few studies in part have not directly evaluated the effects of each refactoring method separately on internal or external software quality attributes nonetheless their cumulative effects have been discussed. Xing et al. [13] have discussed most frequent types of refactoring and high-level design requirements which are mandatory for refactoring process using Eclipse as their case study. There have been so far no reports to undertake organized study which classify various commonly used refactoring methods along with their corresponding effects on software object oriented metrics. The current study is designed to address this issue for the benefit of all.

3. General Procedure of Refactoring

During the refactoring process either we move a piece of source code from one place in the system to another, we change a method signature, sometimes change the class structure and sometimes just rename the existing elements. Despite the automated refactoring support provided by today's IDEs, refactoring is not easy as it seems. Although refactoring can be made easier with many available tools but over reliance can be Risky. Gastavo et al. [14] have shown in their study that when typical "pull-up method" refactoring was applied in Eclipse tool, it can even sometimes introduce errors. Refactoring is tedious and error prone process and few guidelines are also given in their paper to make it safer. A good search and replace utility usually helps, but cannot catch everything. Newer IDEs and editors have sophisticated commands for specific refactoring operations but it is the developer’s duty to search through all the other code and make corresponding changes to make refactoring process safer. Developer should run automated regression tests before and after a refactoring session. In general the steps undertaken during the refactoring process are shown in the Figure 1.

Figure 1. The Process of Refactoring

4. Roadmap to Measure Software Maintainability using Software object oriented Metrics

Software object oriented metrics suite are used to measures the structural quality of a code. Although there are several metrics proposed in literature to measure the maintainability of the object oriented software, OO metrics suite proposed by Chidamber and Kemerer (C&K) in 1991 [15] became quite popular among researchers and further referred by many researchers and practitioners to evaluate analytically. Several studies were conducted for its validation and many empirical studies [16-27] used this metric suite to access the software maintainability of the given code. Besili et al. [16] presented results of empirical validations on C & K Metrics and found first 5 metrics as good quality indicators. Tang et al. [17] validated C & K metrics on real time systems. Li [18] validated C & K metrics theoretically as per the framework proposed by Kitchenhem et al.[19] and added few more metrics. From 2000 to 2010 many researchers Thwin and Quah[20], KK Aggarwal et al.[21], Koten and Gray [22], Zhou et al.[23], Elish et al.[24] and Kaur et al.[25] , KK Aggarwal et al.[26] and Y Singh et al. [27] have empirically verified C&K set of metrics and verified their correlation with the maintainability. They have used a combination of metrics suite proposed by C & K [15] and Li Henry [18].

The formal definition of C & K metrics suites are given below.

Weighted Methods per Class (WMC): It is defined as the sum of McCabe’s cyclomatic complexities of all local methods defined in a class. It is always advisable to have its value as much less as possible. More methods if packed in one class would obviously reduce its reuse and the class becomes more complex which in turn increases maintainability.

Depth of Inheritance Tree (DIT): It measures the maximum inheritance path from the class to the root class. As we increase depth by implementing inheritance in our code, it increases reusability and maintainability but beyond certain depth, code becomes very complex and harder to maintain as suggested by Daly et al.[28].

Number of children (NOC): NOC equals the number of immediate child classes derived from a base class. NOC measures the breadth of a class hierarchy. Depth which is measured by DIT is generally better than breadth, since it promotes reuse of methods through inheritance. NOC and DIT are closely related. Inheritance levels can be added to increase the depth and reduce the breadth.

Coupling Between Objects (CBO): It measure the number of classes to which a given class is coupled. Two classes are coupled when methods declared in one class uses methods or instance variables defined in other class. For a good maintainable system CBO should be kept low. Godin and Miceli [29] suggested a maximum CBO value to be less than 14 as increased value means there is very high coupling between the classes which would have negative impact on maintainability. Excessive coupled classes also prevent reuse of existing components and they are damaging for a modular, encapsulated software design.

Response for a Class (RFC): It is defined as the number of methods that can potentially be executed in response to a message being received by an object of that class. Its value should be kept as low as possible to keep the system maintainable. Li and Henry [18] stated that one may intuit that larger the RFC, harder to maintain the class since calling a large number of methods in response to a message makes tracing an error extremely difficult and so the maintenance process.

Lack of Cohesion of Methods LCOM: The 6th metric in the Chidamber & Kemerer metrics suite is LCOM (or LOCOM), the lack of cohesion of methods which actually measures the cohesiveness present in class. LCOM is the number of disjoint sets of local methods in a class. More cohesive class would be easier to maintain and as stated by Li and Henry[18] the larger value of LCOM makes the class harder to maintain.

There are many quality attributes given in ISO 9126 Quality Model [30] such as Functionality, Reliability, Usability, Efficiency, Maintainability and Portability. This study is primarily related with "maintainability". Roadmap is presented to measure maintainability from C & K metric suite in figure 2. These OO metrics are measured before refactoring is applied on selected software system code. These OO metrics are collected again after the selected refactoring method is applied. This enables us to observe the change in the OO metrics which is due to the application of specific refactoring method. At a given time only one refactoring method is applied and its effects were observed. The process is repeated each time for all the selected refactoring methods in this study.

Figure 2. Roadmap to measure maintainability from Chidamber and Kemerer metric suite

5. Research Methodology

This section discusses the research method adopted to investigate the effect of few selected refactoring method on software maintainability. We present refactoring methods selected in this study, detailed description of the software code undertaken for empirical investigation, data collection method, effects of refactoring on C & K metrics suite and remarkable observations and discussion.

5.1 Selection of Refactoring Methods.

Fowler et al.[1] have defined more than 70 methods of refactoring along with motivation behind each one. Few are very simple in nature such as renaming; code extraction or pull-up methods where as few are very complex such as exchanging risky long language idioms with safer alternatives or the code optimization. Very meticulously Fowler in his book has specified each and every method and its step-by-step description examples along with why and how it should be done. As an initial set of experiment we have chosen five refactoring methods. Very primitive methods such as renaming etc have been intentionally avoided since they do not have any significant impact on C&K metrics suite and we will not be able to ascertain its effects on maintainability. We have carefully chosen those refactoring methods which either redistributes the responsibilities within classes or those which operate at methods level. Our criteria is also influenced by the fact that tool being used must possess those automated refactoring methods. The following are the five methods chosen and examples are taken from [31] :

Consolidate Conditional Expression: This refactoring method combines sequence of conditional tests with the same result into a single conditional expression and then extracts it.

double Pension Amount() {

if ( Age < 60 ) return 0;

if (_Is_Disabled > 12) return 0;

if (_sex = "Male" ) return 0;

// compute the pension amount given to female who is not disabled in current year and age > 60

double Pension Amount() {

if(isNotEligableForPension())

return 0;

Encapsulate Field: Data hiding is the general principal of Object oriented programming. To implement this encapsulates public field by making it private and provides accessors (getter and setter methods) to it.

public String student_name

private String student_name;

public String getStudentName() {return Student_name;}

public void setStudentName(String arg) {Student_name = arg;}

Extract Class: If the existing class becomes too complex, creates a new class and moves the relevant fields and methods from the source class into the new class.

Student

Name

Enrollment_number

getMobileNumber

MobileNumber

MobilePhone_Parents

MobilePhone_self

getMobileNumber

Student

Name

Enrollment_number

MobilePhone_Parents

MobilePhone_self

getMobileNumber

1

Extract Method: If there is a piece of code fragment that can be grouped together, then extracts those groups of statements and put them into a new method. Finish you task by giving some sensible name to newly created method which explains its purpose.

void printStudentDetails() {

System.out.println("name:"+ student_name);

System.out.println ("Grades physics" + getGradesPhysics());

System.out.println ("Grades chemistry" + getGradesChemistry());

System.out.println ("Grades Maths" + getGradesMaths());

}

void printOwing() {

void printStudentDetails() {

System.out.println ("name: " + _name);

printDetailGrades();

}

void printDetailGrades()

{

System.out.println ("Grades physics" + getGradesPhysics());

System.out.println ("Grades chemistry" + getGradesChemistry());

System.out.println ("Grades Maths" + getGradesMaths());

}

Hide Method: If a method is not used by any other class then change the visibility of a method and make the method private.

Student

-ReadStudent

Student

+ReadStudent

5.2 Software Background

We undertook the project with the very aim to determine the effect of refactoring on the simple software system codes written by students in JAVA and also on more complex system software codes written by professional in C#. We do this with intend to accommodate beginners as well as professional. Two software system codes were chosen from the projects undertaken by the student of B.Tech 5th Semester of Guru Gobind Singh Indraprastha University. They were learning and doing preliminary work on JAVA. Three customized software system are also used in this study which are developed by professionals. The details are given below.

Table 1. The Details of software code used in empirical study

S. No.

Type of project

Project Name

Platform

Language used

Line of Code

Number of module

Description

1

Basic Course Project

FLMS

Web Based Application

.net

1484

34

File Letter Monitoring System is a web application which monitors the file/letter movement in an office or organization

2

Basic Course Project

EASY classes Online services

Web Based Application

.net

2070

58

It is a web portal for an Educational Institute in Delhi. It provides study material online for students in two ways.

3

Customized Project

SMS

Windows based Application

C#

5132

27

Student management system is a windows based application which maintains the record of students & teacher for private educational institute.

4

Customized Project

IM System

Windows based Application

C#

2941

8

Inventory Management System is a windows based application which maintains inventory of company at different branch offices in different cities and product names & record can be appended itself by the users.

5

Customized Project

ABILL

Windows based Application

C#

2070

10

Angel Bill printing software is a window based application in which after adding information which can maintain fully editable items list by client itself with generation of a common bill format.

5.3 Data Collection

The methodology adopted for the current study is reflected in Figure 4. First job was the identification of the "bed smell" in the code where refactoring could be helpful and corresponding selection of refactoring method as suggested by Fowler [1]. C & K metrics of the code were collected before applying the particular refactoring method. In the next process, refactoring was applied and values of C & K metrics were collected again. Change in the values of each and every metric corresponding to particular refactoring method was prepared. Finally changes in the values of metrics were mapped to their corresponding effects on maintainability using the results of study conducted by Li and Henry [18].

Figure 3. The Process of Data Collection before and after Refactoring

5.4 Effect of Refactoring on Object oriented (C&K) Metrics

The changes in the values of internal OO metrics after applying the refactoring method from all case studies chosen as part of this project have been summarized in Table 2. Further, the effects of selected refactoring methods on OO metrics were analyzed one by one along with their cumulative effects on maintainability which are briefly given below:

5.4.1 Consolidated Conditional Expression: Many lines of code are merged into a single statement which reduces value of LOC. However WMC and RFC increase due to an additional method being added in the same class. This newly added method accesses existing instances of data member which results in reduction of LCOM value.

5.4.2 Encapsulating Field: Public data members are converted to private and two additional methods are created to access the values of data. Values of WMC and RFC increased which is attributed to two newly created methods (to get and set the value). There were no change in the values of CBO, NOC and DIT as no new class was introduced. LCOM value reduces as these newly created accessors uses the same instances of variable. Line of code (LOC) also increases due to newly created methods to get and set the values of private members.

5.4.3 Extract Method: It increase WMC and RFC values and decrease LCOM value because new methods are extracted from existing methods in the class with an aim to increase understandability of the code. However there is no effect on CBO, DIT and NOC values as no new class was created.

5.4.4 Extract Class: It increases DIT, CBO and NOC value as a new class is created which moves the relevant field and method from a source class into a new class. However RFC, WMC and LOC value reduces because the code common to few classes was moved upward with an endeavor to achieve reusability. Further it increases the coupling between the classes as the extracted class and source class share same data. It is also one of the reasons due to which value of CBO increases.

5.4.5 Hide Method: There is no change recorded on the value of internal OO metric when this refactoring method was applied. It is so because this process does not redistributes’ responsibilities assign to any class and only the visibility of one method was converted from public to private………………..

Table 2. Selected Refactoring Methods and their effects on C & K Metrics Suite

Refactoring Methods

WMC

DIT

NOC

CBO

RFC

LCOM

LOC

Encapsulate Field

Increase

No change

No change

No change

Increase

Increase

Increase

Extract Method

Increase

No change

No change

No change

Increase

Increase

Increase

Hide Method

No change

No change

No change

No change

No change

No change

No change

Consolidate Conditional Expression

Increase

No change

No change

No change

Increase

Decrease

Decrease

Extract Class

Decrease

Increase

Increase

Increase

Decrease

Decrease

Increase

5.6 Discussion

To establish the relationship between C & K metrics and maintainability we totally rely on study of Li and Henry [18]. We study the overall effect of refactoring on OO metrics and further map it to maintainability using the findings of Li and Henry [18]. This study leads us to many interesting inferences mentioned as follows:

First, we discuss the effect of two refactoring method "Encapsulating field" and "Extract Method". It increases WMC, LOC, RFC and LCOM since new method is created in the class. There is no change on DIT, NOC and CBO as we have not introduced any new class. As per the findings of Li and Henry [18], if there is any increase in the values of WMC, LOC, RFC and LCOM, overall maintainability of the code would be reduced. Stroggylos and Spinellis [6] also recorded the similar findings that if we add any method in to a class this in turn add responsibilities to the class and it becomes more complex and harder to maintain. Newly created method also uses the same instances of data members, present in the class therefore the reduction in the value of LCOM is observed which in turn reduces maintainability. In the current study similar findings were recorded with regard to enhance effects on OO metrics however it may not necessarily reflect in corresponding decline in maintainability as the level of abstraction also increases which in turn contributes towards augmented understandability and overall maintainability. The positive effects of "understandability due to abstraction" are much more than the negative effects of these metrics values which suggest final increase in maintainability. This can be understood by beautiful example of house, although walls made in the house consumes space but it clearly separate each room and overall house becomes more organized.

Second, refactoring method applied was "Extract Class". This refactoring method reduces the line of code (LOC) since relevant fields of the class are extracted in to a new class. Drastic decrease in the values of WMC was observed as methods of the source class were moved to extracted class. Values of DIT, NOC and CBO are increases due to additional new classes. As per the findings of Li and Henry [18], maintainability should be reduced however on the contrary, despite increase in DIT, NOC and CBO values our findings were that overall code becomes easier to maintain on account of reduction in WMC and increased reusability. Interestingly reusability has been closely associated with maintainability as suggested by [32]

Third observation that "Hide Method does not affect any OO metric" was in full agreement with Elish and Alshayeb [33] since it only changes the visibility of the method from public to private if that method is not used by any other class. This refactoring process neither alters the structural design nor do amends responsibilities assign to any class. Notwithstanding the above refactoring process is an important consideration to ensure that codes adhere to the principles of Object Orientation.

Last and very interesting observation is that decision should not be on the basis of change in the values of metrics, instead while calculating the final impact on maintainability, all metrics along with other quality attributes such as understandability and reusability should be given enough weight age and based upon cumulative effects of all factors final impact on maintenances should be calculated. Programmers cannot blindly apply refactoring each and every day; instead enough time should be given to calculate pros and cons achieved by refactoring process and final call should be adopted.

6. Threats to Validity

There are a few threats to validity of this study that should be taken into consideration while interpreting the results. Some of these limitations are very common whenever any empirical study is conducted and hence not uniquely attributable to this study. However, for the sake of completeness we have mentioned them all as follows:

The results obtained in this study are based on the data obtained from real life applications which have specific characteristics and behavior therefore cannot be generalized. Based on the empirical investigations in previous studies [16-27] it is assumed that metrics selected in this study have statistically significant relationship with maintainability. Such statistical methods provide only empirical evidence of relationships however experiments where certain measures can be varied in a controlled manner while keeping the others constant, could actually demonstrate the real time scenario. As usual however, it is difficult to undertake such controlled experiments in reality. It should be noted that only code developed in C# was considered in the current study with an assumption that the conclusions derived from using this code are valid for object-oriented methodologies. However, further research is required to be undertaken to verify this scheme on other object oriented languages such as Java.

There are many psychological factors also which affect maintainability which have not been considered in this study as it is not feasible to quantify them such as varying level of expertise of developers, different standards in which application is developed, number of active developers involved, development history of the systems and familiarity of the system with the persons involved in maintenance. It is further reiterated that this study only provides probable indications of the effect of different design measures on maintainability. In this study since it was not possible to consider all factors that effect maintainability in one model, the results obtained here deserves to be verified as part of future work, using the other models which consider other aspects as well.

7. Conclusion and Future Direction

The effects of refactoring on maintainability have been investigated in the current study. In the process, a customized source code has been used to perform refactoring process using automated tool. Various values of OO metrics of the code were calculated before and after refactoring process. In order to map refactoring process to maintainability, various studies done by researchers to map the relationship of OO metrics to maintainability has been used. In this work five systems in order to analyze the effect of refactoring on maintainability of the software have been used. The following results have been obtained while analyzing the effect of refactoring on various factors of maintainability represented in the form of OO metrics:

The software practitioners and researchers can use the guidelines and results obtained from this study while making the decisions regarding selection of refactoring methods. In all the studies available in literature, usually researchers have applied one refactoring method at a time and observed its effect. A possible future direction would be to investigate two or more refactoring at a time and observe its collective effects on various quality attributes. The task becomes more challenging if the refactoring methods are conflicting in nature, for example "Pull Up Method" increases reusability and maintainability but at the cost of augmented testing efforts. Analyzing their cumulative effects on software quality would be adventurous.