Establishing the Source Code Disruption Caused by Automated Remodularisation Tools

Abstract

Abstract-Current software remodularisation tools only operate on abstractions of a software system. In this paper, we investigate the actual impact of automated remodularisation on source code using a tool that automatically applies remodularisations as refactorings. This shows us that a typical remodularisation (as computed by the Bunch tool) will require changes to thousands of lines of code, spread throughout the system (typically no code files remain untouched). In a typical multi-developer project this presents a serious integration challenge, and could contribute to the low uptake of such tools in an industrial context. We relate these findings with our ongoing research into techniques that produce iterative commit friendly code changes to address this problem.

An Empirical Study of Cohesion and Coupling: Balancing Optimization and Disruption

“…Therefore, apart from decreasing the cohesion of the system, a Bunch re-modularisation might also be unrealistic because developers rarely create new packages to accommodate existing classes. This observation adds evidence to recent claims [13][11] against "Big Banlowere-modularisation approaches (i.e., a complete re-allocation of the system's classes in packages), where recent studies have used the original modular structure implemented by developers as a guide to find more suitable packages for certain classes [1] [8].…”

“…A previous study by Hall et al [13] measured how many lines of code ought to be added/changed in order to apply solutions found by search based modularisation approaches. Apart from showing that developers would have to change up to 10% of their code base to adopt solution proposed by automated approaches, they also showed that the LOC to be changed strongly correlates with the modular structure disruption metric MoJoFM [56].…”

“…However, despite more than 30 publications on search based modularisation, few studies [13] [11] have performed an evaluation of the disruptive effects that automated modular improvement may cause on the original modular structure of the software systems under study. A thorough study of the disruption caused by modular restructuring is needed, because there is evidence that software engineers tend to resist structural and architectural improvement in favour of similarity and familiarity [57].…”

The Scent of a Smell: An Extensive Comparison Between Textual and Structural Smells

“…Finally, the Misplaced Class represents a class located in a package that contains other classes that are not related to its function [36], [82], [97]. The interest in these code smells is dictated by the fact that they have been recognized as important threats to the maintainability of a software system [1], [40], [48], [50], [97], [109], but also because they are considered harmful by developers [73].…”

“…At the same time, our results might be affected by the presence of the socalled "conceptual" false positives [31], i.e., code smell instances identified by detection tools as true positives but not perceived as such by developers. However, we limited this threat by investigating code smell types that previous research found to be critical for developers [40], [73], thus focusing on code smell instances likely to be perceived by developers as actual design problems.…”