Using Modularity Metrics to assist Move Method Refactoring of Large System

For large software systems, refactoring activities can be a challenging task, since for keeping component complexity under control the overall architecture as well as many details of each component have to be considered. Product metrics are therefore often used to quantify several parameters related to the modularity of a software system. This paper devises an approach for automatically suggesting refactoring opportunities on large software systems. We show that by assessing metrics for all components, move methods refactoring an be suggested in such a way to improve modularity of several components at once, without hindering any other. However, computing metrics for large software systems, comprising thousands of classes or more, can be a time consuming task when performed on a single CPU. For this, we propose a solution that computes metrics by resorting to GPU, hence greatly shortening computation time. Thanks to our approach precise knowledge on several properties of the system can be continuously gathered while the system evolves, hence assisting developers to quickly assess several solutions for reducing modularity issues

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

Refactorings of Design Defects using Relational Concept Analysis

Software engineers often need to identify and correct design defects, ıe} recurring design problems that hinder development and maintenance\ud by making programs harder to comprehend and--or evolve. While detection\ud of design defects is an actively researched area, their correction---mainly\ud a manual and time-consuming activity --- is yet to be extensively\ud investigated for automation. In this paper, we propose an automated\ud approach for suggesting defect-correcting refactorings using relational\ud concept analysis (RCA). The added value of RCA consists in exploiting\ud the links between formal objects which abound in a software re-engineering\ud context. We validated our approach on instances of the <span class='textit'></span>Blob\ud design defect taken from four different open-source programs

Using FCA to Suggest Refactorings to Correct Design Defects

Design defects are poor design choices resulting in a hard-to- maintain software, hence their detection and correction are key steps of a\ud disciplined software process aimed at yielding high-quality software\ud artifacts. While modern structure- and metric-based techniques enable\ud precise detection of design defects, the correction of the discovered\ud defects, e.g., by means of refactorings, remains a manual, hence\ud error-prone, activity. As many of the refactorings amount to re-distributing\ud class members over a (possibly extended) set of classes, formal concept\ud analysis (FCA) has been successfully applied in the past as a formal\ud framework for refactoring exploration. Here we propose a novel approach\ud for defect removal in object-oriented programs that combines the\ud effectiveness of metrics with the theoretical strength of FCA. A\ud case study of a specific defect, the Blob, drawn from the\ud Azureus project illustrates our approach

Class movement and re-location: An empirical study of Java inheritance evolution

This is the post-print version of the final paper published in Journal of Systems and Software. The published article is available from the link below. Changes resulting from the publishing process, such as peer review, editing, corrections, structural formatting, and other quality control mechanisms may not be reflected in this document. Changes may have been made to this work since it was submitted for publication. Copyright @ 2009 Elsevier B.V.Inheritance is a fundamental feature of the Object-Oriented (OO) paradigm. It is used to promote extensibility and reuse in OO systems. Understanding how systems evolve, and specifically, trends in the movement and re-location of classes in OO hierarchies can help us understand and predict future maintenance effort. In this paper, we explore how and where new classes were added as well as where existing classes were deleted or moved across inheritance hierarchies from multiple versions of four Java systems. We observed first, that in one of the studied systems the same set of classes was continuously moved across the inheritance hierarchy. Second, in the same system, the most frequent changes were restricted to just one sub-part of the overall system. Third, that a maximum of three levels may be a threshold when using inheritance in a system; beyond this level very little activity was observed, supporting earlier theories that, beyond three levels, complexity becomes overwhelming. We also found evidence of ‘collapsing’ hierarchies to bring classes up to shallower levels. Finally, we found that larger classes and highly coupled classes were more frequently moved than smaller and less coupled classes. Statistical evidence supported the view that larger classes and highly coupled classes were less cohesive than smaller classes and lowly coupled classes and were thus more suitable candidates for being moved (within an hierarchy)