Paper: Dependency Profiles for Software Architecture Evaluations Authors: Eric Bouwers, Arie Van Deursen and Joost Visser Session: Early Research Achievements Track Session 3: Managing and Supporting Software Maintenance Activities

1. Dependency Profiles
for Software Architecture Evaluations
Eric Bouwers, Arie van Deursen, and Joost Visser
September 2011 T +31 20 314 0950
info@sig.eu
www.sig.eu

2. Why?
Background, motivation, objectives
1I6
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]
Dependency Profiles © 2011 Software Improvement Group

3. Quantifying
encapsulation and independence
2I6
Dependency Profile
• For each top-level component
• Percentages of code in 4 categories A
• Hidden = encapsulated
• Inbound = provides interface
• Outbound = requires interface
• Transit = mixed
B
A: < 75%, 10%, 15%, 0% >
• Good encapsulation,
limited dependence
B: < 40%, 20%, 35%, 5% >
• Highly exposed,
highly dependent
Dependency Profiles © 2011 Software Improvement Group

4. Preliminary observations
General
3I6
Hidden code
• Median is 35%
• Ranges from 7% to 100%
Transit Systems
• 0% for 18 systems
• Over 20% for 10 systems
Inbound and outbound
• Outbound is larger than inbound for
all but 9 systems
Dependency Profiles © 2011 Software Improvement Group 0.0 0.2 0.4 0.6 0.8 1.0
hiddenCode inboundCode outboundCode transitCode

5. Preliminary observations
Statistical
4I6
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++
Dependency Profiles © 2011 Software Improvement Group

6. Evaluation
Study design
5I6
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
Dependency Profiles © 2011 Software Improvement Group

7. Open questions
Food for discussion and future work
6I6
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
Dependency Profiles © 2011 Software Improvement Group