Zéphyrin Soh

On the use of developers context for automatic refactoring of software anti-patterns

A novel automated refactoring approach that takes into account task context.A large scale case study showing the effectiveness of the proposed approach in two scenarios: root-canal and floss refactoring.Evaluation of the design quality of refactored solutions using a state-of-the-art quality model QMOOD. Anti-patterns are poor solutions to design problems that make software systems hard to understand and extend. Entities involved in anti-patterns are reported to be consistently related to high change and fault rates. Refactorings, which are behavior preserving changes are often performed to remove anti-patterns from software systems. Developers are advised to interleave refactoring activities with their regular coding tasks to remove anti-patterns, and consequently improve software design quality. However, because the number of anti-patterns in a software system can be very large, and their interactions can require a solution in a set of conflicting objectives, the process of manual refactoring can be overwhelming. To automate this process, previous works have modeled anti-patterns refactoring as a batch process where a program provides a solution for the total number of classes in a system, and the developer has to examine a long list of refactorings, which is not feasible in most situations. Moreover, these proposed solutions often require that developers modify classes on which they never worked before (i.e., classes on which they have little or no knowledge). To improve on these limitations, this paper proposes an automated refactoring approach, ReCon (Refactoring approach based on task Context), that leverages information about a developers task (i.e., the list of code entities relevant to the developers task) and metaheuristics techniques to compute the best sequence of refactorings that affects only entities in the developers context. We mine 1705 task contexts (collected using the Eclipse plug-in Mylyn) and 1013 code snapshots from three open-source software projects (Mylyn, PDE, Eclipse Platform) to assess the performance of our proposed approach. Results show that ReCon can remove more than 50% of anti-patterns in a software system, using fewer resources than the traditional approaches from the literature.

On the effect of program exploration on maintenance tasks

When developers perform a maintenance task, they follow an exploration strategy (ES) that is characterised by how they navigate through the program entities. Studying ES can help to assess how developers understand a program and perform a change task. Various factors could influence how developers explore a program and the way in which they explore a program may affect their performance for a certain task. In this paper, we investigate the ES followed by developers during maintenance tasks and assess the impact of these ES on the duration and effort spent by developers on the tasks. We want to know if developers frequently revisit one (or a set) of program entities (referenced exploration), or if they visit program entities with almost the same frequency (unreferenced exploration) when performing a maintenance task. We mine 1,705 Mylyn interaction histories (IH) from four open-source projects (ECF, Mylyn, PDE, and Eclipse Platform) and perform a user study to verify if both referenced exploration (RE) and unreferenced exploration (UE) were followed by some developers. Using the Gini inequality index on the number of revisits of program entities, we automatically classify interaction histories as RE and UE and perform an empirical study to measure the effect of program exploration on the task duration and effort. We report that, although a UE may require more exploration effort than a RE, a UE is on average 12.30% less time consuming than a RE.

Noise in Mylyn interaction traces and its impact on developers and recommendation systems

Interaction traces (ITs) are developers’ logs collected while developers maintain or evolve software systems. Researchers use ITs to study developers’ editing styles and recommend relevant program entities when developers perform changes on source code. However, when using ITs, they make assumptions that may not necessarily be true. This article assesses the extent to which researchers’ assumptions are true and examines noise in ITs. It also investigates the impact of noise on previous studies. This article describes a quasi-experiment collecting both Mylyn ITs and video-screen captures while 15 participants performed four realistic software maintenance tasks. It assesses the noise in ITs by comparing Mylyn ITs and the ITs obtained from the video captures. It proposes an approach to correct noise and uses this approach to revisit previous studies. The collected data show that Mylyn ITs can miss, on average, about 6% of the time spent by participants performing tasks and can contain, on average, about 85% of false edit events, which are not real changes to the source code. The approach to correct noise reveals about 45% of misclassification of ITs. It can improve the precision and recall of recommendation systems from the literature by up to 56% and 62%, respectively. Mylyn ITs include noise that biases subsequent studies and, thus, can prevent researchers from assisting developers effectively. They must be cleaned before use in studies and recommendation systems. The results on Mylyn ITs open new perspectives for the investigation of noise in ITs generated by other monitoring tools such as DFlow, FeedBag, and Mimec, and for future studies based on ITs.

Context and Vision: Studying Two Factors Impacting Program Comprehension

Linguistic information derived from identifiersand comments has a paramount role in program comprehension. Indeed, very often, program documentation is scarce and when available, it is almost always outdated. Previous research works showed that program comprehension is often solely grounded on identifiers and comments and that, ultimately, it is the quality of comments and identifiers that impact the accuracy and efficiency of program comprehension. Previous works also investigated the factors in?uencing program com-prehension. However, they are limited by the available tools used to establish relations between cognitive processes and program comprehension. The goal of our research work is to foster our understanding of program comprehension by better understanding its implied underlying cognitive processes. We plan to study vision as the fundamental mean used by developers to understand a code in the context of a given program. Vision is indeed the trigger mechanism starting any cognitive process, in particular in program comprehension. We want to provide supporting evidence that context guides the cognitive process toward program comprehension. Therefore, we will perform a series of empirical studies to collect observations related to the use of context and vision in program comprehension. Then, we will propose laws and then derive a theory to explain the observable facts and predict new facts. The theory could be used in future empirical studies and will provide the relation between program comprehension and cognitive processes.