1 / 17

Exploring Structural Change and Architectural Evolution

Exploring Structural Change and Architectural Evolution. Qiang Tu and Michael Godfrey Software Architecture Group (SWAG) University of Waterloo. Motivation. Change is inevitable Usually cheaper to adapt what you have Some change is “additive” …

Download Presentation

Exploring Structural Change and Architectural Evolution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related