How history justifies system architecture (or not)

Abstract

The revision history of a software system conveys important information about how and why the system evolved in time. The revision history can also tell us which parts of the system are coupled by common changes: "whenever the database schema was changed, the sqlquery() method was altered, too." This "evolutionary" coupling can be compared with the coupling as imposed by the system architecture; differences indicate anomalies which may be subject to restructuring. Our ROSE prototype analyzes fine-grained coupling between software entities as indicated by common changes. It turns out that common changes are a good indicator for modularity, that evolutionary coupling should be determined between syntactical entities (rather than files or modules), and that common changes can indicate coupling between software entities and nonprogram artifacts that is unavailable to the analysis of a single version.