ERA - Dependency Profiles for Software Architecture Evaluations

589 views

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
589
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

ERA - Dependency Profiles for Software Architecture Evaluations

  1. 1. Dependency Profilesfor Software Architecture EvaluationsEric Bouwers, Arie van Deursen, and Joost Visser September 2011 T +31 20 314 0950 info@sig.eu www.sig.eu
  2. 2. Why?Background, motivation, objectives 1I6Architecture •  “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 evolutionMetrics •  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. 3. Quantifyingencapsulation and independence 2I6Dependency Profile •  For each top-level component •  Percentages of code in 4 categories A •  Hidden = encapsulated •  Inbound = provides interface •  Outbound = requires interface •  Transit = mixed BA: < 75%, 10%, 15%, 0% > •  Good encapsulation, limited dependenceB: < 40%, 20%, 35%, 5% > •  Highly exposed, highly dependentDependency Profiles © 2011 Software Improvement Group
  4. 4. Preliminary observationsGeneral 3I6Hidden code •  Median is 35% •  Ranges from 7% to 100%Transit Systems •  0% for 18 systems •  Over 20% for 10 systemsInbound and outbound •  Outbound is larger than inbound for all but 9 systemsDependency Profiles © 2011 Software Improvement Group 0.0 0.2 0.4 0.6 0.8 1.0 hiddenCode inboundCode outboundCode transitCode
  5. 5. Preliminary observationsStatistical 4I6Correlation 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. 6. EvaluationStudy design 5I6Data •  Source code, taking top-level packages as components •  Change historyDependent variable •  Percentage of cross-component change-setsHypotheses •  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 componentsDependency Profiles © 2011 Software Improvement Group
  7. 7. Open questionsFood for discussion and future work 6I6Future 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 annuallyDiscussion •  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 0950Dependency Profiles © 2011 Software Improvement Group

×