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

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.

4
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.

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.

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

7
Entity schemas
8
Beagle architecture
9
Case study GCC and EGCS

• Have factbases for 29 releases of GCC/EGCS over
  ten years.

10
Q1 What happened during the EGCS development?
11
(No Transcript)
12
Q2 How can I discover previous refactorings and
redesigns?
13
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

14
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 f calls in old version.
• Look at intersection of the Qfs these are good
  candidates for es old name.

15
Caller/callee analysis
16
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.

17
(No Transcript)
18
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.

19
(No Transcript)
20
(No Transcript)
21
(No Transcript)
22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
(No Transcript)
26
(No Transcript)
27
(No Transcript)