Detection of logical coupling based on product release history

Abstract

Code-based metrics such as coupling and cohesion are used to measure a system's structural complexity. But dealing with large systems-those consisting of several millions of lines-at the code level faces many problems. An alternative approach is to concentrate on the system's building blocks such as programs or modules as the unit of examination. We present an approach that uses information in a release history of a system to uncover logical dependencies and change patterns among modules. We have developed the approach by working with 20 releases of a large Telecommunications Switching System. We use release information such as version numbers of programs, modules, and subsystems together with change reports to discover common change behavior (i.e. change patterns) of modules. Our approach identifies logical coupling among modules in such a way that potential structural shortcomings can be identified and further examined, pointing to restructuring or reengineering opportunities.

Are suggestions from coupled file changes useful for perfective maintenance tasks?

“…Many studies have been dedicated to investigating software repositories to find logically coupled changes, e.g., Bieman, Andrews & Yang (2003) ;Fluri, Gall & Pinzger (2005) ;Gall, Hajek & Jazayeri (1998). We identify two granularity levels, the first one investigates the couplings based on a file level (Kagdi, Yusuf & Maletic, 2006;Ying et al, 2004) and the second scenario examines coupled changes identified between parts of files like classes, methods or modules (Fluri, Gall & Pinzger, 2005;Kagdi, 2007;Zimmermann et al, 2004;Zimmermann et al, 2006;Hassan & Holt, 2004).…”

SE² model to support software evolution

“…Such dependencies are termed as evolutionary dependencies or couplings [5,6,17,18]. The changes observed from the past evolution of a specific system are used as a basis to speculate the change dependencies between any given software entities.…”

Is It Dangerous to Use Version Control Histories to Study Source Code Evolution?

“…Gall et al [16] studied the logical dependencies and change patterns in a product family of Telecommunication Switching Systems by analyzing 20 punctuated software releases over two years. They decomposed the system into modules and used their CAESAR technique to analyze how the structure and software metrics of these modules evolved through different releases.…”

“…Since a shadowed change is not present in the code, it is not present in the snapshot committed to a Version Control System (VCS). Therefore, code evolution research performed on the snapshots stored in the VCS (like in [16][17][18]) does not account for shadowed code changes. Ignoring shadowed changes could significantly limit the accuracy of tools that try to infer the intent of code changes (e.g., infer refactorings [10,11,21,49,50], infer bug fixes [23,30,32,33,39,53]).…”