Exploring Structural Change and Architectural Evolution

1. Exploring Structural Change and Architectural Evolution Qiang Tu and Michael Godfrey Software Architecture Group (SWAG) University of Waterloo

2. Motivation • Change is inevitable • Usually cheaper to adapt what you have • Some change is “additive” … • e.g., new features to existing infrastructure or new infrastructure • … but a lot of change is “invasive”. • Bloat/drift causes redesign, refactoring, re-engineering CSER -- Montreal, May 2001

3. Motivation • Maintainers need to comprehend how systems have evolved, and • Researchers need to perform case studies on evolving systems, BUT • Existing techniques/tools do not adapt well to structural change, assume architecture remains stable. CSER -- Montreal, May 2001

4. Requirements for supporting environment • Flexible architecture, functionality. • Support finely- and coarsely-grained analysis, plus infrastructure for moving between levels. • Navigation and visualization. • Scale up to handle multiple versions of MLOC systems. • Support for well-known metrics, plus allow new ones to be added. CSER -- Montreal, May 2001

5. Requirements for supporting environment • Explicitly address architectural evolution. • How to model architectural relations? • How does structure change over time? • How to track and reason about changes? • Patterns of architectural change? • Compare architectural snapshots. • Pairs, multiple versions • Support identification and detection of change patterns. CSER -- Montreal, May 2001

6. Beagle: A vehicle for exploring evolution • Populate database (DB/2) with “facts” from various extractors • cfx (static analysis) • Understand for C++ (metrics) • PBS visualization engine • Java-based infrastructure; JDBC; grok scripts CSER -- Montreal, May 2001

7. Entity schemas CSER -- Montreal, May 2001

8. Case study: GCC and EGCS • Have factbases for 29 releases of GCC/EGCS over ten years. CSER -- Montreal, May 2001

9. Q1: What happened during the EGCS development? CSER -- Montreal, May 2001

10. CSER -- Montreal, May 2001

11. Q2: How can I discover previous refactorings and redesigns? CSER -- Montreal, May 2001

12. Structural change and origin analysis • Naïve analysis  lots of “added/deleted” pairs when entities are merely moved around. • Most tools/methodologies for evaluating long-term evolution are sensitive to this. • Solution: use clone-detection-like techniques [“Bertillonage”] • Need only consider “added/deleted” entities. • Complex computations (metrics) already done at check-in time. • Can work at different architectural levels: • function, file, subsystem CSER -- Montreal, May 2001

13. Origin analysis: Two techniques • Metrics-based analysis • For each “added” entity: • Calculate combined Euclidean distance from each “deleted” entity for five metrics [Kostas]. • Select top five matches; compare entity names. • Relationship analysis (e.g., caller/callee) • (Caller analysis) For each “new” entity e: • Find Re, set of all entities that call e that are present in both versions. • For each fRe, calculate Qf, set of all “deleted” entities that fcalls in old version. • Look at intersection of the Qfs; these are good candidates for e’s old name. CSER -- Montreal, May 2001

14. Caller/callee analysis CSER -- Montreal, May 2001

15. Q3: How much does ECGS differ from GCC? • Integrate newly discovered knowledge about refactorings and redesigns. • Present unified understanding in architectural views. • Permit analysis to “leap over” structural discontinuities. CSER -- Montreal, May 2001

16. CSER -- Montreal, May 2001

17. Beagle: Future work • Most of what you have seen works already! • Future work: • Theory of architectural change. • More experimentation and case studies. • Integration around cppx using GXL. CSER -- Montreal, May 2001