Exploring Structural Change and Architectural Evolution University of

Exploring Structural Change and Architectural Evolution University of Waterloo Qiang Tu and Michael Godfrey Software Architecture Group (SWAG) University of Waterloo CSER -- Montreal, May 2001

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, reengineering CSER -- Montreal, May 2001 2

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 3

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

Requirements for supporting environment 5. 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? 6. Compare architectural snapshots. • Pairs, multiple versions 7. Support identification and detection of change patterns. CSER -- Montreal, May 2001 5

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 6

Entity schemas CSER -- Montreal, May 2001 7

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

Q 1: What happened during the EGCS development? CSER -- Montreal, May 2001 10

CSER -- Montreal, May 2001 11

Q 2: 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 1. 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. 2. 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 f calls 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

Q 3: 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 18