Unveiling and reasoning about co-change dependencies

Product flexibility is one of the expected benefits of a modular design, and thus "it should be possible to make drastic changes to a module without changing others." Accordingly, the data available on version control systems might help software architects to reason about some quality attributes of the modular decomposition of a system. In this paper we investigate the impact of co-change dependencies into system stability, that is, the potential ripple effect that might occur during maintenance tasks. Here we use (a) Design Structure Matrices (DSMs) for visualizing dependencies motivated by assets’ co-change and (b) two metrics for estimating system stability: Propagation Cost of Changes and Clustered Cost of a Decomposition. We conducted a comprehensive study about co-change dependencies and their effects on system stability, considering the change history of six open-source Java systems: Derby, Eclipse UI, Eclipse JDT, Hadoop, Geronimo, and Lucene; and one relevant financial systems of the Brazilian Government (SIOP). We evaluated two distinct situations: first considering only the static dependencies of each system and then considering both static and co-change dependencies of each system. There is a significant impact of the co-change dependencies on the stability measurements for Derby, Hadoop, Lucene, and SIOP. This result suggests that the modular decomposition of these systems does not resemble their change history. Accordingly, our findings provide empirical evidence that the common approach for reasoning about the modular decomposition, which often uses only static dependencies, hides important details about the costs of maintenance tasks.