How History Justifies System Architecture (or not)
Lehrstuhl für Softwaretechnik (Prof. Zeller)
Universität des Saarlandes – Informatik
Informatik Campus des Saarlandes
Campus E9 1 (CISPA)
E-mail: zeller @ cs.uni-saarland.de
Telefon: +49 681 302-70970
How History Justifies System Architecture (or not).
International Workshop on Principles of Software Evolution
(IWPSE 2003), Helsinki, Finland, September 2003.
"Each time when function is_single_display_cmd() is modified, the function PosBuffer::filter() is changed, too. [...] At first glance, these two methods have no recognizable dependency. However, the DDD maintainer confirmed that the two functions must typically be changed together. This is another example where our approach reveals dependencies that may not be recognized by traditional program analysis." (Example: The DDD Debugger)
Get the paper in PDF format (11 pages, 690k).
AbstractThe 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 non-program artifacts that is unavailable to the analysis of a single version.
See Also...<email@example.com> · http://www.st.cs.uni-saarland.de/papers/iwpse2003/ · Stand: 2018-04-05 13:41