Clone Removal in Java Programs as a Process of Stepwise Unification

Cloned code is one of the most important obstacles against consistent software maintenance and evolution. Although today's clone detection tools find a variety of clones, they do not offer any advice how to remove such clones. We explain the problems involved in finding a sequence of changes for clone removal and suggest to view this problem as a process of stepwise unification of the clone instances. Consequently the problem can be solved by backtracking over the possible unification steps

A heuristic-based approach to code-smell detection

Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache

Reverse engineering of model transformations for reusability

The final publication is available at Springer via http://dx.doi.org/10.1007/978-3-319-08789-4_14Proceedings of 7th International Conference, ICMT 2014, Held as Part of STAF 2014, York, UK, July 21-22, 2014Reuse techniques are key for the industrial adoption of Model-Driven Engineering (MDE). However, while reusability has been successfully applied to programming languages, its use is scarce in MDE and, in particular, in model transformations. In previous works, we developed an approach that enables the reuse of model transformations for different meta-models. This is achieved by defining reusable components that encapsulate a generic transformation template and expose an interface called concept declaring the structural requirements that any meta-model using the component should fulfil. Binding the concept to one of such meta-models induces an adaptation of the template, which becomes applicable to the meta-model. To facilitate reuse, concepts need to be concise, reflecting only the minimal set of requirements demanded by the transformation. In this paper, we automate the reverse engineering of existing transformations into reusable transformation components. To make a transformation reusable, we use the information obtained from its static analysis to derive a concept that is minimal with respect to the transformation and maximizes its reuse opportunities, and then evolve the transformation accordingly. The paper describes a prototype implementation and an evaluation using transformations from the ATL zoo.This work has been funded by the Spanish Ministry of Economy and Competitivity with project “Go Lite” (TIN2011-24139

On Preserving the Behavior in Software Refactoring: A Systematic Mapping Study

Context: Refactoring is the art of modifying the design of a system without altering its behavior. The idea is to reorganize variables, classes and methods to facilitate their future adaptations and comprehension. As the concept of behavior preservation is fundamental for refactoring, several studies, using formal verification, language transformation and dynamic analysis, have been proposed to monitor the execution of refactoring operations and their impact on the program semantics. However, there is no existing study that examines the available behavior preservation strategies for each refactoring operation. Objective: This paper identifies behavior preservation approaches in the research literature. Method: We conduct, in this paper, a systematic mapping study, to capture all existing behavior preservation approaches that we classify based on several criteria including their methodology, applicability, and their degree of automation. Results: The results indicate that several behavior preservation approaches have been proposed in the literature. The approaches vary between using formalisms and techniques, developing automatic refactoring safety tools, and performing a manual analysis of the source code. Conclusion: Our taxonomy reveals that there exist some types of refactoring operations whose behavior preservation is under-researched. Our classification also indicates that several possible strategies can be combined to better detect any violation of the program semantics

Technical Debt Prioritization: State of the Art. A Systematic Literature Review

Background. Software companies need to manage and refactor Technical Debt issues. Therefore, it is necessary to understand if and when refactoring Technical Debt should be prioritized with respect to developing features or fixing bugs. Objective. The goal of this study is to investigate the existing body of knowledge in software engineering to understand what Technical Debt prioritization approaches have been proposed in research and industry. Method. We conducted a Systematic Literature Review among 384 unique papers published until 2018, following a consolidated methodology applied in Software Engineering. We included 38 primary studies. Results. Different approaches have been proposed for Technical Debt prioritization, all having different goals and optimizing on different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in practice. We report an impact map of such factors. However, there is a lack of empirical and validated set of tools. Conclusion. We observed that technical Debt prioritization research is preliminary and there is no consensus on what are the important factors and how to measure them. Consequently, we cannot consider current research conclusive and in this paper, we outline different directions for necessary future investigations