Improving software modularization via automated analysis of latent topics and dependencies

Abstract

Oftentimes, during software maintenance the original program modularization decays, thus reducing its quality. One of the main reasons for such architectural erosion is suboptimal placement of source code classes in software packages. To alleviate this issue, we propose an automated approach to help developers improve the quality of software modularization. Our approach analyzes underlying latent topics in source code as well as structural dependencies to recommend (and explain) refactoring operations aiming at moving a class to a more suitable package. The topics are acquired via Relational Topic Models (RTM), a probabilistic topic modeling technique. The resulting tool, coined as R3 (Rational Refactoring via RTM), has been evaluated in two empirical studies. The results of the first study conducted on nine software systems indicate that R3 provides a coupling reduction from 10% to 30% among the software modules. The second study with 62 developers confirms that R3 is able to provide meaningful recommendations (and explanations) for move class refactoring. Specifically, more than 70% of the recommendations were considered meaningful from a functional point of view.

An empirical study on the interplay between semantic coupling and co-change of software classes

“…Some studies have used the term "semantic" (Poshyvanyk et al 2009;Qusef et al 2011, Bavota et al 2010, 2013b, 2014aKagdi et al 2010;Gethers et al 2012), while others have used the term "conceptual" (Gethers et al 2012) to describe the same concept. Poshyvanyk et al (2009) state that conceptual coupling captures the degree to which the identifiers and comments from different classes relate to each other (Qusef et al 2011, Bavota et al 2010, 2013b, 2014aKagdi et al 2010).…”

“…Poshyvanyk et al (2009) state that conceptual coupling captures the degree to which the identifiers and comments from different classes relate to each other (Qusef et al 2011, Bavota et al 2010, 2013b, 2014aKagdi et al 2010). Gethers et al (2012) add a twist to the definition and state that conceptual coupling captures the extent to which domain concepts/features and software artefacts are related to each other.…”

Analysis of Metric-Based Object-Oriented Code Refactoring Opportunities Identification Approaches

“…However, during software evolution or maintenance, as the software systems' internal structure is subjected to continuous enhancement, modification and adaptation, its code becomes comp lex and consequently drift away fro m the orig inal design [5] [21]. Furthermo re, poor design decisions due to strict condition of deadline forces developers not to adhered to the princip le of h igh cohesion and low coupling [11] [12]. As a result, the software (packages, classes , methods or field) in turn becomes mo re co mp lex and deteriorates in quality thereby making it difficult to understand and maintain [9].…”

“…Consequently, as the class responsibilities increases, so its complexity leading to the deterioration of its quality [9] [10]. Studies have shown that some of the causes of design flaws in software systems are due to the applicat ion of inappropriate design solutions by developers leading to code not conforming to OO programming rules and market pressure resulting to strict deadline [11] [12]. To this end, co mprehending and maintaining the software systems becomes a difficult, if not impossible tasks.…”

“…To perform refactoring in software code, the first task is to pinpoint the refactoring candidates that manifest in the form of bad smells before applying the appropriate refactoring to remove them. Today, there exist several approaches to identify refactoring opportunities in OO software systems and the application of appropriate refactorings have been proposed, developed and utilized during software development [10] [12][17] [18][19] [20]. However, these approaches are designed to identify opportunity for a particular refactoring candidate or couple of them which is ach ieved by either full automation or semi automat ion.…”