T +31 20 314 0950 info@sig.eu www.sig.eu

Dependency Profiles for Software Architecture Evaluations Eric Bouwers, Arie van Deursen, and Joost Visser

September 2011

I 6 1

Dependency Profiles © 2011 Software Improvement Group

Why? Background, motivation, objectives

Architecture •  “Organizational structure of a software system, including components, connections,

constraints, and rationale.” [Kogut and Clements, 1994]

Evaluation •  Of implemented architecture •  Monitoring during initial development and continued evolution

Metrics •  Traditionally: coupling and cohesion at the level of modules (files, classes) •  Desired: at the architectural level •  Desired: simple, technology-independent, allowing root cause analysis [Heitlager et al 2007]

I 6

Dependency Profiles © 2011 Software Improvement Group

Quantifying encapsulation and independence

Dependency Profile •  For each top-level component •  Percentages of code in 4 categories •  Hidden = encapsulated •  Inbound = provides interface •  Outbound = requires interface •  Transit = mixed

A: < 75%, 10%, 15%, 0% > •  Good encapsulation,

limited dependence B: < 40%, 20%, 35%, 5% > •  Highly exposed,

highly dependent

A

B

2

I 6 3

Dependency Profiles © 2011 Software Improvement Group

Preliminary observations General

Hidden code •  Median is 35% •  Ranges from 7% to 100%

Transit •  0% for 18 systems •  Over 20% for 10 systems

Inbound and outbound •  Outbound is larger than inbound for

all but 9 systems

hiddenCode inboundCode outboundCode transitCode

0.0 0.2 0.4 0.6 0.8 1.0

Syst

ems

I 6 4

Dependency Profiles © 2011 Software Improvement Group

Preliminary observations Statistical

Correlation with size? •  Spearman rank correlation •  None for hidden and transit code •  Weak for inbound (-0.28) and outbound (0.32)

Differences per technology, type of system, development context? •  Kolmogorov-Smirnov •  No differences between industry and open source •  No differences between libraries and applications •  Lower percentage of hidden code for Java than for .NET or C/C++

I 6 5

Dependency Profiles © 2011 Software Improvement Group

Evaluation Study design

Data •  Source code, taking top-level packages as components •  Change history

Dependent variable •  Percentage of cross-component change-sets

Hypotheses •  In systems with low percentages of inbound + transit code,

encapsulation is better and therefore changes are less likely to propagate to other components

•  In systems with low percentage of outbound + transit code, components are more independent and therefore changes are less likely to propagate to other components

I 6 6

Dependency Profiles © 2011 Software Improvement Group

Open questions Food for discussion and future work

Future work •  Empirical validation against internal change ratios •  Include into SIG quality model and standard evaluation process •  Collect experience of SIG consultants with application to 100+ systems annually

Discussion •  Purely graph-based architecture metrics abstract too much to evaluate the degree of

information hiding / preparedness for change that is achieved.

Dr. ir. Joost Visser j.visser@sig.eu http://twitter.com/jstvssr www.sig.eu +31 20 314 0950