ERA - Dependency Profiles for Software Architecture Evaluations
1 like262 views
The document discusses dependency profiles as a method for evaluating software architecture, focusing on encapsulation and component independence. It presents observations about the distribution of code categories within components and statistical correlations to system size and technology. Future work aims to empirically validate findings and enhance quality evaluation processes.
![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](https://image.slidesharecdn.com/2011-09dependencyprofilesicsm2011-111015133113-phpapp01/85/ERA-Dependency-Profiles-for-Software-Architecture-Evaluations-2-320.jpg)
ERA - Dependency Profiles for Software Architecture Evaluations
- 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