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.