Post on 19-Jan-2016
description
University of Waterloo
Exploring Structural Change and Architectural Evolution
Qiang Tu and Michael Godfrey
Software Architecture Group (SWAG)
University of Waterloo
CSER -- Montreal, May 2001 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,
BUTExisting techniques/tools do not adapt well
to structural change, assume architecture remains stable.
CSER -- Montreal, May 2001 4
Requirements for supporting environment1. 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 5
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 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
Entity Attribute
PK Entity ID
Entity String
Configuration Attribute
PK Configuration Key
Configuration String
Version Number
PK Release Key
SeriesMajorMinorBugfix MajorBugfix Minor
Release Date
PK Release Key
YearMonthDay
Function Metrics
PK Function IDPK File IDPK Release Key
Line of CodeLine of CommentCyclomaticMax NestingFan-InFan-OutInputOutputGlobal Variable AccessGlobal Variable UpdateParameterParameter UpdateLocal VariableS-ComplexD-ComplexAlbrechtKafura
File Metrics
PK File IDPK Release Key
Line of CodeAverage CyclomaticAverage Line of CodeAverage Line of CommentAverage Fan-OutFunctions DefinedInputOutputGlobal Variable AccessMaintainance Index
Function-Level Fact
PK Release KeyPK Configuration KeyPK RelationPK Entity APK Entity B
Entity B Property
File-Level Fact
PK Release KeyPK Configuration KeyPK RelationPK Entity APK Entity B
Program-Level Fact
PK Release KeyPK Configuration KeyPK RelationPK Entity APK Entity B
Subsystem-Level Fact
PK Release KeyPK Configuration KeyPK RelationPK Entity APK Entity B
CSER -- Montreal, May 2001 9
Case study: GCC and EGCS
• Have factbases for 29 releases of GCC/EGCS over ten years.
0
100
200
300
400
500
600
700
800
900
1000
Aug-87 Dec-88 May-90 Sep-91 Jan-93 Jun-94 Oct-95 Mar-97 Jul-98 Dec-99 Apr-01
# o
f m
od
ule
s
g++
gcc
egcs
CSER -- Montreal, May 2001 10
Q1: What happened during the EGCS development?
CSER -- Montreal, May 2001 11
CSER -- Montreal, May 2001 12
Q2: How can I discover previous refactorings and redesigns?
CSER -- Montreal, May 2001 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
CSER -- Montreal, May 2001 14
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 15
Caller/callee analysis
B( )
C( )
A( )
D( )
E( )
B( )
G( ) G( )
F( )
N( )
E( )
N( )
Releasev2.0
Releasev1.0
A( )
A( )
CSER -- Montreal, May 2001 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.
CSER -- Montreal, May 2001 17
CSER -- Montreal, May 2001 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.