Your SlideShare is downloading. ×
0
ERA - Dependency Profiles for Software Architecture Evaluations
ERA - Dependency Profiles for Software Architecture Evaluations
ERA - Dependency Profiles for Software Architecture Evaluations
ERA - Dependency Profiles for Software Architecture Evaluations
ERA - Dependency Profiles for Software Architecture Evaluations
ERA - Dependency Profiles for Software Architecture Evaluations
ERA - Dependency Profiles for Software Architecture Evaluations
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

ERA - Dependency Profiles for Software Architecture Evaluations

464

Published on

Paper: Dependency Profiles for Software Architecture Evaluations …

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
464
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. 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. 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. 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. 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. 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. 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

×