C. Le Goues and S. Yoo (Eds.): SSBSE 2014, LNCS 8636, pp. 168–183, 2014. © Springer International Publishing Switzerland 2014 A Robust Multi-objective Approach for Software Refactoring under Uncertainty Mohamed Wiem Mkaouer 1 , Marouane Kessentini 1 , Slim Bechikh 1 , and Mel Ó Cinnéide 2 1 University of Michigan, MI, USA firstname@umich.edu 2 Lero, University College Dublin, Ireland mel.ocinneide@ucd.ie Abstract. Refactoring large systems involves several sources of uncertainty re- lated to the severity levels of code smells to be corrected and the importance of the classes in which the smells are located. Due to the dynamic nature of soft- ware development, these values cannot be accurately determined in practice, leading to refactoring sequences that lack robustness. To address this problem, we introduced a multi-objective robust model, based on NSGA-II, for the soft- ware refactoring problem that tries to find the best trade-off between quality and robustness. We evaluated our approach using six open source systems and demonstrated that it is significantly better than state-of-the-art refactoring ap- proaches in terms of robustness in 100% of experiments based on a variety of real-world scenarios. Our suggested refactoring solutions were found to be comparable in terms of quality to those suggested by existing approaches and to carry an acceptable robustness price. Our results also revealed an interesting feature about the trade-off between quality and robustness that demonstrates the practical value of taking robustness into account in software refactoring. 1 Introduction Large-scale software systems exhibit high complexity and become difficult to maintain. It has been reported that the cost of maintenance and evolution activities comprises more than 80% of total software costs. In addition, it has been shown that software maintainers spend around 60% of their time in understanding the code. To facilitate maintenance tasks, one of the widely used techniques is refactoring which improves design structure while preserving the overall functionality of the software [12]. There has been much work on different techniques and tools for refactoring [12], [23], [21], [9]. The vast majority of these techniques identify key symptoms that cha- racterize the code to refactor using a combination of quantitative, structural, and/or lexical information and then propose different possible refactoring solutions, for each identified segment of code. In order to find out which parts of the source code need to be refactored, most of the existing work relies on the notion of design defects or code smells. Originally coined by Fowler [12], the generic term code smell refers to struc- tures in the code that suggest the possibility of refactoring. Once code smells have been identified, refactorings need to be proposed to resolve them. Several automated