ERA - Measuring Disruption from Software Evolution Activities Using Graph-Based Metrics
description
Transcript of ERA - Measuring Disruption from Software Evolution Activities Using Graph-Based Metrics
Measuring Disruption from Software
Evolution Activities Using Graph-
Based Metrics
Prashant Paymal, Rajvardhan Patil, Sanjukta Bhowmick, Harvey Siy
Department of Computer Science,
University of Nebraska at Omaha
Introduction
• Real world software systems have large numbers of components (e.g. classes, functions, etc.)
• It is difficult to get a quick summary of how system evolved after a major change such as perfective maintenance activity or new software release
Case Study
• Our case study consists of six versions of JHotDraw from March 2001 to January 2004
Version Date Commit Messages
V1 3/9/2001 Merge to JHotDraw 5.2 (using JFC/Swing GUI components)
V2 10/24/2001 Before merge for version 5.3 (dnd, undo…) merge dnd(before 5.3)
V3 8/4/2002 After various merges… (before 5.4 relaease)
V4 11/8/2002 Refactor to use StandardStorageFormat as a superclass
V5 5/8/2003 Refactoring of Cursor. – java.awt.Cursor(class) has been systematically replaced
V6 1/9/2004 After renaming the CH.ifa.draw to org.jhotdraw
Network Construction
• Extracted relationships from these versions (inheritance, implementation, method calls and class member access, object declaration and instantiation)
• Network was created by connecting class dependencies, where each edge (u, v) is a dependency from class „u‟ to class „v‟
Vertex Properties
• Degree Distribution ▫ Frequency of vertices per degree, scale
free for most real world networks
• Clustering Coefficient ▫ Connections between neighbors
• Betweenness Centrality▫ Ratio of shortest paths through a
vertex
• Articulation Points▫ It‟s removal would cause the network to
become disconnected
• Network representing Version 1,▫ Lighter Nodes: High Betweenness Centrality▫ Larger Nodes: High Clustering Coefficient
Objective
• Extract key combinatorial properties from these six networks that would enable us to detect evolutionary characteristics such as
▫ Points of significant change in the software
▫ How these changes affect crucial classes in the network
Change in Vertex Properties
• All properties increased with version number
Correlation Between Properties
▫ Positive correlation between degree and betweenness centrality
▫ Correlation between clustering coefficient and betweenness centrality changes across versions
Disruption in Values and Rank
• We examine how the relationships between these properties changed from one version to the next
Disruption in Values and Rank
Disruption in Values and Rank
Identifying Crucial Vertices
• High▫ If vertex has high rank (within top 25) in at least one of the
following categories• Extra High
▫ If vertex has high rank in at least two categories• Low
▫ If vertex has zero value for any one vertex based properties and is not marked as a High vertex
• Extra Low▫ If it has zero value for both betweenness centrality and
clustering coefficient
• (High Betweenness Centrality, High Indegree, High Outdegree, High Clustering Coefficient / Articulation Point)
Percentage Breakdown of All Vertices
in Each Version
Percentage Breakdown of Vertices
(Common to All Versions)
High
Extra High
Low
Extra Low
Other
Analysis of Newly Added Vertices
Bug Frequencies
• Changes that have the keywords “bug fix” in the change log
• The periods with high percentage are also the periods after the high disruption
Conclusion
• The significant evolutionary changes occur between Version 2 – Version 3 and Version 4 – Version 5
• The network has grown cumulatively. Newer vertices tend to get added to the peripheries of the network
• The top 25 ranking of vertices was generally stable across versions. Important nodes stay important. This indicates stability in the design.
• The bug frequency is higher after Version 3 and Version 5. The degree of disruption can help explain why bug incidence increases (future work)
Acknowledgement
• Nebraska EPSCoR
• College of IS&T, University of Nebraska at Omaha
Thank you!