não disponível

Low structural coupling is a design principle at the heart of software engineering. A recurrent claim is that classes with high coupling are prone to undergo forced local changes as a consequence of changes made in the classes they are connected to. This claim can be found in almost every Software Engineering book, in fundrunental papers of the area, in whitepapers written by industry experts, and even in Wikipedia. Despite the popularity and credibility of the claim, very little research effort has been put on its understanding. In other words, if a class A depends on another class B, then is A more likely to co-change with B as compared to the case where A does not depend on B? In other words, is the existence of dependencies statistically associated with the occurrence of co-changes? To what extent? Answering this question is crucial step in understanding the link between dependencies and software changes. Hence, in this paper, we set out to empirically investigate the link between structural dependencies and co-changes. In a preliminary study with 4 open-source systems, we discovered that structural dependencies do not instantly make artifacts co-change. However, the rate with which an artifact co-cochanges with another is indeed higher when the former structurally depends on the latter. We confirmed this finding in a new study where we extracted structural dependencies and co-changes from 77,286 code snapshots of 45 Java projects randomly sampled from the Apache Software Foundation. Our results indicated that, when A depends on Band B changes, the chances of A changing together with B is around 32 percent in average, with a standard deviation of 13.6 percent. We also built classification models using Random Forests to investigate which kinds of dependency best explain co-changes. We found that the length of transitive dependencies, number of type imports, number of method calls, and number of references were the most important variables in the model. However, the classifiers were often inaccurate, thus implying that dependencies are not good predictors for co-changes. In fact, we also found that a substantial number of commits involve classes that are not connected via dependencies, reinforcing our belief that co-changes are more frequently induced by other forms of connascence, such as conceptual coupling. In summary, on the one hand, we found empirical evidence connecting the existence of structural dependencies to the occurrence co-changes. On the other hand, we found that the majority of co-changes do not correlate with structural dependencies, meaning that structural dependencies might be responsible for a small portion of all software changes. As a practical consequence, developers should still embrace the low coupling principle by managing software dependencies while designing and evolving their systems. However, our findings also imply that IDEs should take into account additional sources of information to support developers in successfully propagating software changes, as structural iv dependencies seem not to be the main player. Finally, the data and tools produced during this research might be leveraged to bootstrap follow-up investigations, such as the influence of structural anti-patterns on change propagation