Understanding Multi-Dimensional Code Couplings
Dissertation zur Erlangung des akademischen Grades Doktor der Naturwissenschaften (Dr. rer. nat.) am Fachbereich IV der Universit¨at Trier
vorgelegt von Dipl.-Inf. Fabian Beck
im Februar 2013
Betreuer:
Prof. Dr. Stephan Diehl, Universit¨at Trier
ii
Abstract
Software systems consist of hundreds or thousands of files, which are usually not independent of each other but coupled. While it is obvious that structural dependencies like method calls or data accesses create couplings, there also exist other, more indirect forms of coupling that should be considered when modifying, extending, or debugging a system. In contrast to most previous research, this doctoral thesis considers code coupling as a multi-dimensional construct: several forms of structural couplings are contrasted to couplings based on the history and the semantics of the source code entities. The work proposes two novel visualization techniques, which allow for exploring and visually comparing different concepts of coupling. Based on an empirical study on open source systems, the work further provides insights into the relationship between concepts of coupling and the modularization of software; first evidence on the usage of modularization principles can be derived thereof. Finally, a new application for adapting the modularization of a software system—component extraction—is introduced and tested with varying coupling data. In general, this thesis targets at improving the understanding of multi-dimensional code couplings by systematically contrasting various concepts of coupling.
iii
iv
Preface
This work is a dissertation thesis submitted at the University of Trier (Fachbereich IV – Informatik ) in February 2013. It has been supervised by Prof. Dr. Stephan Diehl (University of Trier). As examiners, I propose Prof. Dr. Stephan Diehl and Prof. Dr. Martin Pinzger (Alpen-Adria University of Klagenfurt). The research has been in parts supported by the Deutsche Forschungsgemeinschaft (DFG) [grant number DI 728/8-1/2].
Prior Publication Parts of the content of this thesis—including ideas, approaches, results, and figures— have been already published elsewhere. In particular, the work is based or connected to the following publications: • The feasibility study summarized in Chapter 2 was conducted as part my of diploma thesis [21] and later on refined and published as a full paper at the 17th Working Conference on Reverse Engineering (WCRE 2010) [23]—an extended version of this paper was invited and accepted for Empirical Software Engineering [26]. • The node-link visualization approach presented in Section 4.3 was accepted as a full paper at the 6th IEEE International Workshop on Visualizing Software for Understanding and Analysis (VISSOFT 2011) [30]. Some excerpts of the related parallel edge splatting approach published in the IEEE Transactions of Visualization and Graphics [61] (as a conference contribution to InfoVis 2011 ) are also discussed in this context. • The matrix-based visualization approach as introduced in Section 4.4 was presented as a full paper at the 5th International Symposium on Software Visual-
v
vi
ization (SOFTVIS 2010) [24]. Furthermore, an extended version of the paper was invited and accepted to be published in Information Visualization [27]. • The evaluation of the visualization approaches in Section 4.5 summarizes a yet unpublished paper [5]. • The empirical study in Chapter 5 reports results published as a full paper at the 19th ACM SIGSOFT Symposium on Foundations of Software Engineering and 13th European Software Engineering Conference (SIGSOFT/FSE 2011 and ESEC 2011) [25]. For this publication, I was awarded the Joseph A. Schumpeter-Preis of the Fachbereich IV, University of Trier in 2012. • The component extraction approach of Chapter 6 was presented as a full paper at the 17th Working Conference on Reverse Engineering (WCRE 2010) [183]. The improved user interface for the approach was introduced as a short paper at 14. Workshop Software-Reengineering [29]. Other published works I was involved in [22, 31, 55, 56, 57, 60, 87] are not in the main scope of the thesis but are referenced as related work—their content is not integrated to larger extent into the thesis.
Acknowledgments My grateful thanks go to my advisor Stephan Diehl for providing me the great opportunity of working on this research project, for his helpful support and advice conducting the research, for many intense and fruitful discussions, for encouraging me in pursuing a career in academia, and, not least, for being an excellent role model as a researcher and teacher. I also thank Martin Pinzger for being willing to take the role as examiner and for his valuable feedback on my research. Besides the support of my advisor, the research forming the basis for this thesis has been conducted also in collaboration with other researchers and students. I would like to thank everybody involved, in particular, Michael Burch for many constructive discussions, his expertise in visualization, and the productive collaboration in many projects, Radoslav Petkov for implementing the node-link visualization approach, Patrick Braun and Martin Puppe for implementing different bundling approaches for this approach, Andreas Marx for collaboratively designing the component extraction approach and for implementing the initial component extraction tool, Alexander Pavel for implementing the improved interface for component extraction, Benjamin Biegel, Artur Lipinski, Alexander Voskoboinik, and Peter Weißgerber for their help with data acquisition, Michael Burch, Corinna Vehlow, and Daniel Weiskopf for collaboratively developing the parallel edge splatting approach, Ala Abuthawabeh and Dirk Zeckzer for the collaboration on evaluating the visualization approaches, Andrea Jaax for her expertise on min-cut problems, and G¨ unter Daniel Rey for his advice in statistics. Drafts of this thesis were proofread by Benjamin Biegel,
vii
Michael Burch, Rainer Lutz, Florian Reitz, and G¨ unter Daniel Rey—thank you for your constructive feedback. I have always liked to work at the University of Trier, which can be attributed to large extent to my great colleagues, who created a welcoming and amicable atmosphere. My particular thanks go to Stephan Diehl for fostering this atmosphere, to Benjamin Biegel and Rainer Lutz (the other members of the software engineering group) and Michael Burch (a former member, who often came for a visit) for being such supportive colleagues and good friends, to Jennifer Driesch, Lisa Horn, Sandra G¨orres, and Agnes Jacoby for their support in administrative issues, to Florian Reitz for the supply in coffee and for many good conversations, to all undergraduate students working together with me for their support in research and their interesting ideas, to everybody using the coffee machine or joining our table at lunch for relaxing breaks, and to our weekly badminton group and the occasional board game group for exiting matches. My special thanks are directed to my loving family and friends for their support, their interest in me, their help with problems, inspiring discussions, and relaxing activities.
Artwork A picture accompanies the beginning of each chapter. I created these pieces of generative design (images computed by an algorithm) as a leisure activity along working on the thesis. The initial idea—not related to the thesis—was to simulate ink diffusion in water, but the project drifted towards more abstract artifacts that share many characteristics with code fragments coupled by multiple concepts: dense areas of color form nodes that are connected by various branches in several directions; the fuzziness and overlap of these branches may reflect the multi-dimensionality and uncertainty that comes along when studying those couplings in real software projects. Hence, the generated images can be considered as an artistic interpretation of multi-dimensional code couplings. Each image is intended to somehow reflect the nature of the respective chapter.
Feedback I am very interested in the readers’ opinion and feedback on this work. Please contact me if you have questions, comments, or critique1 . I would be also very glad to receive ideas for future research and willing to collaborate on related projects. —Fabian Beck, February 2013 1
[email protected]
viii
CONTENTS
List of Figures
xiii
List of Tables
xvii
1 Introduction 1.1 Modularity . . 1.2 The Congruence 1.3 Objectives . . . 1.4 Outline . . . . .
. . . . . . . of Coupling . . . . . . . . . . . . . .
2 Feasibility Study 2.1 Objectives . . . . . . 2.2 Experimental Design 2.2.1 Dataset . . . 2.2.2 Clustering . . 2.2.3 Assessment . 2.3 Results . . . . . . . . 2.3.1 Comparison . 2.3.2 Combination 2.4 Lessons Learned . . . 2.4.1 Feasibility . . 2.4.2 Challenges . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . and Modularity . . . . . . . . . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . .
. . . . . . . . . . .
. . . .
. . . . . . . . . . .
. . . .
. . . . . . . . . . .
. . . .
. . . . . . . . . . .
. . . .
. . . . . . . . . . .
. . . .
. . . . . . . . . . .
. . . .
. . . . . . . . . . .
. . . .
. . . . . . . . . . .
. . . .
. . . . . . . . . . .
. . . .
. . . . . . . . . . .
. . . .
. . . . . . . . . . .
. . . .
. . . . . . . . . . .
. . . .
. . . . . . . . . . .
. . . .
1 3 4 5 6
. . . . . . . . . . .
9 10 10 10 12 12 13 13 14 15 15 15
3 Code Coupling 17 3.1 Application Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2 Coupling Graph Data Model . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.1 Code Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
ix
x
Contents
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
21 22 24 24 25 26 31 36 40 42
4 Visual Comparison of Code Couplings 4.1 Visualizing Code Couplings . . . . . . . . . . . 4.1.1 Graph Visualization Paradigms . . . . . 4.1.2 Node-Link Approaches . . . . . . . . . . 4.1.3 Adjacency Matrix Approaches . . . . . . 4.1.4 Software Development Tools . . . . . . . 4.2 Visual Graph Comparison . . . . . . . . . . . . 4.2.1 Static Node-Link-Based Comparison . . 4.2.2 Animated Node-Link-Based Comparison 4.2.3 Matrix-Based Comparison . . . . . . . . 4.2.4 Aggregation-Based Comparison . . . . . 4.2.5 Limitations of Existing Approaches . . . 4.3 Node-Link Approach . . . . . . . . . . . . . . . 4.3.1 Objectives . . . . . . . . . . . . . . . . . 4.3.2 Visualization Approach . . . . . . . . . . 4.3.3 Interactive Visualization Tool . . . . . . 4.3.4 Design Alternatives . . . . . . . . . . . . 4.3.5 Visual Patterns . . . . . . . . . . . . . . 4.3.6 Case Study . . . . . . . . . . . . . . . . 4.3.7 Summary . . . . . . . . . . . . . . . . . 4.4 Matrix Approach . . . . . . . . . . . . . . . . . 4.4.1 Objectives . . . . . . . . . . . . . . . . . 4.4.2 Visualization Approach . . . . . . . . . . 4.4.3 Interactive Visualization Tool . . . . . . 4.4.4 Advanced Layout . . . . . . . . . . . . . 4.4.5 Case Study . . . . . . . . . . . . . . . . 4.4.6 Summary . . . . . . . . . . . . . . . . . 4.5 Explorative Evaluation . . . . . . . . . . . . . . 4.5.1 Experimental Design . . . . . . . . . . . 4.5.2 Results . . . . . . . . . . . . . . . . . . . 4.5.3 Limitations . . . . . . . . . . . . . . . . 4.6 Discussion . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43 44 44 46 50 51 53 55 57 57 58 59 60 60 61 65 73 78 79 86 86 87 88 94 100 112 117 118 118 120 122 122
3.3
3.4
3.2.2 Coupling . . . . . . . . . . . 3.2.3 Modularity . . . . . . . . . 3.2.4 Implementation . . . . . . . Concepts of Coupling . . . . . . . . 3.3.1 Object-Oriented Systems . . 3.3.2 Structure . . . . . . . . . . 3.3.3 History . . . . . . . . . . . . 3.3.4 Semantics . . . . . . . . . . 3.3.5 Other Concepts of Coupling Discussion . . . . . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
xi
Contents
4.6.1 4.6.2
Contrasting the Two Approaches . . . . . . . . . . . . . . . . 122 Extended Application Scenarios . . . . . . . . . . . . . . . . . 126
5 Empirically Analyzing the Congruence 5.1 Objectives . . . . . . . . . . . . . . . . . . . . 5.2 Modularity Principles . . . . . . . . . . . . . . 5.2.1 Low Coupling and High Cohesion . . . 5.2.2 Information Hiding . . . . . . . . . . . 5.2.3 Conway’s Law . . . . . . . . . . . . . . 5.2.4 Further Principles and Guidelines . . . 5.2.5 Conjectured Relationships . . . . . . . 5.3 Coupling-Modularity Congruence . . . . . . . 5.3.1 Module Cohesion and Coupling . . . . 5.3.2 Congruence Metric . . . . . . . . . . . 5.3.3 Related Metrics . . . . . . . . . . . . . 5.4 Study . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Independence of Concepts . . . . . . . 5.4.2 Coupling-Modularity Congruence . . . 5.4.3 Module Type Congruence . . . . . . . 5.4.4 Result Summary . . . . . . . . . . . . 5.5 Discussion . . . . . . . . . . . . . . . . . . . . 5.5.1 Threats to Validity . . . . . . . . . . . 5.5.2 Related Empirical Studies . . . . . . . 5.5.3 Implications on Modularity Principles . 5.5.4 Impact on Tools . . . . . . . . . . . . . 6 Component Extraction 6.1 Component Extraction Approach . . . 6.1.1 Application Scenario . . . . . . 6.1.2 Code Couplings . . . . . . . . . 6.1.3 Extraction Process . . . . . . . 6.2 Objectives . . . . . . . . . . . . . . . . 6.3 Algorithmic Approach . . . . . . . . . 6.3.1 Component Extraction Problem 6.3.2 Algorithmic Solution . . . . . . 6.3.3 Inertia . . . . . . . . . . . . . . 6.3.4 Component Contract . . . . . . 6.4 Interactive User Interface . . . . . . . . 6.4.1 Prototype Interface . . . . . . . 6.4.2 User Study . . . . . . . . . . . 6.4.3 Improved Interface . . . . . . . 6.5 Evaluating Component Extraction . . . 6.5.1 Experimental Design . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
129 130 131 131 133 134 135 136 137 138 140 143 144 145 149 153 157 157 157 158 161 163
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
165 . 166 . 167 . 168 . 168 . 169 . 170 . 170 . 172 . 174 . 175 . 177 . 178 . 180 . 182 . 185 . 185
xii
Contents
6.6
6.5.2 Results . . . . . . . . . . . . 6.5.3 Threats to Validity . . . . . Discussion . . . . . . . . . . . . . . 6.6.1 Related Approaches . . . . . 6.6.2 Applicability and Extensions
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
189 194 195 196 198
7 Conclusion
201
Bibliography
205
Zusammenfassung
233
LIST OF FIGURES
1.1 1.2
Two Java classes related by multiple concepts of coupling. . . . . . . Overview of the outline of this thesis. . . . . . . . . . . . . . . . . . .
3.1
Visualized example of a modularized code coupling graph including two concepts of coupling. . . . . . . . . . . . . . . . . . . . . . . . . . 19 Overview of retrieving coupling data from a software project. . . . . . 25
3.2
Visualization of a graph following the node-link and the adjacency matrix paradigm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Representation of different concepts of coupling in a UML class diagram. 4.3 Two sketches of enriched node-link diagrams for visualizing code couplings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Map-based node-link approaches for visualizing code coupling in 2D or 3D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Example of an Design/Dependency Structure Matrix used for visualizing structural code couplings (similar to [232]). . . . . . . . . . . . . 4.6 Generic paradigms for visual comparison. . . . . . . . . . . . . . . . . 4.7 Variants of static node-link-based graph comparison approaches showing a comparison of two types of edges. . . . . . . . . . . . . . . 4.8 Matrix-based graph comparison using split cells and color-coded boxes for discerning edge types (similar to [299]). . . . . . . . . . . . 4.9 Alternative node layouts for node-link diagrams showing the same sample graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10 Three hierarchy visualization approaches arranging the nodes on a single linear axis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Sketched final layout of the node-link comparison approach. . . . . .
2 6
4.1
45 47 48 49 51 54 55 58 62 63 64
xiii
xiv
List of Figures
4.12 Visual comparison of three concepts of code coupling—inheritance (SD.Inh), aggregation (SD.Agg), and usage (SD.Use)—for JFtp applying the node-link approach. . . . . . . . . . . . . . . . . . . . . 4.13 Interactively manipulated variant of the visualization presented in Figure 4.12: zoomed event and net package, zoomed SD.Agg subdiagram, highlighted event package. . . . . . . . . . . . . . . . . . . 4.14 Available options for editing the selection of highlighted entities. . . 4.15 Example for highlighting by advanced selection options: selecting gui package, then deselecting all code entities that do not have incoming inheritance edges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.16 Example illustrating the interactive fusion of graphs: intersection of SD.Inh and SD.Agg based on summed edge weights. . . . . . . . . . 4.17 Applying edge splatting for JFtp (compare to Figure 4.12) using a topographic color scale to encode the edge density; image created with the parallel edge splatting tool. . . . . . . . . . . . . . . . . . . 4.18 The effect of edge splatting on dense areas of edge crossings. . . . . 4.19 Juxtaposed linearized node-link diagrams in a Cartesian and a radial coordinate system. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.20 Visual patterns in split linearized node layout indicating different graph structures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.21 Checkstyle project in the node-link approach comparing five concepts of code coupling: inheritance (SD.Inh), aggregation (SD.Agg), usage (SD.Use), evolutionary coupling by support (EC.Sup), and type I code clone coupling (CC.I ). . . . . . . . . . . . . . . . . . . . . . . 4.22 Checkstyle project with highlighted code entities in the api package that are target of inheritance dependencies. . . . . . . . . . . . . . . 4.23 Checkstyle project with enlarged and highlighted grammars package and enlarged api package. . . . . . . . . . . . . . . . . . . . . . . . 4.24 Checkstyle project focusing on structural dependencies with highlighted api package. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.25 Comparison of two hierarchies that are different on the finest level of detail (expanded ) but equivalent on a higher level (partly collapsed ). 4.26 Paradigms for hierarchy comparison according to the taxonomy of Graham and Kennedy [120, Figure 4]. . . . . . . . . . . . . . . . . . 4.27 Matrix-based hierarchy comparison by marking self-referencing cells. 4.28 Advanced matrix-based hierarchy comparison visualizing the similarity of modules as color-coded Jaccard Coefficients. . . . . . . . . . . 4.29 Final matrix-based hierarchy and graph comparison approach. . . . 4.30 JFtp project in the matrix approach contrasting the package structure against a clustered modularization based on structural and evolutionary data; the matrix-based graph visualization compares structural (blue cells) and evolutionary couplings (red cells). . . . . . . . . . .
. 66
. 68 . 69
. 70 . 72
. 76 . 76 . 77 . 78
. 81 . 82 . 83 . 84 . 87 . 89 . 91 . 92 . 93
. 95
List of Figures
4.31 Details retrieved on demand for the util package showing adjacent code entities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.32 JFtp with different levels of detail in the modularization: default view with no collapsed nodes (left) and adapted level of detail (right, equivalent to Figure 4.30). . . . . . . . . . . . . . . . . . . . . . . . 4.33 Controls for selecting the significance level thresholds for the adaptive level-of-detail algorithm (detail of Figure 4.30). . . . . . . . . . . . 4.34 Example illustrating the local sorting algorithm; descending pairs of self-referencing cells are indicated as green lines, ascending ones as dashed red lines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.35 Example and illustrated proof by induction showing the equivalence of minimizing ascending lines between self-referencing cells and the tanglegram layout problem. . . . . . . . . . . . . . . . . . . . . . . . 4.36 Visualization detail of a clustered modularization for the Azureus project without local sorting (top) and with local sorting (bottom). 4.37 Comparing the package structure and a clustered modularization for the Azureus project without global sorting (left) and with global sorting (right). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.38 Azureus project comparing the SCDG and the unfiltered ECDG00.0 having the package structure attached. . . . . . . . . . . . . . . . . 4.39 Azureus project comparing the SCDG and the filtered ECDG00.8 ; the package structure is contrasted to a clustered modularization based on combined structural and evolutionary data. . . . . . . . . . . . . 4.40 Examples for limitedly matching package structures and clustered modularizations: JUnit (left), JEdit (right). . . . . . . . . . . . . . 4.41 JFtp with multiple concepts of coupling visualized in the multi-matrix approach; legend for subcell division and coloring. . . . . . . . . . . 4.42 Interpretation process for deriving software engineering insights from the presented visualizations in the explorative study. . . . . . . . . 5.1 5.2
5.3 5.4
5.5 5.6
Illustrating example showing a congruent and non-congruent scenario between couplings and modularization. . . . . . . . . . . . . . . . . Computing correlations between concepts of code coupling by transforming coupling graphs into vectors and sampling them across multiple projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pearson correlations between different concepts of coupling sampled from all studied systems. . . . . . . . . . . . . . . . . . . . . . . . . Coupling-modularity congruence (top) and average couplingmodularity congruence (bottom) for each concept of code coupling summarized as boxplots across all sample projects. . . . . . . . . . Coupling-modularity congruence for each concept of coupling discerned by frequently occurring types of modules. . . . . . . . . . . Overlay of all congruence medians of the six diagrams in Figure 5.5.
xv
. 98
. 99 . 102
. 106
. 108 . 111
. 111 . 113
. 115 . 117 . 119 . 120 . 138
. 146 . 148
. 152 . 155 . 156
xvi
6.1 6.2
6.3 6.4 6.5 6.6 6.7 6.8 6.9
List of Figures
Three-staged process of interactive computer-aided component extraction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transformation of a coupling graph into a graph for solving the minst-cut problem; key entities and component assignments are indicated in green (original component) and red (extracted component). . . . Representation of a class in the prototype user interface. . . . . . . Prototype component extraction interface showing an extraction result for a small sample project. . . . . . . . . . . . . . . . . . . . . Main view of the improved interface showing the extraction results for a sample project. . . . . . . . . . . . . . . . . . . . . . . . . . . Tooltip showing detail coupling information on demand in the improved interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Boxplots of the relative modular and evolutionary independence for single concepts of coupling. . . . . . . . . . . . . . . . . . . . . . . Boxplots of the relative modular and evolutionary independence for single and combined concepts of coupling. . . . . . . . . . . . . . . Boxplots of the relative modular and evolutionary independence for filtered single and combined concepts of coupling. . . . . . . . . . .
. 168
. 173 . 179 . 179 . 183 . 184 . 190 . 193 . 194
LIST OF TABLES
2.1
MoJoFM clustering quality for a selection of clustering setups. . . . . 13
4.1
Available software development products that include a visualization of code coupling: node-link diagrams (NL), enriched node-link diagrams (eNL), or dependency structure matrices (DSM). . . . . . . . Implemented edge routing strategies and their summarized characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Categorization of identified visual patterns (number of participants in parentheses), their relation to graph structures and to software engineering tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summarized comparison of the two presented visualization approaches; differences are highlighted in italics. . . . . . . . . . . . .
4.2 4.3
4.4 5.1 5.2
5.3 5.4 5.5 6.1
Summary of conjectured relationships between modularity principles and concepts of coupling. . . . . . . . . . . . . . . . . . . . . . . . . Properties of the sample of software projects and their repositories (#Pa: number of packages; #V: number of classes and interfaces; Rep: repository type; #Tr: number of transactions; #Dev: number of developers). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of concepts of coupling considered in the study (compare to Section 3.3). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manually detected types of modules (packages) and the number of projects they occur in (at least 20 code entities). . . . . . . . . . . . Summarized congruence results for the conjectured relationships between modularity principles and concepts of coupling. . . . . . . . .
. 52 . 74
. 121 . 123 . 132
. 144 . 145 . 154 . 162
Sample projects selected by the participants for the user study (#V: number of classes and interfaces). . . . . . . . . . . . . . . . . . . . . 181
xvii
xviii
6.2
List of Tables
Selected set of combinations of couplings employed for evaluating the component extraction approach. . . . . . . . . . . . . . . . . . . . . . 192
CHAPTER 1 Introduction
If changing one module in a program requires changing another module, then coupling exists. —Martin Fowler, 2000 [102] Defining coupling by those hypothetical changes, multifaceted reasons exist why entities of a software system need to be changed together—coupling is indicated by different observable features of the system: Structure: A fragment of code is not an isolated description of an algorithm; a fragment of code rather depends on other fragments, for instance, by calling methods or accessing data. Changing the functionality or interface of one fragment may induce changing another. History: The history of a software project might reveal hidden dependencies not documented in the structure of the code: for example, imagine that whenever
1
2
1 2 3 4 5 6 7
/* * * @author fabian */ class A { String name ; B b = new B (); void doSomething () { b . doSomethingElse (); }
8 9 10 11
String toString () { return name ; }
12 13 14 15
1 Introduction
}
1 2 3 4 5 6 7
/* * * @author fabian */ class B { String name ; void doSomethingElse () { ... }
8 9 10 11
String toString () { return name ; }
12 13 14 15
}
Figure 1.1: Two Java classes related by multiple concepts of coupling.
a specific entity of the software was changed in the past, another had to be adopted accordingly. Hence, it is likely that changing the two together is also necessary in the future. Semantics: When adapting the specification of a software system, all entities that relate to the modified semantics need to be changed. However, these entities are not necessarily connected by the structure or the history of the system, but only implement similar semantics. These indicators need to be considered whenever an entity of the software system is changed because they hint at other entities that might have to be changed as well. This makes analyzing code coupling an essential part of program comprehension, which precedes changing the program, of impact analysis, which estimates the impact of a change, of re-engineering, which targets high-level changes for improving the architecture of a program, and of debugging, which tries to locate incorrectly changed code. Since hypothetically necessary co-changes cannot be directly measured, software engineers, instead, have to look at observable relationships between fragments of code that are likely to induce future co-changes—these connections between entities of code are called code couplings in this thesis. The term serves as a superordinate to other terms often used in a similar context, such as code dependencies, relationships, associations, links, similarities, or connections. Each form of observable relationship introduces a different concept of code coupling. Already very small pieces of code can be connected by multiple of those concepts, as the following example shows. Example 1.1: Consider two Java classes, A and B, like listed in Figure 1.1. Both classes do not include much functionality: they both have a class attribute name and override the toString() method. Moreover,
1.1 Modularity
3
some functionality is represented by the methods doSomething() and doSomethingElse(). These two classes are coupled by • usage: doSomething() of class A calls doSomethingElse() of class B; • aggregation: class A aggregates class B and thus relies on functionality of B; • code clones: the method toString() is identical for both classes and might need to be changed consistently; • ownership: both classes were developed by the same author, hence, rely on the same expertise or might include the same errors in reasoning. While usage and aggregation can be considered as structural concepts of coupling, ownership is a form of history-related coupling and code clones are connected to the semantics of the code.
Concluding this discussion, the following can be stated: Code coupling needs to be considered as multi-dimensional. This observation is the central idea and motivation of this thesis. Comparing and combining multiple concepts of code coupling promises to improve the understanding and to ease the development of software systems. In particular with respect to the modularity of a software system—arranging its code into higher-level structures—multi-dimensional code couplings can have a high impact.
1.1 Modularity For human beings, the only way to manage a complex system or solve a problem is to break it up. —Carliss Y. Baldwin and Kim B. Clark, 2000 [11] In their general theory on modularity, Baldwin and Clark [11] argue that complex systems, such as software systems, need to be modularized to make their complexity manageable. In research literature, multiple desirable attributes are connected to a good modularization of a software system: Comprehensibility and Abstraction: Modules hide complexity so that the system is easier to understand [11, 208] and can be developed on a higher level of abstraction [11].
4
1 Introduction
Changeability and Independent Development: Modules restrict the propagation of changes so that the system becomes easier to change [182, 208] and many developers can work in parallel on the project [11, 208]. Reusability and Flexibility: Modules group together dependent elements so that modules can be easily reused in other projects [182, 188] or replaced by more efficient implementations [11, 252]. Modularity is omnipresent in software development; looking at existing systems and programming languages, there exists a multitude of concepts that implement a form of modularity: In early days of programming, groups of functionality were called modules (Algol, Modula, Pascal ). But usually these modules refer to flat groups—for organizing the code hierarchically, directories (C /C++, PHP ) and packages (Ada, Java, SmallTalk ) are used. Also classes and interfaces as introduced in objectoriented programming or components and services can be considered as a form of modularization, however, carrying more semantics than just indicating a loose grouping of functionality. Changing the modularization of a system is rather simple: it is only a matter of changing its organization, not a matter of changing its semantics. As Parnas [208] points out, systems can be equal in behavior but different in their modularization. Hence, the modularization of a system can be improved independent of changing its functionality.
1.2 The Congruence of Coupling and Modularity In order to modularize a system, software developers need a criterion for grouping code entities together. Usually, the entities are compared to each other and those are grouped that are similar, connected, dependent, related, or in other words coupled by any concept of coupling. Hence, there is a multitude of criteria for modularization: for instance, those code entities are placed in the same module that structurally depend on each other [247], that are connected to the same design decisions [208], or that are related by the communication structure of the development team [74]. These modularity principles, more or less, are connected to couplings between code entities. Abstracting from the concrete principles, in each case, pairs of coupled entities should be placed into the same module while pairs of non-coupled entities can be spread across different modules. This implies that, in a good modularization, there exists certain congruence between the code couplings and the modularity: the couplings are assumed to mostly connect entities in the same module rather than in different modules. In general, the combination of code couplings and modularity can be considered as a central part of the architecture of a software system:
1.3 Objectives
5
Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.1 By considering history-related couplings even aspect of the environment and the evolution of the system can be partly reflected in the code couplings.
1.3 Objectives Usually, coupling is not treated as a multi-dimensional but one-dimensional construct, often consisting of only structural dependencies. There exist indeed some works that analyze different concepts of coupling (for details see Section 5.5.2 and Section 6.6.1), but more on an exemplary level than applying and comparing a larger number of concepts systematically. In contrast, this work is considering code coupling as a multi-dimensional construct and aims at providing the means for systematically analyzing these couplings. As a first step, the code coupling information should be made explorable through visualization. This is challenging because software systems are complex and easily contain hundreds of entities and thousands of couplings. What makes the problem even harder is the representation of multiple concepts of coupling—the concepts need to be compared to each other. Objective 1.1: Visualize different concepts of code coupling in modular software systems.
As argued above, code couplings are closely connected to the modularity of software systems. There exist multiple principles and guidelines for modularizing software, but it is not clear which modularity principles are applied in practice. In order to relate the couplings to the overall structure of the system, the congruence between code couplings and the modularity needs to be studied. Rather than providing the means for exploration by visualization, the congruence is required to be observed and measured in existing software projects in an empirical approach. Objective 1.2: Analyze the congruence between concepts of coupling and modularity. 1
ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of SoftwareIntensive Systems
6
1 Introduction
Feasibility Study
Chapter 2
Code Coupling
Chapter 3
Visual Comparison
Congruence
Component Extraction
Visually compare multiple concepts of code couplings.
Study the congruence between concepts of code coupling and modularity.
Extract software components based on multi-dimensional code couplings.
Objective 1.1
Chapter 4
Objective 1.2
Chapter 5
Conclusion
Objective 1.3
Chapter 6
Chapter 7
Figure 1.2: Overview of the outline of this thesis.
Understanding multi-dimensional code-couplings and their congruence to modularity can help developers in better modularizing their software: based on code coupling information, modularizations can be generated automatically or problems in existing modularizations can be detected. While there already exist many approaches that compute such modularizations [178], again the multi-dimensionality of code coupling is not yet explored systematically. Objective 1.3: Leverage the multi-dimensionality of code coupling for modularizing software systems.
These three general objectives should be addressed in this thesis. Hence, the central goal of this work is to provide a better understanding of different concepts of code coupling in particular context of modularity.
1.4 Outline The outline of the thesis reflects the threefold objectives as it consists of three main chapters, each addressing one of the objectives. The main chapters are framed by two introductory and a concluding chapter. Figure 1.2 provides an overview of this structure. As a starting point, Chapter 2 presents a feasibility study where two concepts of coupling—one related to structure, the other related to history—are contrasted in the application of automatically modularizing software systems. Questions of feasibility for further studies and lessons learned are discussed in detail.
1.4 Outline
7
Chapter 3 discusses code couplings in detail: it presents relevant application scenarios of code couplings, defines a data model for formally representing multidimensional code couplings, and introduces the specific concepts of coupling that are used throughout the thesis. The main chapters implementing the objectives are the following: • Chapter 4 (Objective 1.1) investigates the scalable visual comparison of code couplings. Two novel visualization approaches are proposed for two variants of the visualization problem. These approaches are implemented as interactive tools providing additional features to ease the comparison. Applying the visualization tools to coupling data yields first insights on the dataset. In general, the visualization approaches provide the means for exploring multidimensional code couplings. • Chapter 5 (Objective 1.2) analyzes the congruence of coupling structures and modularizations in an empirical study. A set of 16 open source software projects is investigated with respect to which concept of coupling is most congruent to the modularization of the respective system. Concepts from all three types of coupling—structure, history, and semantics—are systematically compared. The results provide evidence on how modularity principles are used in practice. • Chapter 6 (Objective 1.3) tries to leverage the multi-dimensionality of coupling in a practical application related to modularity: Code couplings are used to shape a software component that can be extracted for future, independent development. An algorithmic solution that processes code couplings is proposed and embedded into an elaborate user interface. Different concepts of coupling are evaluated separately and in combination for component extraction. Chapter 7 finally concludes the thesis by summarizing the major contributions, discussing limitations, and providing an outlook on possible impact of the work and future challenges.
8
1 Introduction
CHAPTER 2 Feasibility Study
Understanding multi-dimensional code couplings is a complex and multi-faceted research question. But when starting to directly approach the above, concrete objectives, first experience with comparing and leveraging multiple concepts of coupling had been already gained in an initial study. This study investigates two concepts of coupling for automatically creating modularizations of software systems. The two concepts are assessed by comparing the quality of the derived modularizations. Furthermore, combining both concepts in a simple approach shows how the multidimensionality of code coupling can be leveraged. Hence, the study is considered a feasibility study for the subsequent work; lessons learned significantly impacted later design decisions. The initial study is summarized in the following—details can be found elsewhere [23, 26].
9
10
2 Feasibility Study
2.1 Objectives Software clustering algorithms [178] generate modularizations of software systems, which partition the entities of a system into flat or hierarchically organized modules. Often, the coupling structure is used as a clustering criterion: tightly coupled code entities are grouped together. Software clustering is an unsupervised form of classification as clusters are not assigned particular semantics before clustering. As software clustering is an established field of research and an application where code couplings are used for modularizing software systems, it presents an appropriate scenario for gaining first experience with multi-dimensional code couplings. Structural code dependencies seem to be the most frequently used concepts of coupling for software clustering, but also some other concepts have been used. For instance, code entities can be clustered according to which entities changed together frequently in the past [37, 268, 269]. Even first steps have been made to integrate structural dependencies and such evolutionary co-change couplings in software clustering approaches [8, 241, 283]. But the comparison and integration of the two concepts of coupling seems to be only a secondary goal or byproduct in these works. Nevertheless, this research shows that it is promising to investigate these two concepts of coupling in greater detail. Objective 2.1: Compare and integrate structural dependencies and evolutionary couplings in the application of software clustering.
2.2 Experimental Design The study focuses on object-oriented software system, in particular, open source systems implemented in Java. The package structure reflects the modularization in such systems. Hence, in this context, software clustering means grouping classes and interfaces into a hierarchical package structure.
2.2.1 Dataset The set of sample systems that is used for clustering in the study consists of ten projects, namely, Azureus (Az), Checkstyle (Che), CruiseControl (CC), iText (iT), JEdit (JE), JFreeChart (JFC), JHotDraw (JHD), JUnit (JU), Tomcat (Tom), and Wicket (Wi). This set has been compiled from a list originally containing eighteen projects by excluding those projects that show questionable attributes of quality, such as uncommonly large package sizes, low comment ratio, or low numbers of users. Since the package structure of the sample projects is required to be of high quality
2.2 Experimental Design
11
as discussed below, imposing these requirements on quality becomes important. The selected projects are small to mid-size projects consisting of 103 to 840 classes and interfaces divided into 16 to 86 packages. Structural dependencies are retrieved from the executable bytecode (jar files) of the systems. Similar as in UML class diagrams [45], the following structural dependencies are discerned: inheritance (a class extending another class or implementing an interface), aggregation (usage of another class for defining a class attribute), and usage (other forms of structural dependencies, such as method calls, usage as a local variable, etc.). These couplings connect the classes and interfaces of the system, which can be formally modeled as a graph. The resulting graphs have non-weighted, directed edges (i.e., couplings) and are named class inheritance graph, class aggregation graph, and class usage graph. Additionally, the structural class dependency graph (SCDG) summarizes these concepts by aggregating the couplings of the three structural graphs. For computing evolutionary couplings, it needs to be retrieved which files were changed together in the past. Such information is stored in the code repositories of the projects, in this case, CVS or SVN repositories covering 1 to 9 years of development and involving 2 to 27 developers. Based on check-in transactions, pairs of files can be identified as being modified together. This information is used to compute two values for co-changed files that summarize their common evolution: first, the support value counts the plain number of transactions the two files were changed together; second the confidence value puts support in relation to the frequency of change of a particular file [301]—a high confidence value indicates that is was likely that, if one entity was changed, the other was changed as well. These couplings are mapped to classes and interfaces and represented in the evolutionary class dependency graph (ECDGkα ). The parameters k and α act as filters and specify the minimal strength of the evolutionary coupling required to be considered in the graph; in particular, k denotes a threshold that the support value must exceed and α a respective threshold for the confidence value. Example 2.1: The ECDG00.8 filters evolutionary couplings and only considers those couplings that have support value higher than 0 (this applies to all evolutionary couplings) and a confidence value higher than 0.8.
To combine the two concepts of coupling (structural and evolutionary data), the respective graphs are aggregated using graph union operations in two variants: The first variant, the simple union operation ∪, unites the set of couplings of two nonweighted graphs. In order to emphasize or weaken the influence of certain couplings, the second variant, the weighted union operation ∪[a,b,c] , additionally assigns different weights to the couplings of the aggregated graph: weight a to the couplings only
12
2 Feasibility Study
contained in the first graph, weight b to the couplings contained in both graphs, and weight c to the couplings only contained in the second graph. Example 2.2: SCDG∪[1,4,1] ECDG00.8 denotes a combined structuralevolutionary graph where the SCDG is united with the ECDG00.8 assigning weight 1 to the couplings that are either part of the SCDG or the ECDG00.8 and weight 4 to the couplings that are included in both graphs.
2.2.2 Clustering The study employs a clustering algorithm that generates modularizations of the software systems based on different coupling graphs. In particular, the software clustering tool Bunch [177, 193], which was evaluated as one of the best available software clustering tools [8, 178, 289], is used to generate all clustered modularizations. Bunch defines a metric that measures the quality of a modularization of a software system and optimizes the clustering with respect to this metric by applying a hill climbing algorithm. Recursive repetitions of this process produce a hierarchical clustering result. Containing random decisions, clustering need to be performed several times in each setup to stabilize the results.
2.2.3 Assessment Software clustering results are often assessed by comparing the clustered modularization to a reference modularization. This reference is considered the optimal solution and need to be of certain quality. In the study, the current package structure of the software projects serves as the reference modularization—as already mentioned in Section 2.2.1, projects having certain attributes of questionable quality were excluded from the study. Comparing a clustered modularization to the reference modularization requires a metric that quantifies the difference between two modularizations. MoJoFM [278], an established metric for this purpose, compares two non-hierarchical modularizations of the system by computing the minimal number of move and join operations to transform one modularization into the other. This number is then normalized so that the metric represents the similarity of the two partitions as a value between 0 (totally different) and 100 (equivalent). In the study, MoJoFM is used for comparing two hierarchical modularizations. Hence, one level for the clustered modularization as well as one for the reference modularization needs to be selected in a reasonable way: each level of the clustered hierarchy is compared to the lowest level of the package hierarchy, which carries the
2.3 Results
13
Table 2.1: MoJoFM clustering quality for a selection of clustering setups. Az
Che
CC
iT
JE
JFC
JHD
JU
Tom
Wi
avg
inheritance
30.2
46.0
54.3
51.1
42.0
35.4
37.2
28.5
32.8
51.2
40.9
aggregation
28.6
25.2
30.3
48.0
47.1
14.3
17.8
21.6
35.8
23.2
29.2
usage
52.4
52.0
51.2
66.3
63.5
40.6
33.1
33.5
54.5
49.3
49.7
SCDG
49.9
55.1
52.5
66.7
65.5
44.2
35.0
35.0
54.0
52.2
51.0
ECDG00.4 ECDG00.8
35.6
55.4
43.2
57.8
47.0
43.2
28.9
20.7
11.3
53.4
39.6
32.6
43.6
37.1
57.5
45.9
39.8
28.3
20.6
11.4
41.7
35.9
SCDG∪ECDG00.8
52.7
60.4
54.2
67.8
68.7
53.3
37.4
34.4
55.9
56.9
54.2
SCDG∪[1,4,1] ECDG00.8
52.7
60.5
55.4
69.0
71.1
54.4
38.4
37.1
55.4
58.8
55.3
Default1
16.3
11.5
8.7
42.2
15.7
1.8
3.3
3.3
4.1
2.3
10.9
most detailed information; the best MoJoFM value is taken as the clustering quality. Results are averaged per setup over the multiple runs of the clustering algorithm. Please note that, though normalized, MoJoFM cannot be used to compare the quality of clustering results across different software projects because the normalization is project dependent; only comparisons within a project are valid. As a point of reference, a baseline value can be computed by applying MoJoFM to a meaningless modularization where all entities belong to a single module (Default1 ).
2.3 Results The study consists of two parts: First, structural dependencies and evolutionary couplings are compared to each other with respect to their qualification for clustering. Second, both concepts of coupling are combined to improve the clustering quality. The results of the study are summarized in Table 2.1 and discussed in the following.
2.3.1 Comparison To compare the structural dependencies and evolutionary couplings, different coupling graphs and setups are used as the input for the clustering process: the three basic structural graphs (inheritance, aggregation, usage), the aggregation of the three (SCDG), and multiple filtering setups for the evolutionary graph ECDGkα with support threshold k and confidence threshold α. Table 2.1 (inheritance–ECDG00.8 ) presents the results in terms of MoJoFM values. For the evolutionary coupling graphs, only a selection of the best filtering setups is listed.
14
2 Feasibility Study
Looking at the four structural coupling graphs, on average usage dependencies (49.7) and the aggregated structural dependencies (SCDG: 51.7) achieve the best results on average. Inheritance (40.9) and aggregation (29.2) seem to be less effective for clustering, but still produce results reasonably better than the default clustering (Default1 : 10.9). In comparison to the structural dependencies, the best evolutionary ones (ECDG00.4 : 39.6 ;ECDG00.8 : 35.9) cannot compete with the high quality results of the aggregated structural dependencies (SCDG: 51.7), only with the somewhat lower quality of inheritance (40.9) and aggregation dependencies (29.2). Analyzing the results of individual projects, however, it can be observed that the evolutionary clustering quality is varying more than the structural clustering quality. For instance, the evolutionary quality is very low in the Tomcat project (ECDG00.4 : 11.3; ECDG00.8 : 11.4), but approximately as high as for the aggregated structural dependencies in Checkstyle (SCDG: 55.1; ECDG00.4 : 55.4), JFreeChart (SCDG: 44.2; ECDG00.4 : 43.2), and Wicket (SCDG: 52.2; ECDG00.4 : 53.4). In a quick analysis of these results, it appears that evolutionary couplings might not be valuable for software clustering when structural dependencies are readily available. But analyzing evolutionary couplings in greater detail, it turns out that evolutionary couplings—if filtered—are quite suitable for clustering as they mostly connect entities within the same package. The reason why they cannot directly compete with structural dependencies rather is their partially low data density: the percentage of entities that were never changed together with other files in the analyzed period of development is 38% on average although large spans of development are covered. This observation suggests the use of evolutionary couplings in addition to structural dependencies, not as an alternative.
2.3.2 Combination The union and weighted union operations (Section 2.2.1) provide a tool for combining the two concepts of coupling. Since the aggregated structural dependencies (SCDG) yield the best results in the first part of the study, only those are combined with different evolutionary coupling graphs. The analysis of the combined data sources is two-staged: First, the simple union is tested applying different filters on the evolutionary data. Then, the most promising evolutionary filtering setup is combined with structural data using the weighted union operation with different weighting schemes. Applying the simple union combination strategy already clearly improves the clustering result: as it can be retrieved from Table 2.1, the best combination enhances the clustering quality from 51.0 (SCDG) to 54.2 (SCDG∪ECDG00.8 ). Hence, the evolutionary data seems to be an add-on to the structural data. In the combination,
2.4 Lessons Learned
15
the high data quality of the evolutionary data pays off while its low data density is counterbalanced by the high data density of the structural data. For the weighted union operation, strengthening those couplings that are part of both the evolutionary and the structural graph further improves the clustering result (SCDG∪ECDG00.8 : 54.2; SCDG∪[1,4,1] ECDG00.8 : 55.3): in the best combination, SCDG∪[1,4,1] ECDG00.8 , these duplicate couplings are weighted four times more important than other couplings. A high percentage of duplicate couplings connecting entities of the same package explains the success of strengthening these couplings.
2.4 Lessons Learned The design process and the results of this study provide first experience for comparing and combining different concepts of coupling. This experience helps answering questions of feasible as well identifying challenges for follow-up research.
2.4.1 Feasibility Generally speaking, the results of the feasibility study are positive: First, it was feasible to model two different concepts of coupling as graph structures; having such unified data model, the graphs can be easily compared, combined, and used in the same application. Second, the design of the study prototypically shows how concepts of coupling can be compared when employed in a specific application: the concept of coupling are used independently and the quality of the results can be contrasted. Third, combining concepts of coupling seems to be valuable: already the aggregation based on simple graph union operations improves the clustering results. In general, the initial objective for the study (Objective 2.1) is met as structural and evolutionary couplings were compared and used together for software clustering. The positive evaluation of feasibility clearly suggests to further deepen this line of research.
2.4.2 Challenges Analyzing the limitations of the study and reflecting the gained experience, the following challenges can be identified: Explorability: In the study, the quality of a modularization is reduced to a single number. While this allows for comparing the results directly, this number cannot provide explanations why certain concepts are more suitable for specific applications. Making the couplings explorable by visualization might reveal further insights.
16
2 Feasibility Study
Direct Comparison: Comparing concepts of coupling in a specific application such as software clustering is only an indirect form of comparison. The results are hardly generalizable to other applications and the application might potentially introduce a bias towards one of the concepts. Hence, a challenge is finding a more direct way, besides visualization, for comparing concepts of coupling. Theory: The feasibility study takes a pragmatic approach: everything that improves the result is legitimate. But considering the different ideas and theories on characteristics of a good modularization, it is desirable to better connect the concepts of coupling to modularity theory. Multiple Concepts: In the study, only two concepts of coupling are contrasted and combined. Comparing and integrating more than two concepts presents a further challenge. Applicability: Though motivated and connected to practical applications, software clustering seems to be only rarely directly applied by software developers: the clustering algorithm proposes changing the whole modularization of the system without paying respect to possibly existing structures. Considering an approach for improving the modularity of a system that takes more care on practical constraints is preferable. These challenges provide further motivation for the research presented in the following chapters. While explorability is addressed by the novel visualization techniques (Chapter 4), a more direct comparison and a closer connection to theory is provided in a further empirical study (Chapter 5). Moreover, the application of component extraction (Chapter 6) focuses on a task that is narrower than software clustering but pays more attention to issues of applicability.
CHAPTER 3 Code Coupling
Analyzing multi-dimensional couplings in software systems is the leitmotif of this work. This chapter introduces such couplings in detail and prepares the ground for the subsequent analyses: the chapter briefly summarizes applications where code couplings have large impact (Section 3.1), defines a precise data model for modularized coupling structures (Section 3.2), as well as introduces and discusses all concepts of coupling relevant in this work (Section 3.3 and Section 3.4). Besides presenting the basic definition and concepts, also technical issues are reported such as the implementation of the data model and the concrete acquisition of the coupling data.
17
18
3 Code Coupling
3.1 Application Scenarios Considering fragments of code as coupled instead of as independent entities seems to be an essential, inevitable concept in software engineering; it has an impact on nearly every phase of software development: already use cases or requirements are connected to each other anticipating the later couplings of code entities; designing the software is about shaping code entities and connections in between; testing and debugging a software requires inspecting and following couplings to find and fix bugs; finally, for maintaining and extending a system, existing couplings need to be taken into account in order to change the system consistently. In broad strokes, the following list outlines a set of software engineering applications that are particularly impacted by code couplings. Change Impact Analysis: Predicting and analyzing the influence of code changes is known as change impact analysis. It is used for deciding how to change a system, for prioritizing test cases in the context of regression testing, or for identifying bug inducing changes [226]. Changes are propagated through some form of code coupling, for instance, based on the structure of the software [168], its history [303], or its semantics [214]. Hence, code couplings can be used for estimating the impact of changes. Software Modularity: Dividing a software system into smaller parts provides a modularization of the system. Software modularity can be related to different abstractions and levels thereof: methods and attributes are assembled into classes, interfaces and classes are hierarchically organized as packages, cross-cutting features form aspects, or larger parts of the software build subsystem or components. Independent of the abstraction, code couplings help to modularize a system, for instance, when identifying classes [230], when automatically clustering a system into higher-level modules [177], or when mining aspects [52]. Code Quality and Bug Prediction: The evaluation of code quality and the identification of bug prone code entities often involves software metrics. Among the proposed metrics in literature, many are based on specific forms of code coupling. For instance, coupling metrics [54] and cohesion metrics [53] are defined on the structural dependencies of the code. Bug prediction is realized based on such metrics [94] or based on metrics on other forms of coupling like evolutionary coupling [81]. Also social network analysis can be applied to code coupling structures in order to find error-prone code entities [41]. These applications have in common that they are not limited to the use of specific forms code coupling: they are open for integrating different concepts. For instance, software clustering has been successfully implemented based on couplings derived from the structure of software systems [177], on couplings from their history [268], and on couplings from the semantics of the code [154]. And as the feasibility study
3.2 Coupling Graph Data Model
19
mA mB
mC a
d mD
b
e
f code entity
mE c
g
h
i
coupling • color: type • strength: weight
module
Figure 3.1: Visualized example of a modularized code coupling graph including two concepts of coupling.
(Chapter 2) and other works [8, 241, 283] show, different concepts of coupling can also be leveraged in combination for software clustering. Among the three listed applications, software modularity draws the main attention of this work because of its fundamental significance for software engineering: only modularization makes complex systems, such as software systems, manageable, as Baldwin and Clark point out [11].
3.2 Coupling Graph Data Model The first step towards introducing the data is defining a formal model to represent it. Since code couplings form a graph-like structure consisting of entities and connections in between, the following definitions use notations similar to those used in graph theory. In particular, these definitions extend a graph G = (V, E) where V is a set of vertices (also called nodes or entities) and E ⊆ V × V a set of edges (also called relationships, connections, dependencies, couplings) between these vertices. The final data model is a construct called modularized multi-dimensional coupling graph, which aggregates, for a single software system, all data relevant in this work. Example 3.1: Figure 3.1 illustrates such a modularized graph containing two concepts of coupling. Nine code entities (a, b, . . . , i) are divided into five hierarchically organized modules (mA , mB , . . . , mE ). The root module is mA and contains two submodules (mB and mC ) but no code entities as direct descendants. Module mC is an example that directly includes a
20
3 Code Coupling
code entity (d) as well as two submodules (mD and mE ). The code entities are connected by weighted code couplings: while the strength of the line indicates the weight, the two different concepts are discerned by color. An arrow head encodes the direction of the couplings.
With intent, the data model described in the following is designed somewhat more abstract than necessary. The rationale is showing the openness and extensibility of the approach. For instance, though all software systems studied in this work are object-oriented systems, the data model abstracts from this programming paradigm—replicating the analyses for non-object-oriented systems would be possible without changing the data model and metrics building upon the model.
3.2.1 Code Entities The programming language provides a syntax that hierarchically organizes the code. The syntactical elements of the code are nodes in an abstract syntax tree, which are here called code entities. Definition 3.1 (Code Entity): A code entity is a syntactical unit of the source code of a software system.
Code entities form the atomic elements of this data model. They might represent, for instance, identifiers, expressions, blocks, or methods, but also high-level representations such as classes or interfaces. Although, the later focus is on these high-level entities, this wider definition already reflects that the data model is open for any kind of code entities and not limited to the object-oriented paradigm. A software system or any agglomeration of source code thus can be considered a set of code entities. An important requirement for a set like this is that code entities do not overlap, which means that a piece of source code is not represented more than once in the set. Definition 3.2 (Set of Code Entities): A set of code entities is a finite set consisting of n code entities V = {v1 , v2 , . . . , vn } where any pair vi , vj ∈ V (i 6= j) does not overlap with respect to the code v1 and v2 represent.
3.2 Coupling Graph Data Model
21
A set may consist of uniform types of code entities (e.g., only methods). But this is not a necessary condition, for instance, the classes and interfaces of a software system together form a non-overlapping set consisting of two types of code entities.
3.2.2 Coupling Coupling denotes relational information between two code entities. Such relational information can be mathematically modeled as a tuple. To allow different strengths of connection, a coupling may carry a weight, that is, a positive real-valued number— the tuple becomes a triple. Definition 3.3 (Coupling): A coupling is a triple e = (v1 , v2 , ω) ∈ V × V × R+ where V is a set of code entities. While v1 is called source and v2 target, ω denotes the weight of the coupling.
Couplings are per se directed, that is to say, pointing from one code entity to another. However, undirected couplings between v1 and v2 can be modeled as a pair of directed couplings e1 = (v1 , v2 , ω) and e2 = (v2 , v1 , ω). A concept of coupling agglomerates the coupling information related to a certain type of connection between code entities. For instance, structural dependencies should be discerned from evolutionary couplings. Hence, a concept of coupling can be defined as a specific set of couplings. Definition 3.4 (Concept of Coupling): A concept of coupling is a finite set of couplings EV ⊂ V × V × R+ defined on a set of code entities V .
As a consequence, a set of code entities V together with a concept of coupling EV forms a directed weighted graph, here called coupling graph. Definition 3.5 (Coupling Graph): A coupling graph is a directed weighted graph G = (V, EV )
22
3 Code Coupling
where V = {v1 , v2 , . . . , vn } is a set of code entities and EV a concept of coupling on V .
Such a coupling graph, however, only includes one concept of coupling. To integrate different concepts, the definition needs to be extended and, to indicate the difference, the graph is denoted as multi-dimensional. Definition 3.6 (Multi-Dimensional Coupling Graph): A multidimensional coupling graph is a graph G = (V, (EV1 , EV2 , . . . , EVm )) where V is set of code entities and (EV1 , EV2 , . . . , EVm ) a vector of concepts of coupling on V .
From the perspective of graph theory, this graph structure is a variant of a directed weighted multi-graph with labeled edges. The dimensionality of G is m, the number of contained concepts.
3.2.3 Modularity What is still missing in these definitions of graphs is a notation for modularity. Considering a module—a higher-level abstraction of code entities—as a plain set of code entities would only allow non-hierarchical modularizations. For hierarchical modularizations, it has to be possible to nest modules into modules: the modules and the code entities form a hierarchy where the modules are the inner vertices and the code entities are the leaf vertices. A module is described in the following as a tuple containing a set of submodules M and a set of code entities Vm . Definition 3.7 (Module): A module is a tuple m = (M, Vm ) where M = {m1 , m2 , . . . , mk } is a finite set of contained modules (submodules), Vm = {v1 , v2 , . . . , vl } is a finite set of directly contained code entities. Moreover, let V (m) := Vm ∪ V (m1 ) ∪ V (m2 ) ∪ . . . ∪ V (mk ) be the set of directly and indirectly contained code entities of m. It is required that Vm ∩ V (m1 ) ∩ V (m2 ) ∩ . . . ∩ V (mk ) = ∅.
3.2 Coupling Graph Data Model
23
The definition discerns directly included entities (the direct children of the module Vm ) from indirectly included entities (direct or indirect children of one of the submodules). The set V (m) summarizes both kinds of included entities. To build a hierarchical structure, code entities cannot occur more than once in the module hierarchy—this is expressed by stating that the intersection of the set of directly included entities and all sets of indirectly included entities has to be empty. Having defined a module, a modularization is just the decomposition of a complete system into hierarchically structured modules. To specify a modularization, only the root module and a set of code entities need to be assigned; the included entities of the root module match the given set of code entities. Definition 3.8 (Modularization): A modularization is a tuple MV = (mroot , V ) where mroot is a module (root module), V a set of code entities, and V (mroot ) = V .
A modularization itself is only a hierarchy with clearly discerned inner vertices and leaf vertices. The important step is to connect this modularization with a coupling graph. But if both, the graph and the modularization, are defined on the same set of code entities V , this step is straightforward. Definition 3.9 (Modularized Coupling Graph): A modularized coupling graph is a triple ˆ = (V, EV , MV ) G where G = (V, EV ) is a coupling graph and MV a modularization on V .
Analogously, a second variant of a modularized coupling graph is defined with multidimensional couplings. Definition 3.10 (Modularized Multi-Dimensional Coupling Graph): A modularized multidimensional coupling graph is a triple ˜ = (V, (EV1 , EV2 , . . . , EVm ), MV ) G where G = (V, (EV1 , EV2 , . . . , EVm )) is a multi-dimensional coupling graph and MV a modularization on V .
24
3 Code Coupling
In the graph visualization community, an additional hierarchy on the nodes of a graph is called compound graph [138]. Hence, a modularized multi-dimensional coupling graph can be classified as a directed weighted compound multi-graph with labeled edges.
3.2.4 Implementation In preparation for the tools and analyses of this work, the data model was implemented as an object-oriented data structure in Java. While, in the feasibility study, still a standard graph library was used as the main data structure, the subsequent visualizations and conducted studies require a more customized data structure that directly implements the above definitions. GraphML1 , an XML-based graph format, is employed to store the data. Different concepts of coupling therein can be distinguished by labeled edges. Although GraphML is not designed to hold a hierarchy additional to the graph, a hierarchy can be easily included by encoding it in the names of the vertices (code entities). For instance, x.y.z represents code entity z contained in module y, which is a submodule of the root module x. As an implemented alternative, hierarchies are stored in accompanying text or XML files. The data model was developed in a test-driven way—test cases were written before the code implementing the respective features. This fosters a good test coverage preventing bugs and warrants a certain code quality.
3.3 Concepts of Coupling According to Fowler [102], when the modification of a code entity demands the modification of another entity, then the two are coupled. Although such future common changes of two code entities cannot be foreseen precisely, different indicators in the code and its history hint at possible co-changes. Due to the different indicators, code coupling is considered a multi-dimensional construct in this work—the specific indicators form different concepts of coupling (Definition 3.4). The following paragraphs systematically introduce the concepts of coupling that will be analyzed in this work. The goal for selecting these was to cover a broad spectrum of relevant concepts that also could be retrieved with acceptable effort. In each case, a multitude of ways for transferring the concept into a metric existed; if possible, the standard or most straightforward approach of conceptualization was taken. Where particularly promising or where difficult to select a single definition, multiple conceptualizations are introduced. The number of different conceptualizations, 1
http://graphml.graphdrawing.org/
3.3 Concepts of Coupling
software project
coupling data
bytecode jar
structure DependencyFinder
• •
structural dependencies (SD) fan-out similarity (FO)
proprietary
• •
evolutionary coupling (EC) code ownership (CO)
• •
code clones (CC) semantic similarity (SS)
repository
source code
25
history
JCCD stemming and gensim
semantic
Figure 3.2: Overview of retrieving coupling data from a software project.
however, had to be limited for still being manageable in the following analyses. The final concepts are divided by the three categories: structure, history, and semantics. For each concept, it is discussed why it is an indicator of coupling (Coupling), why it is relevant (Relevance), how it is conceptualized in this work (Conceptualization), and how the necessary data is acquired (Acquisition). When retrieving structural and semantic couplings, only a single version of the source code is required. While it is easier, at least for Java projects, to extract structural couplings from the compiled bytecode of the system, semantic information can be retrieved best from the source code. In contrast, for recording historical information, multiple versions of the source code are needed, which can be extracted from the code repositories of the software projects. Figure 3.2 provides an overview of the data sources and the acquisition process.
3.3.1 Object-Oriented Systems The data model allows for representing different concepts of coupling in a graph structure. While the data model is a very general representation of a software system, discussing concepts of code coupling in the following, however, requires refining the terminology because some concepts depend on the programming paradigm used. In particular, Java systems are studied in this work, which implies the use of objectoriented terminology. Code Entities: Classes and interfaces are the atomic units of object-oriented systems—they form cohesive artifacts of code that are hard to split but can be moved freely (only visibility issues need to be addressed occasionally). Hence, classes and interfaces are considered as the code entities (Definition 3.1) of
26
3 Code Coupling
a system in the following. Moreover, inner or anonymous classes are not incorporated as entities because they are hard to deal with and are rather used for technical reasons than reflecting important design decisions [44, p. 161]. Instead, couplings related to inner and anonymous classes are assigned to the respective parent classes. Couplings: As a consequence, couplings (Definition 3.3) are weighted, directed edges between classes and interfaces. A set of edges being of the same kind forms a concept of coupling (Definition 3.4); multiple concepts are considered as described in the subsequent sections in greater detail. Modularization: Object-oriented systems are usually hierarchically organized into packages: a package may contain a set of classes and interfaces as well as further subpackages. Besides aspects of visibility, packages do not influence the runtime behavior of the system, but only provide a mechanism to structure the system. In the following, packages are equated with modules (Definition 3.7). The complete package structure is the modularization (Definition 3.8) of the system. Entities and packages contained in libraries are not considered as integral parts of the system: they are not represented in the data model. Hence, the whole software system—consisting of a set of classes and interfaces structured by packages and connected by different concepts of coupling—can be represented by a modularized multi-dimensional coupling graph (Definition 3.10). Since classes and interfaces are considered as elementary code entities in this work, only those structural dependencies are relevant that connect different classes and interfaces—dependencies within a single class or interface are too fine-grained and stay unstudied. But also dependencies between different classes and interfaces need to be lifted to a higher level of abstraction. For instance, an inter-class method call becomes a coupling in the data model connecting the two classes that contain the respective methods.
3.3.2 Structure The source code of every non-trivial software necessarily contains jumps such as conditional expressions, goto statements, or method calls. Hence, the statements of the software are not only connected by sequential order but also by these additional cross-connections. Besides those connections related to the control flow of a program, one can also look at the data flow of the software: accessing data that is declared elsewhere (e.g., as a global variable, an abstract data type, or a class) introduces another form of dependency related to the structure of the program; for example, a class accesses attributes of another class. Those connections that determine the static structure of the code can be conceptualized into code couplings in different ways. While the first variant presented in
3.3 Concepts of Coupling
27
the following, the structural dependencies, models them as direct dependencies, the second variant, the fan-out similarity, is an indirect interpretation.
a) Structural Dependencies (SD) Structural dependencies are those couplings in the structure of the code that directly connect two code entities, for instance, a method call or an access of an attribute. Here the term dependency is more suitable than the general term coupling: first, an entity really depends on another one because it cannot be executed without it; and second, the connection is inherently directed, which is also better reflected by the directed term dependency. Besides basic control flow and data dependencies, object orientation introduces higher-level structural dependencies such as inheritance or aggregation. In contrast to the more basic dependencies such as method calls, those abstract dependencies represent potential dependencies: they only provide special options to interact with the target of the dependency; these options might or might not be used. However, they still form a structural dependency because the program can neither be compiled nor run without the target of the inheritance or aggregation dependency. More specifically, structural dependencies are discussed in the following with respect to their characteristics as couplings, their relevance to software engineering, their specific conceptualization in this work, and their acquisition in practice.
Coupling Structural dependencies are indicators of future co-changes—hence, code couplings—because changing an element of the code can impact anything executed afterwards or may introduce constraints that need to be considered before. Such impact might ripple through control flow dependencies as well as data dependencies. For instance, adding a parameter to a method requires changing every caller of this method, or changing the initialization of a class attribute might falsify assumptions in other code entities that access this attribute.
Relevance As sort of natural code coupling, the impact of structural dependencies is nearly self-evident; they are used as a default whenever code fragments are to be put into a relation with each other. Just to give a few examples: Structural dependencies are important for designing software systems as Stevens et al. [247] suggest using them as central criteria for designing the modular structure of software systems; they are also main part of graphical design notations such as UML class diagrams [45]. Structural dependencies are used in software quality metrics [54] as well as in applications such as software clustering [177], aspect mining [181], bug prediction [94], code clone detection [152], and many others.
28
3 Code Coupling
Conceptualization Structural dependencies are conceptualized in this work based on the abstraction that is also used in UML class diagrams [45]: While inheritance and aggregation couplings are each assigned a distinguished role, all other structural dependencies are summarized into a third category, which is called usage. As direct structural dependencies already connect two code entities, the conceptualization as couplings is rather straightforward. Similar concepts of coupling have already been used in the feasibility study (Chapter 2)—the main difference is that couplings in the feasibility study are non-weighted initially (weight is only used for combining different concepts of coupling). Inheritance (Inh): A class that extends the functionality of another class, a class that implements the functionality of an interface, or an interface that extends another interface are directly connected with each other by the concept of inheritance. The direction of the dependency goes from the more concrete, extending or implementing entity to the more general, extended or implemented entity. Since multiple inheritance between classes is not possible in Java, inheritance dependencies between classes form a tree structure. Together with interfaces, the resulting structure, however, is not purely hierarchical but only acyclic because a single entity may implement several interfaces. Concept SD.Inh: Two code entities v1 , v2 ∈ V : v1 6= v2 are coupled (directed: (v1 , v2 , ω)) if code entity v1 extends or implements code entity v2 . The coupling weight is ω = 1. Aggregation (Agg): Classes and interfaces have attributes (also called fields or variables) that form a kind of global variable within the respective entity. When the attribute is declared static, it is the same for all instances of the entity; otherwise, it might carry different values for the instances. If the attribute is not of a simple data type (i.e., boolean, int, double, etc.), the class or interface is said to aggregate the respective complex data type, which can be a class or an interface. It is further considered as aggregation, if an attribute assembles multiple instances of another class or interface such as in form of arrays or collections. Multiple attributes aggregating the same other entity but having different names count as different aggregation dependencies; this is reflected by increasing the coupling weight for such dependencies. The direction of the dependencies goes from the aggregating entity to the aggregated entity. Concept SD.Agg: Two code entities v1 , v2 ∈ V : v1 6= v2 are coupled (directed: (v1 , v2 , ω)) if code entity v1 aggregates code entity v2 by having an attribute using v2 . The coupling weight ω is the number of attributes of v1 depending on v2 .
3.3 Concepts of Coupling
29
Usage (Use): There exist other structural dependencies between entities such as created by calling methods in other entities, using other entities for declaring or defining local variables, accessing attributes of other entities, or employing other entities as method parameters. These dependencies share the feature that they are all provoked by method declarations or bodies. To simplify the dataset, they are summarized as the concept of usage. The weight of a specific usage dependency is determined by the number of methods within the class or interface that uses the respective other class or interface. The direction goes from the using entity to the used entity.
Concept SD.Use: Two code entities v1 , v2 ∈ V : v1 6= v2 are coupled (directed: (v1 , v2 , ω)) if code entity v1 uses code entity v2 in a method as a local variable, a method parameter, by accessing an attribute, or by calling a method. The coupling weight ω is the number of methods of v1 using v2 .
Acquisition The bytecode of Java programs, which is the compiled source code that can be executed by a Java virtual machine, contains the resolved structural dependencies (in contrast, it would be harder to retrieve the information directly from the source code because code entities are not referenced therein by their fully qualified name). There exist tools for extracting these dependencies from the bytecode; namely, the tool DependencyFinder 2 is used to retrieve the dependencies as XML files in a special-purpose format. An additional, self-made XSLT script transforms these XML files into GraphML files, which can be fed into the described implementation of the data model.
b) Fan-Out Similarity (FO) In contrast to considering two entities as coupled when there is a direct structural dependency from one to the other, two entities can also be assumed to be related if they are connected to the same set of other entities. For instance, two entities calling methods of the same other entities have something in common: they depend on the same functionality, hence, might do something similar. This form of coupling is more a similarity than a dependency; it is rather undirected than directed. The idea is not only applicable to outgoing method calls, but to all forms of outgoing structural dependencies: instead of direct dependencies, the coupling describes a similarity in the fan-out of two entities—direct dependencies are transformed into indirect similarities. 2
http://depfind.sourceforge.net/
30
3 Code Coupling
Coupling Two entities having a similar fan-out with respect to structural dependencies are coupled because they are likely to change together: on the one hand, when the functionality they rely on or the interface of this functionality is changed, the two entities are also required to be changed; on the other hand, when the functionality implemented in one of the entities is changed, the other entity implementing a similar functionality might be impacted by this modification.
Relevance As a measure of coupling, fan-out similarity is not nearly used as much as direct structural dependencies. Though rare, one can find applications of this concept in different scenarios: For instance, Schwanke [236] introduces a software modularization approach that uses a similarity metric based on fan-out/fan-in for clustering. In a broader context, not considering fan-out for deriving couplings, the fan-out is used to describe the complexity of a class as a metric (e.g., cyclomatic complexity by McCabe [184], information flow complexity by Henry and Kufura [134], response-for-class metric by Chidamber and Kemerer [69]).
Conceptualization The fan-out of each code entity can be described as an ndimensional feature vector, each dimension representing a potential structural dependency to one of the (n − 1) other code entities or itself. A particular value of the vector is 0 if there is no structural dependency to the code entity represented by the respective dimension; otherwise, the value is the weight of the respective structural dependency. Then, the fan-out similarity of two entities v1 and v2 is computed based on the two feature vectors ~v1 and ~v2 representing the two entities. Among the many metrics proposed in literature for such purpose, the cosine similarity [254] was selected because it is the standard approach when only the directions of the vectors should be taken into account but not their lengths; the metric considers the size of the angle between the vectors as a measure of similarity expressed by the cosine: cos(~v1 , ~v2 ) =
~v1 · ~v2 k~v1 kk~v2 k
The dot product of the vectors is divided by the product of the length of the vectors. The cosine similarity is symmetric and the resulting values range from -1 (contrary: 180◦ angle) to 1 (equivalence: 0◦ angle). Since the vectors only contain non-negative values, however, the maximum angle is 90◦ —the minimum similarity value is 0. Since entities of third party source code and libraries are not considered in the data model, structural dependencies between project-specific entities and external entities are not modeled in the respective concepts of coupling. However, for the fan-out similarity, it would be interesting to also obtain the external dependencies
3.3 Concepts of Coupling
31
because the targets do not have to be modeled as entities. Hence, internal fan-out to project-specific code is discerned from external fan-out to non-project code. Based on the three forms of structural dependencies, also three forms of fan-out similarity are considered: inheritance (Inh), aggregation (Agg), and usage (Use). In each case, the respective structural dependencies are transformed into similarity values using the cosine similarity as described above. External and internal fan-out is treated separately. This leads to the following concepts of coupling discerned (E : external; I : internal), which are undirected because the cosine similarity is symmetric. Concept FO.InhE, FO.InhI: Two code entities v1 , v2 ∈ V : v1 6= v2 are coupled (undirected: (v1 , v2 , ω), (v2 , v1 , ω)) if they extend the same class or implement a similar set of interfaces. The coupling weight ω is the cosine similarity of the inheritance feature vectors.
Concept FO.AggE, FO.AggI: Two code entities v1 , v2 ∈ V : v1 6= v2 are coupled (undirected: (v1 , v2 , ω), (v2 , v1 , ω)) if they aggregate a similar set of code entities. The coupling weight ω is the cosine similarity of the aggregation feature vectors.
Concept FO.UseE, FO.UseI: Two code entities v1 , v2 ∈ V : v1 6= v2 are coupled (undirected: (v1 , v2 , ω), (v2 , v1 , ω)) if they use a similar set of code entities. The coupling weight ω is the cosine similarity of the usage feature vectors.
Acquisition Retrieving the indirect fan-out couplings uses the same XML output of DependencyFinder that contains all relevant structural connections, but applies a different XSLT script. This script converts each code entity into a feature vector where each feature represents the potential connection to one of the other code entities and stores the vector in an XML file. These feature vectors are read in by the Java implementation of the data model and transformed into a coupling graph by applying the cosine similarity measure.
3.3.3 History The past is a predictor of the future, at least, when assuming that things evolve continuously. Following this rationale, the community of mining software repositories
32
3 Code Coupling
investigates the history of software projects to make predictions on and support the future evolution of a project. Two key questions within this community are: Which files were changed together in the past? And who was responsible for these changes? Based on these two questions, two groups of concepts of coupling are presented in the following. c) Evolutionary Coupling (EC) A software developer implementing a feature or fixing a bug usually needs to change multiple files of the software system and, when done, checks in those files together into the software repository. Hence, the check-in transaction documents which files are changed together, in other words, they are co-changed or evolutionarily coupled. This information, however, might be flawed: it could be that it was not necessary to change particular files together (e.g., the developer did two tasks at the same time) or that the changes were not complete (e.g., the developer forgot modifying another code fragment). But such noise can be counterbalanced by considering long spans of development so that co-change information is based on multiple changes. Nevertheless, a basic problem remains: if a file does not get changed at all or has just been introduced recently, reliable co-change information is not available. Coupling Based on the predictive power of the history of a software project on its future development, historic co-changes are a predictor of future co-changes. Hence, evolutionary couplings form another concept of coupling. Relevance Together with the emergence of mining software repositories as a field, evolutionary couplings gained more and more attention over the last ten to fifteen years. Originally, Gall et al. [109] detected such couplings based on releases and change sets; later, analyses were extended to software repositories such as CVS [110, 302] or to fine-grained changes [101]. Evolutionary couplings have been applied in many scenarios, for instance, for change prediction [294, 303], bug prediction [81], aspect mining [63], or, as already mentioned, for software clustering [37, 268, 269]. Conceptualization Evolutionary couplings are conceptualized in this work like proposed by Zimmermann et al. [301] discerning two metrics of coupling: support and confidence. But before specifying these metrics, check-in transactions, which are used for deriving evolutionary couplings, have to be defined. Definition 3.11 (Transaction): Let T = {v1 , v2 , . . . , vk } be a set of code entities that were checked-in together into the software repository by the same developer, then T is called a transaction.
3.3 Concepts of Coupling
33
Each transaction that included changes to a particular pair of code entities adds support to the evolutionary coupling between the two entities. The according support metric counts the number of those transactions. Definition 3.12 (Support): Let v1 , v2 be two code entities and {Ti }li=1 a sequence of transactions, then Sup{Ti } (v1 , v2 ) = |{Ti : v1 , v2 ∈ Ti , 1 ≤ i ≤ l}| is called support of the evolutionary coupling between code entities v1 and v2 .
Based on the support (Sup) as a coupling weight, a first concept of coupling is formulated. Since the metric is symmetric (Sup{Ti } (v1 , v2 ) = Sup{Ti } (v2 , v1 )), the couplings are undirected. Concept EC.Sup: Two code entities v1 , v2 ∈ V : v1 6= v2 are coupled (undirected: (v1 , v2 , ω), (v2 , v1 , ω)) if they were changed together during development (Sup{Ti } (v1 , v2 ) > 0). The weight of the two according couplings reflects the number of common changes (ω = Sup{Ti } (v1 , v2 )).
When two code entities are changed very often, but only sometimes together, the support of the coupling between the two can be relatively high, and in particular higher than the value for two entities that changed rarely, but always together. To counterbalance for such unwanted bias, the number of co-changes reflected in the support metric needs to be normalized. An adequate reference for normalization is the total number of changes of a specific code entity v, which can also be expressed as the support value Sup{Ti } (v, v) (i.e., the number of transactions v is included). The normalized metric expresses the confidence in the evolutionary coupling. Definition 3.13 (Confidence): Let v1 , v2 be two code entities and {Ti }li=1 a sequence of transactions, then Sup{Ti } (v1 ,v2 ) if Sup (v1 , v1 ) > 0 {Ti } Sup{Ti } (v1 ,v1 ) Conf {Ti } (v1 , v2 ) = 0 otherwise is called confidence of the evolutionary coupling from code entity v1 to code entity v2 .
34
3 Code Coupling
Also confidence (Conf ) can be used for defining a concept of code coupling. But in contrast to the support, the confidence is not symmetric (not necessarily: Conf {Ti } (v1 , v2 ) = Conf {Ti } (v2 , v1 )), which leads to directed couplings that always exist in both directions but have different weights. Concept EC.Conf: Two code entities v1 , v2 ∈ V : v1 6= v2 are coupled (directed: (v1 , v2 , ω1 ), (v2 , v1 , ω2 )) if they were changed together during development (Sup{Ti } (v1 , v2 ) > 0). The weights of the two according couplings reflect the normalized numbers of common changes (ω1 = Conf {Ti } (v1 , v2 ), ω2 = Conf {Ti } (v2 , v1 )).
Evolutionary couplings have already been used in the feasibility study as a coupling graph, however, in a slightly different variant: while the couplings in the feasibility study are non-weighted, the two concepts defined above use confidence and support for weighting the couplings. In contrast to filtering the couplings by hard threshold values as done before, this allows finer graduations of coupling. Acquisition Extracting evolutionary couplings is based on a library originally developed for refactoring detection [275, 276]: the repository (SVN or CVS ) is cloned and mirrored into a database; file changes are mapped to check-in transactions (for CVS, where this information is not stored in the repository, a sliding window approach is applied to restore the transactions [302]). Based on these transactions support and confidence can be computed; thereby, branched versions and transactions with more than 25 changed entities are skipped. The latter is a standard technique for reducing noise induced by accidental co-changes [294, 301]. Coupling graphs based on support and confidence are finally stored as GraphML files. d) Code Ownership (CO) The software repository does not only record which files were check-in together, but also which developers were responsible for the changes. This information can be used to retrieve who owns the code (in terms of who changed it). This creates connections between code entities and developers. To transform these into couplings between code entities, the outgoing connections of two code entities can be compared, similarly as done for computing the fan-out similarity for structural dependencies: Two entities are coupled by ownership if they share the same or at least a similar set of owners. Coupling Code ownership is related to expertise on a specific aspect of the program: It can be assumed that a developer changing an entity has certain expertise
3.3 Concepts of Coupling
35
on this entity and the implemented functionality therein. Hence, entities with similar owners are connected by similar expertise. Such connection by code ownership is considered a concept of coupling because, changing an entity connected to a specific expertise, it is likely that entities sharing parts of this expertise need to be changed as well. Relevance Begel et al. [34] report that developers rate questions related to code ownership as most important among other team corporation questions; for example, developers want to know who is responsible for a feature. Connecting code entities and developers, code ownership information is used for improving the collaboration among developers such as finding the expert for a specific feature or problem [34, 194]; but the information can also be leveraged in other scenarios like predicting bugs [42, 190]. Bowman and Holt [47] introduce the idea of using ownership information to connect code entities: they compare high-level architectures based on code ownership to the actual architecture of the system and report reasonable congruence. Conceptualization Code ownership coupling is conceptualized similar to fan-out similarity: the ownership information is described as a vector for each entity; two entities are compared based on the cosine similarity. In a vector like this, each vector entry is a dimension representing a specific developer of the system; the value of the dimension indicates the respective strength of ownership. In a first, simple approach, it is just recorded whether a developer changed the entity or not. Hence, the value of the respective dimension is 1 if the developer modified the entity at least once; otherwise, the value is 0. This binary (Bin) interpretation of code ownership leads to the following concept of coupling. Concept CO.Bin: Two code entities v1 , v2 ∈ V : v1 6= v2 are coupled (undirected: (v1 , v2 , ω), (v2 , v1 , ω)) if they share common authors. The coupling weight ω is the cosine similarity of the binary ownership vectors. In a more elaborate approach, the strength of ownership is estimated more precisely: the number of changes to an entity committed by a specific developer is divided by the total number of changes to the entity. The result, thus, is a proportional (Prop) value between 0 and 1 measuring the percentage of changes to the entity the particular developer was involved in. Concept CO.Prop: Two code entities v1 , v2 ∈ V : v1 6= v2 are coupled (undirected: (v1 , v2 , ω), (v2 , v1 , ω)) if they share common authors. The coupling weight ω is the cosine similarity of the proportional ownership vectors.
36
3 Code Coupling
Again, the vectors only contain positive values so that the cosine similarity provides values between 0 and 1. Acquisition Code ownership information is retrieved from the same database that is built for extracting evolutionary couplings. For each entity, it just needs to be counted how often it is has been changed by which developer. These numbers are used to compute the binary and proportional ownership vectors, which are stored as XML files. Again, these vectors are read in by the implemented data model and converted into a coupling graph applying the cosine similarity metric.
3.3.4 Semantics The semantics of a program describes its abstract meaning. Code that is semantically similar is likely to be changed together when the semantics of a program is to be changed (e.g., by adding a feature or fixing a bug). While it is very hard to specify the semantics formally and precisely, one can approach the semantics informally based on heuristics. This is done in the following by retrieving semantically similar fragments of code (code clones) and by linguistically analyzing the vocabulary used in the source code (semantic similarity). e) Code Clones (CC) Code clones are fragments of equivalent or at least similar code, which were usually created by copy-and-paste operations. Different types of clones are discerned [228]: while type I clones are exact copies (except layout and comments), type II clones can also have variations in identifier names and types; further, type III clones allow structural differences and type IV clones do not constrain the structure of the code anymore but require semantic equivalence instead. Intuitively, a code clone is something like a bad smell : programming by copy-andpaste does not seem to be an elaborate approach as the developer does not need to fully understand the code; moreover, the functionality is implemented twice, which could affect maintenance efforts or increase the risk of introducing bugs. Nevertheless, code clones might have justified reasons of existence such as decreasing the efforts of developing new code, keeping the architecture simple, or improving runtime performance [228]. Coupling When clones cover multiple code entities, these are coupled: code clones usually need to be changed consistently so that changing cloned code in one of the entities requires changing the respective code in the others. For instance, when a bug is found and fixed in cloned code, it is likely that the bug also exists and needs
3.3 Concepts of Coupling
37
to be fixed in the other instances of the clone. The higher the common coverage of code clones between two entities, the more likely they need to be changed together due to clones. Relevance Detecting code clones is an active field of research; numerous approaches have been proposed [228]: they support program comprehension, aspect mining, extracting libraries, and other applications. Treating code clones as a form of coupling, code clone relationships have been visually analyzed on a high level of abstraction between different systems [173] or between multiple versions of a system [172, 292]. Conceptualization The conceptualization of code clone coupling is based on the clone coverage metric by Liviery et al. [173]. Given two code entities, the idea is to compute the percentage of the code that the two entities share. In contrast to the original version of the metric, which only counts the number of equivalent lines, the number of tokens (a token is an atomic entity of the programming language) is used in order to get more precise coverage values. The adapted coverage metric is defined as follows. Definition 3.14 (Clone Coverage): Let v1 , v2 be two code entities, let kvk denote the number of source code tokens of code entity v, and let cc(v1 , v2 ) be the tokens that are covered by shared code clones between v1 and v2 , then kcc(v1 , v2 )k µcc (v1 , v2 ) = kv1 k + kv2 k is called the clone coverage between code entities v1 and v2 .
Based on the clone coverage metric and a detected set of code clones, concepts of coupling are defined. In particular, two concepts are discerned based on type I and type II clones—type III and type IV clones are not considered because they are difficult to detect. Please further note that every type I clone is also a type II clone. Since the coverage metric is symmetric (µcc (v1 , v2 ) = µcc (v2 , v1 )), the resulting concepts produce undirected couplings (I : type I ; II : type II ). Concept CC.I: Two code entities v1 , v2 ∈ V : v1 6= v2 are coupled (undirected: (v1 , v2 , ω), (v2 , v1 , ω)) if they share type I clones. The coupling weight ω is the clone coverage (ω = µcc (v1 , v2 )).
38
3 Code Coupling
Concept CC.II: Two code entities v1 , v2 ∈ V : v1 = 6 v2 are coupled (undirected: (v1 , v2 , ω), (v2 , v1 , ω)) if they share type II clones. The coupling weight ω is the clone coverage (ω = µcc (v1 , v2 )).
Acquisition For detecting code clones, the Java code clone detection library JCCD [39, 38] is used in a tailored configuration and embedded into an extraction program. The program takes the source code of the systems (head revision in the repositories), retrieves type I and type II clones using JCCD, determines the number of tokens in each clone, computes the clone coverage metric as a similarity metric for each pair of code entities, and finally exports the similarity values as a coupling graph into a GraphML file.
f) Semantic Similarity (SS) Another way of approaching the semantics of the code is analyzing the natural language that is used in the code. While looking at code clones only considers the semantics represented by the structure of the code, identifiers and comments form partial descriptions of what the program is intended to do. But since the semantics of natural language is comparably hard to grasp as the semantics of the code, heuristics need to be applied to find semantically similar code entities. Statistical methods applied to the vocabulary used provide such means. Resulting connections between code entities are called semantic similarity or conceptual coupling.
Coupling Two code entities that use a similar natural language vocabulary can be assumed to implement a related feature. When extending or changing the specification of this feature, the two need to be modified together—hence, coupling exists between the two.
Relevance While earlier approaches mostly focused on the structure of the code, identifiers and comments gained more attention over the years. Not only that descriptive identifiers and comments are considered as a good coding style, methods from statistical natural language processing have been applied to connecting code entities: for instance, the vocabulary can be used for locating specific features in the code [180], for predicting the impact of changes [214], or for clustering software systems [154]. Poshyvanyk and Marcus [213] present a conceptual coupling metric and conclude: “the conceptual coupling captures new dimensions of coupling, which are not captured by existing coupling measures”.
3.3 Concepts of Coupling
39
Conceptualization For implementing semantic similarity as a concept of coupling, an approach by Kuhn et al. [154] is adopted. Extracting the vocabulary from the code provides a list of terms and the frequency of how often these terms occur in each code entity. In order to encode a code entity as a vector, each term is represented as a dimension and the specific value of the dimension is counting the frequency of the term. Once more, a code entity represented as a vector like this can be transformed into coupling by applying a similarity measure such as the cosine similarity. A direct comparison of the term frequencies, however, overrates terms that occur in many code entities—the influence of common terms in the corpus (i.e., the software system) needs to be decreased. To this end, tf-idf weighting (term frequency–inverse document frequency) [231], a standard approach in information retrieval, is applied to normalize the frequency vectors. The normalized vectors are used to formulate a concept of coupling. Concept SS.Tfidf: Two code entities v1 , v2 ∈ V : v1 6= v2 are coupled (undirected: (v1 , v2 , ω), (v2 , v1 , ω)) if they share a similar vocabulary. The coupling weight ω is the cosine similarity of the tf-idf document vectors.
Often in natural language, different words are used to describe the same conceptual entity. To summarize terms that co-occur frequently and hence are likely to have a similar meaning, Latent Semantic Indexing (LSI ) [83], another standard information retrieval technique, is applied to the tf-idf vectors. LSI creates new vectors with transformed dimensions, which form the basis for a second concept of coupling related to semantic similarity. Concept SS.LSI: Two code entities v1 , v2 ∈ V : v1 6= v2 are coupled (undirected: (v1 , v2 , ω), (v2 , v1 , ω)) if they share a similar vocabulary. The coupling weight ω is the cosine similarity of the LSI document vectors.
Acquisition The semantic similarity is acquired by a Python script using the libraries stemming 3 and gensim 4 : First, the script excludes the license text from each source code file and, to obfuscate every hint to the modularization of the system, the package name and the name of all ancestor packages. Second, camel-case words are split and stop words are removed (Java keywords and English stop words). Third, the remaining terms are reduced to their stem by applying the Porter stemming 3 4
http://pypi.python.org/pypi/stemming/1.0 http://radimrehurek.com/gensim/
40
3 Code Coupling
algorithm. Finally, the source code entities are represented as tf-idf and LSI document vectors (an LSI model with 30 dimensions is used) and finally stored in an XML file. Again, these vectors can be read in by the implemented data model and converted into a coupling graph applying the cosine similarity metric.
3.3.5 Other Concepts of Coupling The list of concepts introduced so far covers all concepts of coupling that are used in this work. Although the list includes many relevant concepts focusing on very different aspects, there exist further concepts that could have been included as well, but were not due to difficulties in data acquisition or considerations of scope. Dynamic Dependencies When studying the code of a software system without running it, structural dependencies only exhibit potential or estimated connections—it is not clear whether they are really used during runtime. For instance, in an object-oriented language such as Java, the information which method is called precisely can only be determined at runtime due to overriding of methods. Actually executed structural dependencies are called dynamic dependencies to distinguish them from the static structural dependencies discussed above. Dynamic dependencies show more realistic structural couplings, at least when recorded for a realistic execution of a system. Automated tests such as regression tests can provide such execution scenarios. Dynamic dependencies are mainly used for the same purposes as static structural dependencies, for instance, change impact analysis [226], software clustering [210, 291], or aspect mining [264]. But the application of dynamic dependencies sometimes falls behind the use of static dependencies—for coupling metrics, Briand et al. [54] stated in 1999: “The dynamic aspects of coupling between objects at runtime have barely been investigated and are not yet considered in practice.” However, there also exist applications that are based on information retrieved from dynamic analysis such as profiling or debugging. Nevertheless, dynamic dependencies are not considered in this work further because they are hard to retrieve for a reasonable number of systems: first, the system is required to include a significant number of automated tests; second, the system need to be installed and executed in an instrumented environment; third, large datasets of execution traces need to be processed to retrieve the couplings. Communication and Work Flow Discussing aspects of a software system, developers usually talk about specific code entities. When developers plan their next steps or a concrete change, such discus-
3.3 Concepts of Coupling
41
sions are recorded—at least partly—in their personal communication via e-mail or instant messaging, in bug-reports, or in feature requests. Hence, co-occurrence of code entities in such documents indicates possible future co-changes and can be considered as a further concept of code coupling. But communication and work flow information seems to be used rather for building developer networks [40, 67, 235] than for retrieving code couplings [136]. While it is possible to access developer mailing lists and issue tracking systems of many open source projects, the contained documents are difficult to process due to the involvement of natural language: references to code entities must be detected and correctly linked to the respective entities. Additional to these difficulties, two aspects that might be included in such communication couplings are already covered by other concepts of coupling: first, evolutionary couplings record which entities needed to be changed together in the past; and second, semantic similarity might grasp parts of domain-specific relations only expressed through natural language. Coupling beyond Code Entities Different concepts of coupling connect the code fragments of a software project. But a project does not only consist of code but also includes plenty of other artifacts like documentation files, architectural models, behavior diagrams, bugs, change requests, etc. and is related to external artifacts like websites, tutorials, blog posts, forum entries, or mailing lists. Some of these artifacts are directly linked to particular code entities; for instance, an activity diagram describes the behavior of a class or a tutorial article explains how to use a certain feature. Hence, the idea of coupling can be extended from code entities to general software artifacts. This is connected to software traceability [204, 243]—retrieving connections between the various artifacts of a software system. A tool that aims at exploring and leveraging this wealth of coupling information beyond code entities is Codebook [33, 34]. It integrates developers, change transactions, work items, files, and code entities into a single graph structure and provides a framework to mine this data. The framework intends to satisfy developers’ information needs, for example, by finding owners of particular features or by summarizing the activity related to a code entity. Other works focus on particular coupling relations between code and other artifacts, like relations between code and developers [194, 203], code and bugs or change requests [100, 242], or code and documentation [179]. Analyzing the coupling between arbitrary software artifacts, however, is beyond the scope of this thesis. Already in the limited scope of couplings connecting only code entities, the interplay between the concepts is yet largely unknown. Taking other artifacts into account would further increase the complexity of the analyzed problems. Nevertheless, some software artifacts unequal to code entities are indirectly
42
3 Code Coupling
considered by using them for deriving coupling relationships between code entities; for instance, check-in transactions determine whether code entities are evolutionary coupled.
3.4 Discussion This chapter provides an overview of the data that is in the focus of this work: multi-dimensional code couplings. In general, considering code as connected entities is an important concept in software engineering. As shown, such coupling structures can be represented as graphs, which are extensible towards discerning multiple concepts of coupling as well as towards modeling an additional modularization of the software system. Though limited, a broad spectrum of concepts of coupling for object-oriented software is introduced. These couplings cover well-established concepts like different forms of structural dependencies but also include more rarely used, yet promising concepts such as fan-out similarity or code ownership. A multidimensional coupling graph allows for representing all concepts in a single graph for a software system. Looking at the characteristics of coupling graphs, Myers [201] observed that structural dependency graphs share the properties of scale-free networks, which have a heavy-tailed degree distribution. Similar results are reported by Puppin and Silvestri [217] for networks between independently developed fragments of code and by Potanin et al. [215] for dynamic dependencies. For other concepts of coupling than static or dynamic structural dependencies, it is, however, not clear whether the respective graphs share similar characteristics. Studying couplings and comparing different concepts of coupling in closer detail is one of the main objectives for the remainder of this work.
CHAPTER 4 Visual Comparison of Code Couplings
Multi-dimensional code couplings hold a wealth of information. A first step towards unearthing this treasure is to make this information accessible. The information promises to increase the developers’ awareness of couplings and might enhance program comprehension or help preventing bugs. But exploring code couplings could also foster research, for instance, by providing support for generating hypotheses on the usage of code couplings or for presenting results of coupling-based analyses. Visualization is a way to communicate complex information, and hence, could provide the means for exploring multi-dimensional code couplings. Although much research has been done on visualizing graph structures like couplings, the sheer size of software projects and the multi-dimensionality (i.e., multiple concepts of coupling) of the dataset still present serious challenges. In particular, the combination of both challenges—scalability and multi-dimensionality—has not yet been studied sufficiently. This chapter presents two novel visualization approaches that both
43
44
4 Visual Comparison of Code Couplings
tackle this combination of challenges. The two approaches focus on different aspects of the problem and are based on two different graph visualization paradigms. This chapter is structured as follows: First, the state-of-the art in visualizing code couplings is discussed (Section 4.1), followed by a review of how to visually compare graph structures (Section 4.2). Then, the two visualization approaches are introduced: the first one is a node-link approach concentrating on comparing different concepts of coupling (Section 4.3); the second one is based on an adjacency matrix and includes a comparison of different software modularizations in addition to comparing code couplings (Section 4.4). An evaluation finally explores how visualizations like the proposed ones are used in practice (Section 4.5), and a discussion compares the approaches (Section 4.6).
4.1 Visualizing Code Couplings Visualizing abstract data like code couplings is part of the research area of information visualization (for a brief introduction see [129]). As the formal data model defined in Section 3.2 shows, code couplings could be represented as graphs. The visualization of graphs is a very active discipline and provides a broad spectrum of visualization approaches. Usually, graphs of code couplings consist of a large set of vertices. This premise somewhat limits the number of appropriate graph visualization approaches because many approaches run into scalability problems for an increasing number of vertices. Von Landesberger et al. [271] survey graph visualizations that are particularly applicable to large graphs. The following sections discuss graph visualization in the context of software visualization. Some aspects were already covered by surveys on software architecture visualization [114], on visualizing static aspects of software [64], or 3D software visualizations [262]. In particular, the two main paradigms in graph visualization— node-link diagrams and adjacency matrices—are introduced and compared (Section 4.1.1). Then, applications of node-link diagrams for visualizing code couplings are reported in detail (Section 4.1.2), followed by an equivalent discussion on adjacency matrices (Section 4.1.3). Finally, an outlook on implementations of these approaches in software development tools is provided (Section 4.1.4).
4.1.1 Graph Visualization Paradigms Graphs are usually drawn by representing the vertices of the graph as nodes (e.g., circles, rectangles), which are connected by edges depicted as graphical links (straight or curved lines). These so-called node-link diagrams are the most frequently used graph visualization approach, but are not the only paradigm for visualizing graphs: like graph data structures are often stored in adjacency matrices, they can also be
4.1 Visualizing Code Couplings
node-link diagram
45
adjacency matrix a
a reading direction
b
c
a b
b
c
c
Figure 4.1: Visualization of a graph following the node-link and the adjacency matrix paradigm.
visualized as matrices. For a graph consisting of n vertices, an n × n matrix represents the edge structure. An entry in a cell documents the existence of a particular edge that connects the vertices of the intersecting row and column. Drawing these entries as colored blocks creates a matrix-based graph visualization. In Figure 4.1, the two paradigms—node-link diagrams and adjacency matrices—are contrasted, both showing the same small sample graph. The two paradigms are applied in different software visualization approaches as well as they play an important role for the two visualization techniques introduced in this thesis. Node-link diagrams are a straightforward way to visualize a graph structure because the elements of the data structure are directly mapped to visual elements: vertices are mapped to nodes; edges are mapped to links. These direct mappings make node-link diagrams intuitive. In contrast, there does not exist an equivalent direct mapping for vertices in adjacency matrices because vertices are each represented by both a row and a column. Edges, however, are mapped again directly: each edge is represented by a color-coded cell of the visual matrix structure; the reading direction for the edges is specified by convention (here, from left to top). The readability of node-link vs. matrix diagrams has been studied by Ghoniem et al. [115]. In a user study with 36 participants, they measured the correctness and answering time with respect to seven simple tasks the participants had to solve with the graph visualization techniques. Graph size and density were varied systematically. Their results suggest that the matrix approach is more scalable because, for larger and denser graphs, matrices provided better results in most of the studied tasks. An exception was the task of finding paths, which worked better in nodelink diagrams for larger, sparse graphs. A follow-up study by Keller et al. [149] tested partly different task with 21 participants. In contrast to Ghoniem et al., they use real-world datasets instead of randomly generated graphs. Their results provide further evidence that node-link diagrams are more readable for small and sparse graphs and that matrix diagrams are more suitable for large or dense graphs (except of path-related tasks).
46
4 Visual Comparison of Code Couplings
There also exist combinations of matrix and node-link diagrams trying to leverage the advantages of both paradigms. MatrixExplorer [131] connects a node-link and a matrix representation of the same graph by interaction: techniques like brushing and linking help the user to seamlessly switch between the two representations. A technique to integrate both approaches is MatLink [132], where edges are encoded redundantly as matrix cells as well as links. Those links are drawn at the margins of a matrix as arcs connecting the rows of the matrix as well as the columns. In contrast, NodeTrix [133] combines both approaches without redundancy: while small matrix representations are used for representing dense parts of the graph (clusters and cliques), sparse edges connecting the clusters are drawn as links.
4.1.2 Node-Link Approaches Most of the approaches that visualize code couplings are based on node-link diagrams. The central design decision in such diagrams is the layout of the nodes and links because overlapping visual elements could significantly decrease their readability. The question of laying out a graph based on node-link diagrams has been studied in detail by the graph drawing community. A survey on graph drawing from the perspective of information visualization was written by Herman et al. [137]. Further references can be found in the textbook on graph drawing by Di Battista et al. [85]. A set of aesthetic criteria that conceptualize the readability of node-link layouts has been proposed and evaluated [218]: For example, the number of edge crossings should be minimized. Moreover, maximizing symmetries and reducing the number of edge bends are said to support the readability of node-link diagrams. Further criteria exist, not all, however, have been empirically evaluated. Graph layout algorithms usually try to optimize one or a set of these criteria. Besides aesthetic criteria, a hierarchical organization of the nodes may also help to create readable graph visualizations. In software systems, a hierarchy is usually provided by the modularization; in other scenarios or if required, a hierarchy can be created by applying hierarchical graph clustering like demonstrated in the feasibility study (Section 2.2.2). When visualizing large graphs, the hierarchy can be used for reducing the level of detail [92]: hierarchy nodes aggregate sets of graph nodes and thereby reduce complexity. While aggregation automatically leads to a loss of information, the hierarchy can also be leveraged—somewhat less invasive—for grouping nodes [105]. Such grouping can as well be leveraged for reducing visual clutter when bundling similar edges according to the hierarchy [12, 138]. UML Class Diagrams A quite established standard for modeling and depicting object-oriented systems is the Unified Modeling Language (UML) [45]. This visual language defines a set
4.1 Visualizing Code Couplings
47
of diagrams modeling the structure and behavior of software systems. Relational information is a central part of most of these diagrams and usually represents a sort of code coupling. Although the different types of UML diagrams may look quite different, all diagrams are based on the node-link metaphor. For instance, a UML class diagram as sketched in Figure 4.2 describes the classes and interfaces of a software system as rectangular boxes connected by a set of possible couplings like inheritance, composition, aggregation, or association. These couplings are distinguished by using different stroke styles and different types of arrow heads for drawing the links.
Figure 4.2: Representation of different concepts of coupling in a UML class diagram.
There exist many propositions for enhanced UML diagrams: Icons can be used for improving the distinctness of nodes in class diagrams [158, 227]. Some works tried to leverage the third dimension—just by using geons (simple 3D forms) instead of icons [142, 143, 144] or by using a 3D layout for the graph structure [91, 118]. While these approaches tackle the readability of the diagrams, others add extra information such as software metrics [261] or areas of interest [62]. In the case of UML class diagrams, some research has been conducted, which suggests that additional criteria are to be formulated to meet the specific requirements of visualizing software systems. In particular, Purchase et al. [219] observe certain differences between abstract graph representations and UML diagrams: While reducing edge crossings seems to be very important in both cases, arranging the nodes and edges onto an orthogonal grid might be more relevant in UML diagrams. Moreover, in UML diagrams, general aesthetic criteria are not supposed to be as important as in abstract diagrams [221]. Specialized guidelines have been proposed for drawing UML class diagrams including, among others, to semantically group nodes, to join multiple edges, or to place superclasses above subclasses [93, 287]. These specialized aesthetic criteria led to the development of adapted layout algorithms. For instance, adding semantic information by clustering the nodes of a class diagram based on their architectural roles and functionality seems to increase the effectiveness of a class diagram [238, 239, 295]. Another layout algorithm emphasizes the role of class hierarchies created by inheritance edges [124].
48
4 Visual Comparison of Code Couplings
Enriched Node-Link Diagrams UML class diagrams depict the design of a system at class level focusing more on the classes than on the couplings between them. Other approaches exist that apply the node-link approach to software visualization and add further information to the diagram. Many of these approaches target a high level of abstraction or larger excerpts of the system than class diagrams. For instance, SHriMP [249, 250] and its successor Creole [170] are visualization tools that integrate several views on a software system, among them node-link-based visualizations on package level. To reduce the complexity of such diagrams, D4AJava [212] first hides the coupling information, but allows adding relevant couplings interactively. Without hiding any of the information, couplings can be visualized in a radial layout applying hierarchical edge bundling [138, 257, 259]. E-Quality
Class Blueprints A
A
B
B
C
Figure 4.3: Two sketches of enriched node-link diagrams for visualizing code couplings.
Like for UML class diagrams, it is possible to visualize software metrics along with the graph structure. In addition to simple approaches that encode three metrics in the width, height, and brightness of nodes [164], more dimensions and even their evolution across multiple releases of the software system can be encoded in Kiviat diagrams (also called star plots, radar charts, or spider web diagrams) [211]. In their tool E-Quality, Erdemir et al. [95] combine the visualization of different software metrics by shape and color and other attributes with the visualization of different concepts of coupling (sketched in Figure 4.3): they discern seven concepts of static structural coupling by color, indicate direction with arrow heads, use thickness as an indicator of frequency, and discern inter-package edges from intra-package edges by stroke style. Other visualization techniques show more details including fine-grained coupling information below class level. For instance, Staples and Bieman [244] use the third dimension on demand for displaying method calls between classes laid out onto a two-dimensional plane. As a second example, Class Blueprints [90, 163] divide the fields and methods of each class into five categories, visualized in columns as parts of rectangular class representations (sketched in Figure 4.3). Links connect related
4.1 Visualizing Code Couplings
49
fields and methods, within classes as well as between classes. Also Dependency Viewer [284] allows browsing dependencies down to method level; the focus, however, are design principles for code couplings as suggested by Martin [182]. These principles are visually encoded as metric values in the boxes representing classes and in the color of the links connecting the classes. Map-Based Approaches As already discussed, the layout of node-link diagrams is essential for creating a readable visualization. At higher level of abstraction, the hierarchical modularization of a system may help to come up with an appropriate layout. It can be used for subdividing the drawing area and for creating an underlying map for the system. The original graph can be drawn on that map, like sketched in Figure 4.4, either in 2D or 3D. Developers might adapt much faster to a map-based layout because they are already familiar with the hierarchical structure of the system. 2D map A
a
3D map (software city)
B a
c b
c
b
Figure 4.4: Map-based node-link approaches for visualizing code coupling in 2D or 3D.
Some approaches exploit the map metaphor further and describe the software system as a city [6, 13, 150, 205, 246, 281] or as islands [155]. Applying this metaphor, following more or less a real-world model, promises a more efficient code exploration [229, 282]. The map itself, however, just visualizes the structure of the system, for instance, the package structure as a tree diagram [65, 246] or a treemap [64, 281]. Also other criteria like semantic similarity can be used to lay out the map [155]. While software cities are often used for visualizing (non-relational) software metrics [246, 281], the perspective of this thesis draws attention to how these representations can be exploited for visualizing code couplings. Drawing links onto a map (e.g., a treemap [98, 290]), in 2D as well as in 3D, leads to occlusion. If the coupling information is only sparse, this problem is not severe. Hence, showing a small selection of links in the visualizations does not significantly decrease their readability. Typically, those links are only shown for a particular entity on demand when interactively selecting the entity [6, 156, 281]. In 3D cities,
50
4 Visual Comparison of Code Couplings
couplings are usually represented as curved pipes connecting the tops of the buildings (as sketched in Figure 4.4). When considering a non-filtered coupling graph, the coupling information often is not sparse anymore. Wettel [281] as well as Caserta et al. [65] demonstrate how hierarchical edge bundling [138] can be applied in 3D on top of a map-based code visualization in this scenario. This approach still provides readable images when visualizing all couplings at once, not only a selection of couplings. Details like the exact route of a particular edge are, however, lost through the simplification of bundling. Related to drawing links on top of a map-based representation of the software system is the idea of drawing links on top of a source code editor—the code representation in multiple editor views can be considered as a partial map of the system. For instance, Davis connects code entities in juxtaposed editor views by links [82]. In the IDE prototype Code Bubbles [48], the editor views are connected themselves by links indicating method calls. CodeCanvas [84] uses the idea of a code map as the basic layout of an IDE; similar to software cities, excerpts of coupling information such as stack traces are laid over on demand.
4.1.3 Adjacency Matrix Approaches Due to their ability of visualizing large and dense graphs, adjacency matrix approaches are suitable for depicting code coupling information. During the last decade even a de facto standard for such visualizations has been established, the Dependency Structure Matrix (DSM). It originates from the Design Structure Matrix used in engineering for managing design and work dependencies [248]. These matrices are standard adjacency-matrix-based visualizations of graphs. Baldwin and Clark [11] add modular structures to those matrices and discuss this approach as a general methodology to manage complex systems (Figure 4.5): modules are represented as blocks of rows and columns—intra-module dependencies become discernible at a glance (Figure 4.5, orange boxes). Following the ideas of Baldwin and Clark, the Design Structure Matrix was also applied to modular software systems [35, 141, 160, 165, 174, 175, 232, 252]. In software engineering applications, these matrices are mostly called Dependency Structure Matrices (also: DSM ) and depict structural couplings. Besides reflecting the modularization of the software system, they help revealing unwanted cyclic dependencies [35, 165] and can be used for checking the consistency of the architecture and the implementation [141, 232]. Some works enrich the original approach, for instance, by providing interactive features such as expanding and collapsing hierarchy nodes [232], by using color-coded or weighted cells like depicted in Figure 4.5 [35, 232], or by including detailed dependency visualizations in the cells [165].
4.1 Visualizing Code Couplings
1
layer 1 layer 2
Class 1
1
Class 2
2
Class 3
3
Class 4
4
Class 5
5
2
3
3
5
5
4
5 1
2 1
1
51
3 5
Figure 4.5: Example of an Design/Dependency Structure Matrix used for visualizing structural code couplings (similar to [232]).
The usefulness of Dependency Structure Matrices for understanding and developing software systems has been evaluated for different use cases [160, 174, 175, 252]. Beyond depicting structural couplings, many works use adjacency matrices to depict other coupling information, for instance, evolutionary couplings [59, 266, 277], semantic similarity [154], or code clones [173]. Van Ham [267] shows how zooming can be implemented to further increase scalability of matrix-based coupling visualizations: leveraging the hierarchical structure of software systems, multilevel semantic zooming allows browsing large graphs, as van Ham demonstrates with a call graph consisting of about 25,000 nodes. Abdeen et al. [1], in contrast, handle large systems by focusing on a single package and create a form of matrix coupling visualization for the package, which they call Package Reference Fingerprint.
4.1.4 Software Development Tools There exists plenty of tools for modeling software, for instance, tools that support UML diagramming such as ArgoUML1 , Rational Software Architect 2 , or Microsoft Visio 3 . Also visualization tools for architecture understanding have been analyzed and tested in research prototypes, and are step by step adopted by industry [260]. Table 4.1 provides an overview of a selection of product that include some form of code coupling visualization—additional information can be found on the listed web pages and, for some of the products, in supplementary scientific publications. While in some of the systems, such as Visual Studio or Sonar, visualizing coupling is only a minor feature, other products are built around the visualization of code couplings, such as Imagix 4D, Lattix, or SolidSX. 1
http://argouml.tigris.org/ http://www.ibm.com/software/rational/products/swarchitect/ 3 http://office.microsoft.com/en-us/visio/ 2
52
4 Visual Comparison of Code Couplings
Table 4.1: Available software development products that include a visualization of code coupling: node-link diagrams (NL), enriched node-link diagrams (eNL), or dependency structure matrices (DSM). Company
Product
Description
NL
eNL DSM Reference
ARiSA
VizzAnalyzer/3D
code analysis
×
Architecture Analysis
architecture analysis
×
×
–
Structure101
architecture analysis
×
×
–
Sotograph
architecture analysis
×
Imagix 4D
code analysis
×
IntelliJIDEA
IDE
Klocwork Architect
architecture analysis
Lattix
architecture analysis
NDepend
architecture analysis
×
Understand
code analysis
×
SolidSX
architecture analysis
Sonar
code quality
Visual Studio
IDE
[206]
arisa.se
Coverity coverity.com
Headway Software headwaysoftware.com
hello2morrow
–
hello2morrow.com
Imagix
×
–
imagix.com
Jetbrains
×
–
jetbrains.com
Klocwork
×
–
klocwork.com
Lattix
×
[232]
×
–
lattix.com
NDepend ndepend.com
SciTools
–
scitools.com
SolidSource
×
[138, 258]
solidsourceit.com
SonarSource
×
–
sonarsource.com
Microsoft microsoft.com
×
–
4.2 Visual Graph Comparison
53
From the perspective of the applied code coupling visualization technique, three different groups of tools can be distinguished: Simple Node-Link Diagrams: Applying a standard node-link approach without adding any use-case-specific extension is a common form of visualizing code couplings among the listed tools. Sotograph, Imagix 4D, Klocwork Architect, NDepend, SciTools Understand, and Visual Studio all use some sort of hierarchical layout algorithm for their dependency graphs, where entities are arranged in layers by the algorithm. In contrast, ARiSA VizzAnalyzer/3D shows coupling graphs as 3D diagrams. Enriched Node-Link Diagrams: Some of the tools, however, integrate node-link diagrams that are enhanced further. For instance, Coverity Architecture Analysis, Structure 101, and Imagix 4D use complex, interactive node-link layouts based on nested boxes representing packages. They furthermore employ different link styles for different forms of coupling. Aggregated dependencies are explorable through additional list views in Coverity Architecture Analysis and Structure 101. SolidSX also employs the hierarchy of systems, however, as an addition to a radial node-link layout; it applies hierarchical edge bundling as proposed by Holten [138] for visualizing the couplings. Dependency Structure Matrices: Dependency Structure Matrix approaches are implemented in six of the listed tools. While the main feature of Lattix is the matrix visualization, the other three tools use such a visualization only as an add-in to other functionality, Coverity Architecture Analysis, Structure 101, and NDepend even providing competing node-link visualizations of the dependencies. Another difference between Lattix and its competitors is that Lattix focuses on imposing design rules such as layered architectures while others advertise their tools with the use case of cycle detection. The adoption of code coupling visualization approaches in commercial tools shows a certain demand for those techniques in practical software engineering. Telea et al. [260] confirm this demand but also report unsolved problems and open challenges: First, those visualizations need to be tightly integrated into the IDE, which is not always the case up to now. Second, some of the visualizations still need too much manual tuning and customization. Finally, tedious, manual data extraction could be a major obstacle.
4.2 Visual Graph Comparison The unique focus of this thesis is that code couplings are considered a multidimensional construct. As the previous discussion shows, there has been much research on visualizing those couplings. But these works usually only consider one
54
4 Visual Comparison of Code Couplings
concept of coupling, not several. They fall short of showing difference between multiple concepts. Visualizing multiple concepts of coupling instead, however, introduces a set of new challenges that need to be addressed: First of all, the amount of information to encode is multiplied by the number of concepts considered. Moreover, the information does not only have to be readable, also different concepts of coupling need to be clearly distinguished by means of visualization. Comparing concepts of coupling should be easy. Hence, the central part of the visualization problem is the comparison of different concepts of coupling. From the perspective of graph drawing this problem can be translated into the problem of comparing different types of edges in a graph structure or drawing a graph with labeled edges. A further alternative is considering the problem as a graph comparison where the mapping of vertices between the graphs to be compared is given. When the compared graphs, moreover, follow a temporal sequence, these are called dynamic graphs—many visualization techniques are available for visualizing the evolution of graphs. Three widely used generic paradigms exist for visually comparing entities [28, 116], which are illustrated for line diagrams in Figure 4.6: Maybe the simplest one is to juxtapose the visualizations that need to be compared, an approach also called small multiples. In this case, the visual objects that represent the different semantic entities may, however, be far apart and therefore hard to match by the reader. Bringing these different representations together leads to an overlay approach, which is also referred to as superposition. Here, the visualizations overlap each other, often distinguished by color. But overlays could produce visual clutter. This can be avoided by aggregating the data that should be compared and simply presenting a fusion. Since the process of aggregation is likely to come along with losing some of the information, often the original information is visualized as well—the fusion approach is a form of explicit encoding of the difference. juxtaposition
overlay
fusion
Figure 4.6: Generic paradigms for visual comparison.
In the following, visual graph comparison and dynamic graph visualization approaches are presented implementing different comparison paradigms. These approaches are either based on static or animated node-link diagrams, adjacency matrix visualizations, or aggregate statistics on the graph structure.
4.2 Visual Graph Comparison
55
4.2.1 Static Node-Link-Based Comparison For graph comparison—and recently also for dynamic graph visualization—static node-link diagrams are used in various forms. The adjective static here distinguishes those diagrams from animated diagrams. Figure 4.7 provides examples and subdivides these static node-link diagrams into four categories, which provide the outline for the following discussion. Combinations of categories are possible and can be found in some visualization techniques. juxtaposed
link type
stacked
edge-type nodes
a
a
a b
c
a
a
b
b
c
c
a
b
c
b
juxtaposition
c overlay (fusion)
b
c overlay (fusion)
fusion
Figure 4.7: Variants of static node-link-based graph comparison approaches showing a comparison of two types of edges.
Juxtaposed Diagrams The easiest way of comparing two graphs is to juxtapose two standard node-link diagrams (Figure 4.7, juxtaposed ). This approach works as well for comparing multiple types of edges or for visualizing dynamic graphs; if necessary, more than two diagrams can be placed side-by-side. For instance, Barsky et al. [15] provide a tool for comparing juxtaposed graphs. Also Andrews et al. [7] work with juxtaposed diagrams for comparing business processes. Both, however, also include some form of overlay approach, which is discussed later. When comparing juxtaposed diagrams, multiple representatives of the same vertex need to be retrieved instantly across the diagrams. To this end, it is desirable to choose a constant node layout for all diagrams [97, 116], as it is also demonstrated in Figure 4.7 (juxtaposed ). The TimeArcTrees approach [121] even goes a step further and organizes the nodes on a linear axis. This simplifies the layout and nodes can easily be retrieved by following a horizontal line. A similar approach is applied by the TimeSpiderTrees technique [60], which visualizes a sequence of graphs as nested radial node-link diagrams—multiple representatives are placed on the same radial line of the circle.
56
4 Visual Comparison of Code Couplings
Juxtaposed diagrams can be combined with the fusion paradigm: an alternative to choosing the same node layout is connecting identical nodes across juxtaposed diagrams by additional links [86]. Link Type Integrating different types of edges into a node-link diagram for comparison can be also realized by employing different types of visual links—each visual type representing a different edge type. Discerning visual features might be, for instance, the color, stroke, arrow heads, or labels of the link. Figure 4.7 (link type) illustrates this approach showing two types of edges, one represented by blue, continuous lines with non-filled arrow heads, the other by red, dashed lines with filled arrow heads. A prominent example where such a technique is applied in software visualization are UML class diagrams [45] (Figure 4.2). The technique of using different link types can be classified as an advanced overlay approach—different types of edges are integrated (without being aggregated) into the same diagram, but direct overlap of links is avoided. Erdemir et al. [95] (Figure 4.3, E-Quality) also include some fusion aspect into this approach: they order different concepts of coupling by their importance and if two entities are connected by multiple links only the most important one is shown. While different link types are often applied parenthetically, some research particularly specializes this approach towards the application of comparing graphs: For instance, Andrews et al. [7] juxtapose three graphs—the two graphs to compare at the sides and in the middle a merged graph with different types of links. The source of the nodes in the merged graphs can be encoded in their color. Similar approaches showing color-coded differences in merged graphs are also used for diagram differencing, for instance, for comparing multiple version of UML class diagrams [187, 297]. Archambault [9] extends the approach of color-coded merged graphs by summarizing those subgraphs that are only contained in one of the original graphs. Merged pairs of subsequent graphs can be used for visualizing a dynamic graph—these diagrams are then juxtaposed or presented as an animation [10]. Stacked Diagrams Another overlay-based node-link approach are stacked diagrams (Figure 4.7, stacked ), usually drawn as three-dimensional graphics. In such an approach, the nodes can be exactly aligned, building stacks of nodes [49]. However, when the compared graphs are too different and only share a small set of nodes, it might be easier to just connect—instead of stacking—the equivalent nodes in the layers by additional links [17, 107]. This introduces elements of a fusion approach into these overlay-based diagrams. Using these links, not only two graphs can be compared, but also relations to other visualizations might be represented [73].
4.2 Visual Graph Comparison
57
Edge-Type Nodes A pure fusion approach introduced by Pretorius and van Wijk [216] is to represent each edge type as a node, additional to the normal nodes (Figure 4.7, edge-type nodes). In these diagrams, each vertex is represented twice, once on the left vertical axis, once on the right. An edge connecting two vertices is now drawn as two links from left to right, the first link connecting the source node with the node of the edge type, the second connecting the node of the edge type with the target node. Pretorius and van Wijk integrated this approach in a highly interactive tool including advanced highlighting techniques that allow complex graph queries.
4.2.2 Animated Node-Link-Based Comparison Animated node-link diagrams are usually applied for showing temporal changes of graphs (dynamic graph drawing). One graph is shown after the other, normally making changes traceable by animated transitions. According to Gleicher et al. [116], animation can be considered as temporal juxtaposition because it requires the user, like in normal spatial juxtaposition, to memorize information for comparison. Applied to visualizing code couplings, animated node-link diagrams are particularly suitable for visualizing the evolution of couplings across different revisions or releases of a system (e.g., [36, 68, 72, 203]). Preserving the mental map [192] of the graph, which the users form in their minds while watching the animation, is considered a primary goal for animated nodelink diagrams [220]. Analogous to choosing the same node layout in juxtaposed or overlaid diagrams, a constant node layout can be applied to the whole sequence of graphs. Moody et al. [196] call this approach flip book, in contrast to movies, where nodes are free to move. This technique could be preferable for longer sequences or significantly changing graphs. The challenge, however, is not destroying the mental map when moving the nodes. For computing the layout of the moving nodes, two main approaches exist: offline and online dynamic graph drawing [106]. In the offline variant, the whole sequence of graphs is known before starting the animation (e.g., [88, 96, 157]). In contrast, the online variant only considers changes in the past for computing the layout—no assumptions on future changes are made (e.g., [105, 106]).
4.2.3 Matrix-Based Comparison Graph comparison can be implemented based on matrices by using each cell of the matrix for representing different graphs or different types of edges: Melville et al. [189] explore an overlay approach where differently colored cells (representing different types of edges) are stacked like sheets of paper partly overlapping each
58
4 Visual Comparison of Code Couplings
other. In contrast, Zeckzer [299] integrates a fusion aspect: additional to colorcoding, each cell is divided into multiple parts, each part representing a different type of edge. This approach is illustrated in Figure 4.8 visualizing nine different types of edges. a
b
c
a
b c
Figure 4.8: Matrix-based graph comparison using split cells and color-coded boxes for discerning edge types (similar to [299]).
Stein et al. describe a very similar matrix-based approach, however, for the application of dynamic graph drawing [245]. The time-dependent relational information is represented as colored pixels on folded time lines in the cells of a matrix. The color shades of the subcells are used for representing edge weights. Various folding strategies can be applied to consider the characteristics of different temporal patterns. Similar to this approach, also bar charts [293] or complex line graphics [50] can be used for representing the time dimension in the cells as well. A somewhat different dynamic graph visualization approach that can also be considered as a matrix-based approach is the TimeRadarTrees [58] technique. It is a radial visualization where each graph in the sequence of graphs is represented as a annulus. The main circle only provides an overview of the incoming edges of the nodes in kinds of adjacency lists. The full details are given by radial thumbnails around the circle, which form a distributed adjacency matrix representation of the graph. Timeline Trees [55] is the non-radial counterpart of the TimeRadarTrees visualization. (Although the tool is not described as a graph visualization approach, it can be easily extended to dynamic graphs analogously to TimeRadarTrees.)
4.2.4 Aggregation-Based Comparison An indirect form of graph comparison is to first aggregate and simplify the graph information before visually comparing it—a heavy form of fusion approach. The ManyNets technique [104] is an example: In a tabular representation, statistics of the graphs are summarized using different forms of bar charts. While this view is intended to provide overview, detailed node-link diagrams can be opened on demand. A related approach is NetVisia [119]: Instead of summarizing the whole graph, only the graph information of each vertex is aggregated with respect to a certain metric.
4.2 Visual Graph Comparison
59
Then, the metric values for all nodes and multiple graphs are presented in a heatmap representation. The original graph information itself is again available on demand— here, as a matrix visualization.
4.2.5 Limitations of Existing Approaches It is easy to compare two small graphs against each other—it is probably sufficient to apply a straightforward approach such as visualizing the two graphs in juxtaposed node-link diagrams with a constant node layout. Finding an appropriate visualization, however, gets challenging when the graph becomes larger and more than two graphs or edge types should be compared as it is the case for comparing different concepts of code coupling. A simple solution to this scalability problem would be to use an approach working with a strong form of aggregation as those discussed above. Though details might still be available on demand, the visual comparison is limited to the aggregated information. But comparing different concepts of coupling is more about retrieving similar structures across different concepts, detecting particular outliers, or comparing subgraphs. Working with aggregated information would probably be too coarse-grained. Also matrix visualizations of graphs are supposed to be scalable with respect to the number of nodes and are not affected by visual clutter produced by high edge densities [115, 149]. But approaches working with split cells for representing different types of edges or time steps need larger cells destroying parts of this good scalability. Moreover, when comparing the different edge types or graphs, it requires some cognitive effort to discern the small edge representations just based on color and relative position in the cells. Approaches like TimeRadarTrees and Timeline Trees even lose more scalability by depicting the graph information in small thumbnails. Considering node-link diagrams, animated representations are not suitable for comparing concepts of code coupling because they are made for evolving graph structures and not for comparing graph structures varying significantly from stet to step: the difference between two concepts of coupling would be too large for showing them in a short animation. In contrast, static node-link approaches are more appropriate for representing larger differences because the user could detect differences step by step at an individual rate. But edges occupy some space in node-link diagrams so that all existing approaches (Figure 4.7) seem to struggle with some sort of scalability problem: • Using juxtaposed diagrams thoroughly constrains the space available for each diagram—the number of nodes, hence, is restricted. • Discerning the edge types by stroke or overlaying graphs is very limited with respect to the number of different types.
60
4 Visual Comparison of Code Couplings
• Edge-type nodes obfuscate the graph structure and decrease the readability of edges in general. To summarize, none of the referenced visual graph comparison approaches seem to be fully suitable for comparing different concepts of code coupling in considerable scale. However, some already fit partly the intended application scenario. Hence, the two novel approaches proposed in the following are adaptions of existing techniques intended to better meet the requirements of the application scenario.
4.3 Node-Link Approach The first of the two novel visualization techniques is based on juxtaposed node-link diagrams, however, varies significantly from traditional node-link approaches by applying a special layout: nodes are arranged on linear vertical axes and each node is split into two ports assembling outgoing and incoming edges. This uncommon layout targets at fitting scalable node-link diagrams into small stripes that can be arranged side-by-side enabling graph comparison. In the following sections, first, concrete objectives for the visualization technique are derived (Section 4.3.1). A visualization approach that meets these objectives is proposed and its main design decisions are motivated (Section 4.3.2). Then, the interactive tool that implements the approach is introduced in full detail (Section 4.3.3). There exist several interesting design alternatives worth discussing, in particular, edge bundling, edge splatting, and a radial visualization layout (Section 4.3.4). Certain recurring visual patterns help reading and describing phenomena in the visualization (Section 4.3.5). Finally, a case study demonstrates the usefulness of the approach in practical application (Section 4.3.6).
4.3.1 Objectives The motivation for developing a novel visualization technique that enables the comparison of different concepts of coupling was to overcome the limitations of existing approaches. The challenges are finding a scalable representation of possibly large datasets of real-world software systems and fostering the comparison of concepts. These challenges can be translated into the following objective. Objective 4.1: Support the visual analysis and comparison of different concepts of code coupling in a scalable way.
In general, the modularization of a software system is an important point of reference for software developers for understanding and changing a software system.
4.3 Node-Link Approach
61
Visualizing both, the coupling structure and the modularization, might improve the understanding of the current modularization and its underlying design decisions. Hence, a relationship between the two structures should be easy to retrieve from the visualization, which can be expressed as a second objective. Objective 4.2: Depict the relationship of a software modularization and the code coupling structure.
Summarizing, the general objective is visualizing a modularized multi-dimensional coupling graph (Definition 3.10) in a readable way.
4.3.2 Visualization Approach The visualization approach for comparing code couplings is expected to meet these two objectives. In the following, this approach is introduced step-by-step and basic design decisions are motivated. Juxtaposed Node-Link Diagrams A straightforward approach towards visually comparing different concepts of coupling are juxtaposed node-link diagrams (Figure 4.7, juxtaposed ). They are easy to understand and clearly separate the different concepts of code coupling in independent graph diagrams. The latter point distinguishes them from other node-linkbased approaches, which are tightly limited with respect to the number of different concepts that can be concurrently shown in the diagram: concepts are much harder to discern when using different link types (Figure 4.7, link type) or stacked diagrams (Figure 4.7, stacked ); or they are hard to compare like in animated diagrams. An exception is the approach using edge-type nodes (Figure 4.7, edge-type nodes); but this approach is likely to make the graph structure harder to read in general. Hence, juxtaposed node-link diagrams seem to be suitable for comparing multiple concepts of code coupling. Nevertheless, choosing the juxtaposition paradigm of comparison does not automatically exclude other comparison paradigms: those can still be used as supporting, secondary comparison techniques, for instance, by making them available on demand through interactions. Linearized Graph Layout However, the main problem of juxtaposed node-link diagrams is the reduced screen space that is only available for each of the node-link diagrams—the scalability with respect to the number of nodes is jeopardized. This issue is crucial in the current
62
4 Visual Comparison of Code Couplings
traditional
a
b
c
d
e
linearized
split linearized
a
a
b
b
c
c
d
d
e
e
Figure 4.9: Alternative node layouts for node-link diagrams showing the same sample graph.
application because large graph structures need to be visualized. An adaption of the node-link diagrams is required to make them sufficiently scalable. In a conventional node-link diagram like in Figure 4.9 (traditional ), nodes can be freely arranged onto the two-dimensional drawing area. A more space-efficient way to depict a set of nodes, in contrast, is to place them in a linear sequence, for instance, on a vertical axis. As Figure 4.9 (linearized ) shows, edges can be attached as arcs to the sides of the sequence. The depicted diagram arranges all downward links to the right and all upward links to the left, as it is proposed in the TimeArcTrees approach [121], which is based on this linearized representation. Split Nodes A main drawback of the linearized layout, however, is that the links soon become cluttered for larger graphs. A way to mitigate the problem of edge clutter seems to be splitting each node into two ports: one for outgoing links and one for incoming ones. Those ports can then be arranged on two parallel vertical axes so that the two ports of each single node lie on an imaginary horizontal line. The port on the left is the one for outgoing edges, the port on the right the one for incoming edges. As illustrated in Figure 4.9 (split linearized ), edges can be drawn as straight links connecting the ports (alternative edge routing approaches are discussed in Section 4.3.4). Through the arrangement of ports, it is warranted that all edges point from left to right. In this layout, edges can be followed easily: First, the direction of links is obvious because they all point from left to right. Second, links do not cross nodes. Third, when using straight links, only a short section of the link suffices to virtually com-
4.3 Node-Link Approach
node-link tree diagram
indented outline plot
63
icicle plot
A a B b A
a
B
B b
a b
c
A
c
C C
d
c
e
d
C
d e
e
Figure 4.10: Three hierarchy visualization approaches arranging the nodes on a single linear axis.
plete the line. A drawback, however, is that following paths is more difficult than in conventional node-link diagrams: the gaze of the viewer always has to switch horizontally from right to left when following the next edge on the path. But these difficulties are much weaker than in matrix diagrams where the user has to switch from columns to rows or vice versa, following an imaginary diagonal line. Attached Hierarchy When increasing the number of nodes so that each only has a height of a few pixels, it becomes harder to identify the exact node acting as a source or target of a link. Only roughly, the user might identify a set of neighboring nodes as possibly being involved. But if similar nodes can be arranged next to each other, the particular source or target of an edge will become less relevant because the potential start or end nodes belong to the same set of vertices. The hierarchical organization of the software systems provides information for grouping related entities. Hence, the layout might become more scalable when having a hierarchical structure to organize the nodes into meaningful groups. A hierarchy can be easily attached to the sides of linearized node-link diagrams. It restricts the ordering of nodes by defining groups of vertices that belong together. There exist three main options for depicting the hierarchy such that the hierarchy leaf nodes match the linear arrangement of graph nodes [120] (Figure 4.10)—nested approaches like treemaps and also matrix representations are not applicable because the leaf nodes are not positioned on a single linear axis. Node-Link Tree Diagrams: A hierarchy can be considered as a graph, and as such, can be visualized in a node-link diagram [224]. Due to its special structure,
64
4 Visual Comparison of Code Couplings
a
E1
a
E2
a
E3
a
B
A
C
b
b
b
b
c
c
c
c
d
d
d
d
e
e
e
e
Figure 4.11: Sketched final layout of the node-link comparison approach.
this graph is planar (it can be drawn without edge crossings) and is usually depicted as a diagram that looks like a stylized tree (Figure 4.10, node-link tree diagram). Indented Outline Plot: In an alternative layout, also the inner nodes are arranged on the same linear axis as the leaf nodes while parent nodes precede their children; indentation is used to indicate the depth of the hierarchy (Figure 4.10, indented outline plot); this representation is often applied in file browsers such as the Microsoft Windows Explorer. Icicle Plot: The vertices of the hierarchy are depicted as boxes; containment relations are indicated by positioning all children at one side of the parent element so that, together, they are as large as the box of their parent vertex (Figure 4.10, icicle plot) [153]. Using icicle plots seems to be most appropriate in the current scenario because they are more space-efficient and easier to label than equivalent tree diagrams. And in contrast to indented outline plots, they do not reserve additional space for inner vertices of the hierarchy—space that is not required for just depicting links between the leaf nodes of the hierarchy.
Final Layout Putting the pieces together, the visual comparison approach consists of juxtaposed node-link diagrams—called subdiagrams in the following—showing different concepts of coupling. All subdiagrams apply the same split linearized layout. An icicle plot is attached reflecting the hierarchical structure of the data. To use the landscape format of the screen efficiently, the whole diagram is laid out from left to right, first showing the hierarchy, and then, side-by-side, the different subdiagrams in small vertical stripes. Figure 4.11 provides an outlook on this final layout.
4.3 Node-Link Approach
65
Please also note the following details depicted in the figure: Axes of neighboring subdiagrams show the same sequence of nodes and hence can be joined. The nodes are represented as boxes for better fitting the layout of the icicle plot. By horizontally continuing the border lines for all inner vertices of the icicle plot, it becomes easier to relate nodes to the hierarchy. Moreover, arrow heads can be omitted because every link points from left to right. Labels provide information to discern the different types of edges (here, E1 , E2 , E3 refer to the different concepts of coupling as introduced in Definition 3.4). The approach promises to meet the initially formulated objectives: The juxtaposed node-link subdiagrams enable the visual comparison of concepts of coupling in a scalable way due to using the split linearized node-link layout (Objective 4.1). Moreover, the attached icicle plot relates the couplings to the modularization of the system (Objective 4.2).
4.3.3 Interactive Visualization Tool The described node-link approach (Figure 4.11) is implemented as an interactive visualization tool. To this end, details for drawing the hierarchy and the graph were specified such as how to use colors, shading, and opaqueness. But the unique contributions of the implementation are its features to explore and interactively compare the concepts of coupling. The visualization tool is implemented in Java based on the implementation of the data model as introduced in Section 3.2.4. For drawing the diagram itself, the graphics framework Processing is used (Processing is a Java library that simplifies drawing operations and other graphics-related functionality). The following sections describe the visualization tool in detail with a special focus on advanced interactions. As a preview on the final implementation, Figure 4.12 shows an image created with the tool: Three structural concepts of coupling are depicted for JFtp in juxtaposed subdiagrams, namely, inheritance (SD.Inh), aggregation (SD.Agg), and usage (SD.Use). Classes and interfaces form the vertices of the graph while the package structure of the system provides information on their hierarchical organization as discussed in Section 3.3.1. This dataset should serve as a running example throughout this chapter. Its coupling graph consists of 78 vertices and 144 edges (40 for SD.Inh, 66 for SD.Agg, 38 for SD.Use). The example is small enough to demonstrate the features of the visualizations in a readable way in print, but already large enough to have of some practical relevance. Graph and Hierarchy Representation The specified visualization approach (Figure 4.11) already defines the main aspects of the graph layout, but as indicated by Figure 4.12, the implemented tool extends
66
4 Visual Comparison of Code Couplings
Figure 4.12: Visual comparison of three concepts of code coupling—inheritance (SD.Inh), aggregation (SD.Agg), and usage (SD.Use)—for JFtp applying the node-link approach.
the visualization approach with respect to some details: Using shading, the small boxes representing the nodes are separated—border lines would lead to visual clutter for smaller nodes. The attached icicle plot uses a similar shading technique for inner nodes of the hierarchy. Nodes are labeled if enough space is available; if necessary the text of the label is rotated or the font size is decreased. Dummy nodes are inserted and labeled with ‘#’ to summarize the directly included code entities of a package if the package contains further subpackages; this simplifies interactions with respect to those groups of code entities, like focusing and selecting them (see below). For drawing the edges, the blue color clearly discerns the links from the nodes and the icicle plot as well as from the gray horizontal lines continuing the hierarchy. But the links are not fully opaque so that the link color becomes more intense at edge crossings—links can be traced easier, in particular if many edge crossings exist. The data model defines coupling graphs (Definition 3.5) as having weighted edges. There are several standard options for encoding edge weights in a node-link diagram: weights can be color-coded, represented by the opacity of the link, encoded in the thickness of the line, or labeled by the weight in numbers. While the latter option is not feasible due to scalability issues, a reduced opacity is already used for alleviating edge overlap. Since colors are needed for interactive highlighting, finally, the thickness of the links is the remaining concept for indicating the weight of the corresponding edge.
4.3 Node-Link Approach
67
When comparing different concepts of code coupling, the distribution and scale of edge weights might vary heavily between the different concepts. Therefore, it is necessary to normalize the weights of the edges. In particular, the weights are adapted so that the sum of all weights is 1 for each concept. In other words, each edge weight is divided by the sum of all edge weights belonging to the same concept. Furthermore, the thickness of the lines only grows logarithmically with the edge weights to limit a possible exaggeration of outliers.
Basic Interaction The implemented visualization tool allows manipulating the visualization to retrieve details and to ease the visual comparison process. Basic interactions like focusing and highlighting enlarge parts of the visualization or visually distinguish them from others. The premise for all interactions, however, is that the complete dataset is visible at any time—when some parts are enlarged others have to become smaller, that is, no scrollbars will be added to the visualization. A mechanism like this is called focus+context approach [272]. In particular, the tool implements a semantic zooming mechanism in form of a multiple focus concept similar to Table Lens [223]: vertical as well as horizontal zooming is possible. First, vertical zooming refers to focusing nodes in the hierarchy. If a hierarchy node is focused, the node and all its direct and indirect children are enlarged; focusing multiple nodes is possible. Second, an analogous concept applies to horizontal zooming: when focusing one of the subdiagrams, it is enlarged; multiple foci are applicable. All foci—vertical as well as horizontal—can be reset via the context menu. Since zooming already allows enlarging important parts of the hierarchy and scaling down less important things, it was not necessary to integrate collapsing and expanding of hierarchy nodes into the tool. The user may highlight a set of entities by clicking on their visual representation (Figure 4.13). This technique allows marking a single code entity as well as complete packages. While selecting further elements just widens the selection, elements can be deselected by again clicking on them. Each of the selected nodes is visually highlighted in the visualization by green and red markers at the ports for incoming and outgoing edges across all juxtaposed subdiagrams. Moreover, related edges are also emphasized: outgoing edges from a selected node are drawn in green, incoming ones in red. Edges that connect two selected nodes, hence, should be green as well as red, which is realized by assigning a mix-color—a brownish green. These colors are chosen because they provide a certain intuition on the direction of the edges; redgreen color blind users may opt for a different color scale. End points of highlighted edges are indicated by small gray markers in the boxes of the nodes. Like resetting the foci, the context menu allows for deselecting all highlighted elements at once.
68
4 Visual Comparison of Code Couplings
Figure 4.13: Interactively manipulated variant of the visualization presented in Figure 4.12: zoomed event and net package, zoomed SD.Agg subdiagram, highlighted event package.
Additional to focusing and highlighting, node labels can be retrieved on demand when hovering a node with the mouse. Moreover, it is important when analyzing software systems to connect the visualization with the raw data—the actual code: double-clicking a package or a code entity opens the respective package in the file browser or the respective file in a text editor. Example 4.1: Figure 4.13 provides an example for an interactively manipulated view of the visualization presented in its default view in Figure 4.12. The event as well as the net package is vertically enlarged by focusing; horizontally, the SD.Agg subdiagram is scaled up. Furthermore, the user has highlighted the nodes of the event package so that all related links become easier to trace. For an outgoing aggregation edge (green link in the center), the label of the target node (marked by a small gray box) is queried: the FtpClient class.
Interactive Comparison While the juxtaposed subdiagrams already support a visual comparison of concepts of coupling, interaction provides the possibility to further enhance the comparison abilities. For instance, in juxtaposed views, directly neighboring subdiagrams are
4.3 Node-Link Approach
Add Remove
all vertices that
have do not have are reachable by
69
edges incoming edges outgoing edges
Reset selection
Invert selection
Figure 4.14: Available options for editing the selection of highlighted entities.
easier to compare than those farther apart. To ease the comparison, the tool allows for moving subdiagrams by drag-and-drop; they can also be removed or renamed. But additional to these features related to juxtaposition, interaction techniques are implemented that are based on the two other visual comparison paradigms—overlay and fusion. Overlay A weak form of overlay is implemented based on the highlighting technique of entities: Besides directly marking particular entities as described above, also certain properties of a coupling graph can be taken into account for indirect highlighting. For instance, it is possible to remove all vertices from the selection that have incoming edges in a particular graph. Or all vertices are added that are reachable from the current selection of vertices by outgoing edges in a selected concept. A complete list of selection options, which all can be triggered through the context menu of the respective subdiagram, is provided by Figure 4.14. Please note that the reachability option can only be combined with adding vertices, not with removing. Resetting and inverting the selection are additional operations and do not depend on the graph structure. This form of selecting vertices for highlighting is based on the information of a single concept of coupling, but the respective vertices and edges are highlighted across all concepts. This mechanism realizes a form of overlay because information of one concept is highlighted in other concepts. Example 4.2: Figure 4.15 provides an example of how those advanced selection features can be applied. In this case, the goal was to select all code entities within the gui package that are extended or implemented by other code entities. This goal is reached by highlighting all code entities of the gui package and then removing all code entities from the selection that do not have any incoming edges with respect to inheritance (SD.Inh). Four code entities become highlighted, two of them having a large inheritance fan-in. Understanding this inheritance-based selection as an overlay, it can
70
4 Visual Comparison of Code Couplings
Figure 4.15: Example for highlighting by advanced selection options: selecting gui package, then deselecting all code entities that do not have incoming inheritance edges.
be observed that only one of the highlighted code entities, however, has a similar aggregation fan-in and none a similar usage fan-in. While two of the highlighted code entities are directly related to the same parent code entity by inheritance (two brownish green edges in the SD.Inh subdiagram), there do not exist any direct dependencies between them in the two other subdiagrams.
Fusion A comparison by fusion requires merging the underlying data and visualizing the aggregated result. Since the set of vertices is identical for all concepts of coupling within a single coupling graph (Definition 3.5), the sets of edges are the distinguishing features in the current application. Merging several sets of edges EV1 , EV2 , . . . , EVm into a new set of edges EV0 , standard set aggregation methods can be applied; handling edge weights properly, however, requires some extra considerations and leaves different options to choose from for the user. Union: The sets of edges are merged by applying the standard set union operation, that is, an edge is only transferred to the aggregated graph if it is contained
4.3 Node-Link Approach
71
in at least one of the merged sets. The weight of the aggregated edge is either the sum or the maximum of the weights of the merged edges. EV0
=
m [
EVi
i=1
Intersection: An edge is included in the aggregated structure if it is part of all merged sets of edges. The edge weight can again be the sum or the maximum of the original weights. Furthermore, it is now also possible to take over the weights of one of the original concepts. This operation is comparable to filtering edges (without changing their edge weights) based on the edge information of one or multiple other graphs. EV0
=
m \
EVi
i=1
Difference: In contrast to the union and intersection operation, the difference operation on sets is not commutative and hence can only be applied to two concepts of coupling (m = 2): either the set of edges of the second concept is removed from the set of edges of the first concept, or, vice versa, the set of edges of the first concept is removed from the set of edges of the second concept. The edge weights of the remaining edges do not change. EV0 = EV1 − EV2
or EV0 = EV2 − EV1
The fusion of concepts of coupling is interactively controlled as follows: A set of graphs is activated by clicking; a right-click on one of the graphs opens the context menu with all available merge options. When selecting one of the options, a new subdiagram is created—the old subdiagrams can be removed on demand. The name of the new subdiagram consists of the names of the merged diagrams and the applied operation in functional notation. For example, union_max(x,y) means that the subdiagrams x and y were merged applying a union operation and setting the edge weights to the maximum of both sources. Example 4.3: Some design patterns for software development [111] imply particular structural dependencies of different types. For instance, when two code entities are connected by an inheritance and aggregation edge, this hints at a composite pattern. Using the implemented fusion features, such pairs of code entities can be easily detected: SD.Inh and SD.Agg just need to be intersected, as illustrated in Figure 4.16 for JFtp. The resulting intersection only consists of a single edge, which relates the
72
4 Visual Comparison of Code Couplings
Figure 4.16: Example illustrating the interactive fusion of graphs: intersection of SD.Inh and SD.Agg based on summed edge weights.
class HostChooser to the class HFrame (both highlighted in the figure). When looking at the source code, however, it turns out that this example is not a real composite pattern since the aggregated HFrame is only used and reused as an error dialog.
Stages of Comparison The three visual comparison paradigms as implemented in the visualization tool can be considered as different stages of comparison: First, juxtaposition is the inherent comparison paradigm of the approach. Users can compare the different concepts of coupling based on juxtaposition in the static image, without having to interact with the tool. Second, overlay already needs some interaction, but it only has temporary effects on the visualization. Third, fusion requires the most invasive form of interaction: new subdiagrams are generated and juxtaposed. These three stages may often be applied in the listed sequence: observing something in the juxtaposed subdiagrams, the user raises a certain hypothesis, which can be checked applying interactive comparison—first, the overlay comparison based on simple highlighting, and second, the more complex fusion of subdiagrams. The three paradigms, hence, are not competing approaches but complement each other in supporting the user in comparing different concepts of code coupling.
4.3 Node-Link Approach
73
4.3.4 Design Alternatives For different parts of the visualization, there exist sensible alternatives to the design discussed so far. Some of the most interesting alternatives were explored by integrating them into the interactive visualization tool or by analyzing them in the context of the related parallel edge splatting approach [61]. The following discussion investigates those alternatives, namely, different edge bundling strategies, the edge splatting technique, and a radial layout of the visualization. The goal is not providing general answers which alternative is best, but to reveal possible advantages and drawbacks of the design alternatives for the intended usage scenarios. Edge Bundling As the presented visualization is a variant of a node-link diagram, all edge routing and drawing strategies applicable to general node-link diagrams can also be applied here. Instead of straight lines, curved links can be used to connect the nodes, which allows edge bundling: edges heading into similar directions are summarized into bundles of edges so that the diagram becomes less cluttered. A vast variety of bundling approaches has been already put forward, for instance, hierarchical edge bundling [138], force-directed edge bundling [140], mesh-based edge bundling [79], or multi-level agglomerative edge bundling [112]; Lambert et al. [161] provide a more detailed overview. Since software systems are usually hierarchically organized, bundling approaches leveraging this hierarchy are of particular interest in the current context. To explore alternatives to the straight-lines approach, two hierarchical bundling approaches were implemented in the visualization tool. Additionally, a third bundling approach experiments with dynamically derived hierarchies. Table 4.2 provides examples for all four edge routing approaches and summarizes advantages and drawbacks discussed in the following in form of scores (these scores only reflect my subjective opinion and were not derived empirically). Hierarchical Edge Bundling: Holten [138] proposes using a given hierarchical structure to group links into bundles: First, outgoing links of nodes that are siblings in the hierarchy are grouped together and bundled. Then, this procedure is repeated for the next levels in the hierarchy recursively until the root node or a certain predefined level is reached. The same algorithm is applied to incoming edges. The original approach was applied to a radial graph layout, but also works for a kind of split linearized node layout, as demonstrated in a technique for comparing two hierarchies [139]. Hierarchical Traceable Edge Bundling: Beck et al. [31] introduce a bundling technique that focuses on the traceability of edges. While, in the hierarchical bundling technique by Holten, edges are already aggregated that have sibling
74
4 Visual Comparison of Code Couplings
Table 4.2: Implemented edge routing strategies and their summarized characteristics. Straight Lines
Hierarchical Edge Bundling
clarity
++
o
edge clutter
--
++
traceability
++
--
hierarchy
--
++
Hierarchical Traceable Edge Bundling
General Traceable Edge Bundling
clarity
o
o
edge clutter
o
o
traceability
+
+
hierarchy
+
-
4.3 Node-Link Approach
75
source or target nodes, the traceable technique only groups those edges that either have the exactly same source or target node. Again a given hierarchy is used to recursively bundle the edges. The effect is that, for each source node, there exists exactly one bundle, which is split into its ingredients stepwise. Analogously, edges are again merged into a single bundle before they reach the same target node. General Traceable Edge Bundling: As an extension of the traceable approach, an individual hierarchy for each bundle can be derived from the layout of the nodes [31]. Still, only those edges are bundled that either have the same source or target node; but for each bundle, an individual hierarchy is computed: starting with a single bundle for outgoing edges at each source node, the bundle is split if the angle between two neighboring target nodes of the bundle reaches a certain threshold. The same is applied for incoming edges in reverse. Straight lines are easy to understand and clear because only a part of the link is necessary for following unambiguously the line. Nevertheless, the primary goal of bundling, however, is to reduce the visual complexity created by many edges. This effect of simplification by reducing edge clutter is stronger for the hierarchical edge bundling approach than for the two traceable bundling approaches. But a strong bundling also has its drawbacks: the clarity of straight lines is lost to some extent and single edges might no longer be traceable in the hierarchical edge bundling because too many different types of edges are overlapping. Preserving this traceability of single edges is the motivation behind the two other bundling approaches. This is realized by only grouping edges of the same source or target together at the cost of less reduction of edge clutter. Finally, the hierarchy plays an important role for understanding software systems and their code couplings. Using the package structure as a given hierarchy, it is easy to see which package is connected to which other packages. Although the general traceable approach also uses hierarchies, those hierarchies do not carry particular semantics and hence are less useful in the current visualization scenario. In general, the impact of edge bundling is largely not evaluated. A first, very recent study [185], however, confirms that hierarchical edge bundling could hamper tracing of edges. In contrast, detecting structures at a higher level of abstraction might be fostered by bundling: in the study, related clusters were found faster. Edge Splatting While edge bundling changes the routing of links, it is also possible to change the style of the link, for instance, by applying edge splatting: instead of directly drawing the edges, the edge density is computed for each pixel and then plotted as a heatmap showing the density by color. This technique is applied in the parallel edge splatting approach [61] for making timeline-based dynamic graph visualization more scalable.
76
4 Visual Comparison of Code Couplings
Figure 4.17: Applying edge splatting for JFtp (compare to Figure 4.12) using a topographic color scale to encode the edge density; image created with the parallel edge splatting tool.
without edge splatting
with edge splatting
Figure 4.18: The effect of edge splatting on dense areas of edge crossings.
But since edge splatting does not change the routing of edges, it is applicable to every node-link approach, also to the different bundling approaches discussed above. A similar splatting technique was already applied for edge bundling by Holten and van Wijk [140]. Figure 4.17 shows the sample JFtp dataset using edge splatting rendered with the tool implementing the parallel edge splatting approach [61]. Edge splatting seems to have advantages, in particular, if the graphs are rather dense: additional visual information is added to cluttered areas with many edge crossings, which allows for better perceiving details in these areas; this effect is demonstrated in Figure 4.18. But splatting may also decrease the intuitiveness of the diagrams because of the indirect approach to edge drawing. Edge splatting is not implemented in the introduced visualization tool for comparing multi-dimensional code couplings, but a
4.3 Node-Link Approach
Cartesian
radial
a b
e
d
c d e
77
a
c b
Figure 4.19: Juxtaposed linearized node-link diagrams in a Cartesian and a radial coordinate system.
similar effect is reached by making links not fully opaque: the density of edges can be distinguished by the intensity of color at a particular position.
Radial Coordinate System Many visualization techniques are transferable from a usual Cartesian coordinate system to a radial coordinate system. For instance, the radial equivalent of a bar chart is a pie chart. The same form of radial transformation can also be applied to the juxtaposed node-link diagrams with split linearized layout. The two diagrams depicted in Figure 4.19 provide an example by showing the same dataset in a Cartesian version and a radial one. Colleagues and I investigated the advantages and disadvantages of this approach in detail for the related parallel edge splatting technique [56]: On the positive side, edge lengths can be reduced for edges that originally connected nodes at the top of the diagram with nodes at the bottom and visual patterns are preserved under shifting of nodes. On the negative side, edges seem to be harder to follow. Moreover, the size of the subdiagrams is smaller in the circle center than in the outer rings— this might be an advantage for emphasizing recent graphs in a dynamic sequence of graphs, but could affect the comparison of the subdiagrams when there is no such natural focus. Empirical studies furthermore question the effectiveness and efficiency of radial diagrams in contrast to their non-radial counterparts in other scenarios [57, 87]. In the end, the disadvantages of the radial variant seem to outweigh its advantages: the non-radial variant is probably the better solution for comparing concepts of code coupling.
78
4 Visual Comparison of Code Couplings
beam
self
cross beam
cluster
hour glass
fan
out
gap
in
out
in
Figure 4.20: Visual patterns in split linearized node layout indicating different graph structures.
4.3.5 Visual Patterns Certain graph structures are reflected by recurring visual patterns in the visualization. Knowing and detecting those patterns, the visualization can be read more efficiently. Moreover, they provide a vocabulary for describing observations. Although the patterns discussed in the following only refer to a single subdiagram, they simplify the comparison of concepts by introducing a higher level of abstraction. The list below provides an overview of common patterns, which are illustrated by Figure 4.20. The patterns are visualized for straight lines and may differ for bundled edges, which is discussed where necessary. All patterns can also be defined formally; the precise definitions can be found in the work describing the parallel edge splatting approach [61]. The listed visual patterns are loosely related to graph motifs [270], which describe recurring, simple patterns in graphs. Beam: A beam is a horizontal block of densely assembled links connecting the nodes of the same package. For straight lines, such a beam pattern has a rectangular outline while, for edge bundling, it has a waisted shape. As such, a beam pattern either reflects a cohesive cluster of nodes in a module or a set of nodes having self-edges. Cross Beam: In contrast to a beam, a cross beam pattern is a diagonal block of densely assembled links, now connecting nodes of different packages. This pattern first of all refers to straight lines because, only there, a cross beam becomes visible as a diagonal; in contrast, in bundled representations, a cross beam may become S -shaped or U -shaped. Hour Glass: The hour glass pattern consists of two beam patterns in different packages and two cross beam patterns connecting the two packages. It indicates two closely related packages. Fan: Like a hand fan, the fan pattern consists of many lines coming together in a single point forming a triangular shape. In terms of the graph structure, the
4.3 Node-Link Approach
79
focus point of the fan is a node having a high in- or out-degree. Fan patterns appear in a waisted shape for bundled edges. Gap: A gap pattern denotes a whitespace area directly attached at the sides of one of the two axes. This whitespace states that the adjoining nodes do not have any outgoing or incoming edges. This pattern is applicable for bundled as well as non-bundled edges. In general, detecting patterns can only be considered as a heuristic to search for particular structures in the graph: Depending on the arrangement of nodes and packages, existing features of the graph are reflected by the visualization or not. In other cases, visual artifacts look like certain patterns although the graph does not have the according structure. As discussed, straight lines better reveal certain patterns in some cases. Nevertheless, particularly when used cautiously, those patterns still are an efficient instrument to quickly extract information from the graph visualization.
4.3.6 Case Study To provide some evidence of the usefulness of the introduced visual comparison approach, the technique is applied for analyzing different concepts of code coupling in a real-world software system. The case study also provides ideas and strategies of how the visualization can typically be used by researchers or developers for understanding and assessing the coupling structure of software systems. Dataset and Visualization In the case study, the open source code conventions checker Checkstyle in version 5.1 is used as a sample system. It is written in Java and consists of 261 classes and interfaces organized in 21 packages. The system is selected as an example because it is somewhat larger than the simple running example JFtp and visualizations of it still should be readable in a printed version. In the interactive, digital version of the visualization, analyzing larger systems is possible when using a standard HD monitor. Moreover, interactions like zooming and highlighting enable focusing on subsets of the data. Among the different concepts of code coupling introduced in Section 3.3, five are selected for the case study: inheritance (SD.Inh), aggregation (SD.Agg), usage (SD.Use), the support-based version of evolutionary coupling (EC.Sup), and code clone coupling of type I (CC.I ). This set of concepts of coupling provides different perspectives on the software system that should be analyzed. Testing the different implemented edge bundling strategies, it seems that hierarchical edge bundling provides the best overview for the dataset. For investigating details,
80
4 Visual Comparison of Code Couplings
probably one of the other edge routing strategies works better, but details can also be retrieved using the interactive features. For these reasons, hierarchical edge bundling is applied throughout the case study. Detecting Coupling Features The following list describes examples of different application scenarios the visualization can be used in. A particular focus is on the capabilities of the technique for visually comparing different concepts of code coupling. Figure 4.21 shows the default view as displayed when opening the dataset with the visualization tool. Further images created by using interactive features of the visualization tool are provided along with the application scenarios where required. Key Entities The most central classes and interfaces of a software system are those that are coupled to many other code entities. Different concepts of coupling thereby relate to different forms of key entities: For instance, a class extended by many other classes potentially spreads its functionality across all those inheriting classes. Considering evolutionary coupling, a code entity reasonably coupled with others identifies a code entity that often had to be changed together with those other entities. Key entities like this can be identified by looking at their in-degree or out-degree in the respective subdiagram. In terms of visual patterns, high degrees of such form are represented as fan patterns. In the visualization of Checkstyle as presented in Figure 4.21, for instance, larger inheritance (SD.Inh) fan-in patterns can be found for the packages api, indentation, and naming. The particular targets of these fan-ins form key entities of the respective package or the whole system because functionality implemented there could be reused and extended in many other code entities. While, in the indentation and naming package, those inheritance dependencies are limited to the borders of the package, inheritance fan-ins are assembled from different packages for the api package indicating a broader impact of these entities. In contrast to fan-ins, fan-out patterns cannot be detected among the inheritance dependencies—multiple outgoing edges only occur if several interfaces are implemented, which rarely seems to be the case. At first glance, the subdiagrams for aggregation (SD.Agg) and usage (SD.Use) look very similar to the one of inheritance (SD.Inh) in Figure 4.21; this impression is due to similar broad fan-ins for the api package. Hence, elements in this package form similar key entities also for these other concepts. However, the question is whether these are the same entities that are also key entities for inheritance. But highlighting the target of inheritance dependencies in the api package (Figure 4.22) shows that only some of the inheritance key entities are also key entities for aggregation and usage.
4.3 Node-Link Approach
81
Figure 4.21: Checkstyle project in the node-link approach comparing five concepts of code coupling: inheritance (SD.Inh), aggregation (SD.Agg), usage (SD.Use), evolutionary coupling by support (EC.Sup), and type I code clone coupling (CC.I ).
82
4 Visual Comparison of Code Couplings
Figure 4.22: Checkstyle project with highlighted code entities in the api package that are target of inheritance dependencies.
Comparing inheritance to code clones (CC.I ), only few highlighted edges can be observed in the CC.I subdiagram of Figure 4.22. Hence, those inheritance key entities in the api package do not seem to be equivalent key entities for sharing code. What cannot be retrieved by highlighting is whether the emphasized edges are the same as for inheritance. Intersecting inheritance dependencies with coupling by code clones, however, provides further information. The result is depicted in Figure 4.22, inter CC.I(SD.Inh, CC.I); inter CC.I means that the weights of the intersected edges are set to the weights of the code clone edges: Only three highlighted edges remain, identifying one of the entities as a special inheritance-clone key entity. The highlighted edges (and all other edges of the intersection), however, could be unwanted clones: why is a clone necessary when functionality can be shared through an already existing inheritance edge? Checking this particular example in the code, the three edges can be traced to a small clone consisting of a method returning an empty integer array—this clone might be too simple so that removing it would not necessarily pay off.
Coupling Outliers An outlier edge is a single edge (or a few edges) having no similar edges that connect other code entities of the same source and target packages. These outliers might form unwanted or unexpected couplings across several concepts: they could be usage dependencies introducing a cycle, they could represent an unwanted code clone, or hint at a flaw in the design of the system. Outlier edges
4.3 Node-Link Approach
83
Figure 4.23: Checkstyle project with enlarged and highlighted grammars package and enlarged api package.
often form a weak kind of cross beam pattern connecting different packages in one direction. Looking at the overview picture of Checkstyle (Figure 4.21), a quite apparent outlier can be found in the inheritance subdiagram (SD.Inh): a single edge connecting the api package with the grammars package. Searching this outlier in the other subdiagrams, a similar edge can be detected also for usage dependencies (SD.Use). However, when highlighting and enlarging the grammars package like done in Figure 4.23, it turns out that both outliers indeed have the same target (the CommentListener interface) but different sources from different packages. Investigating the relationship between the grammars package and the api package in closer detail, further dependencies can be detected (e.g., by searching for small gray markers at the nodes indicating adjacent nodes to one of the highlighted ones): an aggregation and a usage dependency as well as two evolutionary couplings. Moreover, all other dependencies of the grammars package only link to direct children of the root package (# nodes at the top). Towards improving the design of the system, this provides enough evidence for proposing that the grammars package should become a subpackage of the api package.
Loose Ends and Independent Components Nodes without incoming or outgoing edges can be considered as loose ends of the graph. For a graph falling into several independent components, they mark the borders of these components. In
84
4 Visual Comparison of Code Couplings
Figure 4.24: Checkstyle project focusing on structural dependencies with highlighted api package.
terms of concepts of coupling, loose ends might indicate independent code (no outgoing structural dependencies), entry points for program execution (no incoming structural dependencies), or code that were never changed together with code from other files (no incoming and outgoing evolutionary couplings). Gap patterns in the visualization hint at those loose ends. On a higher level of abstraction, packages can be considered as loose ends if they have no incoming or outgoing dependencies to other packages—these are harder to detect because they do not necessarily show up as gap patterns. Analyzing loose ends, structural dependencies in general are of particular interest. Applying the interactive comparison features, a union of the three structural concepts can be generated as depicted in Figure 4.24. Most of the few nodes having no outgoing edges are located in the api package. Highlighting this package as done in the figure reveals another notable aspect: when virtually blending out the intra-package edges (edges depicted in brownish green in Figure 4.24), the whole api package only has one outgoing edge (the outlier discussed above). Hence, not only single elements of the package seem to be loose ends but also the package itself seems to be something like an end point, in particular, when understanding the grammars package as a subpackage of the api package as already suggested above. When analyzing the incoming edges much larger gap patterns can be found. This might appear surprising because the respective code cannot be accessed directly. When, however, studying the documentation and the code of the system, it soon becomes apparent that Checkstyle works with a plug-in concept that makes heavy
4.3 Node-Link Approach
85
usage of reflections for dynamically loading, for instance, different source code checks (checks package). Detecting loose ends—in terms of structural dependencies—is the first step towards identifying layers in the architecture. In the current example, for instance, the api and grammars are identified as being the end points of those structural dependencies and hence belong to the lowest layer of the architecture. But by looking at loose ends, packages can only be assigned to the topmost and lowest layer; making statements about layers in between is harder. To this end, sorting the nodes according to the direction of dependencies, as it is applied for Dependency Structure Matrices [232], may further enhance the tool for this use case. Cohesiveness and Coupling A package having many dependencies within the package is considered cohesive. And when there exist many dependencies to other packages, it is said to be coupled. Well-designed packages are intended to be highly cohesive, but only lowly coupled [247]. In the visualization, cohesive package structures create beam patterns while coupled packages often yield cross beam patterns. Starting with analyzing usage dependencies (SD.Use) in Figure 4.21, many beam patterns hint at cohesive packages. Coupling is limited since only strong cross beam patterns connect the api package with other packages (this structure might be considered as a set of overlapping fan-in or cross beam patterns). Contrasting usage to the other structural dependencies (SD.Inh and SD.Agg) in Figure 4.21, similar beam and cross beam patterns can be observed. Taking also evolutionary coupling (EC.Sup) and code clones (CC.I ) into account, there exist at least similar beam patterns. But although the cross beam patterns look different, they are still quite alike because many crossing edges link the api package to other packages—the visual difference stems from the symmetry of evolutionary couplings. For code clones, however, the situation appears to be different: here, the checks package and its many subpackages seem to play the leading role, with respect to internal cohesion as well as to coupling to other packages. Discussion The case study provides a rich set of possible scenarios the visualization can be used in. It shows that, applying the visualization, the user may analyze a variety of properties of the software systems reflected in different concepts of coupling. Retrieving those properties can be considered as being part of understanding or reengineering a program. Most of the observations described above depend on the comparison of multiple concepts—hence, retrieving the same information with a visualization that only shows one concept of coupling probably is much harder. Though empirical evaluation against a traditional approach and feedback from software developers applying the
86
4 Visual Comparison of Code Couplings
tool is still lacking, the case study provides first evidence suggesting the general usefulness of the approach.
4.3.7 Summary The presented approach provides the means for visually comparing multiple concepts of coupling organized in a modularization (Section 4.3.2): the comparison is based on juxtaposed node-link diagrams; a special layout that linearly arranges split nodes on parallel axes is required to make the juxtaposed subdiagrams scalable. Besides standard interactive feature that show details on demand and provide zooming, advanced interactions further enhance the comparison of different concepts (Section 4.3.3). Some design alternatives are explored for the approach, among them, different edge bundling strategies and edge splatting (Section 4.3.4). Typical visual patterns are discussed, which help interpreting the visualization (Section 4.3.5). A case study suggests how the approach can be used in different practical software engineering scenarios (Section 4.3.6).
4.4 Matrix Approach The modularization of a software system is visualized along with code couplings in the presented node-link approach. But there are scenarios where more than one modularization of a system exist. These alternative modularizations could be a different version of the system, different modularizations created by applying different modularization criteria, or modularizations generated by clustering. Though there exist approaches for visually comparing multiple hierarchies such as modularizations, these approaches are not suitable for concurrently visualizing code couplings. The goal of this second visualization approach is to integrate the comparison of different software modularizations and the comparison of different concepts of code coupling. Due to the need for comparing hierarchies, this approach is visually very different to the previously presented node-link visualization technique; it is based on an adjacency matrix representation of the coupling graphs instead. The particular interest in the comparison of modularizations goes back to being able to analyze the results of the feasibility study (Section 2.3) in closer detail. The visualization approach is designed so that problems in the clustering process become apparent or reasons for particular clustering outcomes can be found. First, concrete objectives are derived from the intended application scenario (Section 4.4.1). Then, the visualization approach is introduced and motivated (Section 4.4.2); its concrete implementation and interactive aspects are discussed in detail (Section 4.4.3). Advanced layout features enhance the approach (Section 4.4.4).
4.4 Matrix Approach
expanded
87
partly collapsed
first hierarchy a
b
c
d
e
f
a
b
c
d
e
f
a
c
b
d
e
f
a
b
c
d
e
f
second hierarchy
Figure 4.25: Comparison of two hierarchies that are different on the finest level of detail (expanded ) but equivalent on a higher level (partly collapsed ).
Finally, in a case study, the visualization technique is applied to the results of the feasibility study, which yields some new insights (Section 4.4.5).
4.4.1 Objectives Comparing hierarchies requires showing which elements are similar across multiple hierarchies. In the current scenario, having different modularizations of the same software system, the hierarchies include the same set of leaf vertices—the classes and interfaces of the system (Section 3.2). Hence, similarity first of all refers to the equivalence of leaf vertices in the hierarchies. But similarity can also be considered on a higher level of abstraction: modules in the different modularizations are similar if they share a similar set of code entities. The partitions of entities created by two modularizations might be different on certain levels of the hierarchies while they could be similar on other levels. This effect is illustrated in Figure 4.25: On the left side, fully expanded, the two hierarchies look different—it is even necessary to order the leaf vertices differently. When, however, collapsing the green vertices as demonstrated on the right, the partitions on leaf level of two hierarchies become alike. The advantage of using visualization for comparing modularizations instead of metrics like applied in the feasibility study (Chapter 2) is that such effects can be explored. Moreover, visualization could provide details on particular similarities and differences in the modularizations. Targeting these advantages, the following objective can be formulated.
88
4 Visual Comparison of Code Couplings
Objective 4.3: Enable the comparison of different software modularizations by finding and visualizing similar partitions in different levels of the modularizations. Since the comparison of multiple concepts of code coupling shall also be supported by the second visualization approach, Objective 4.3 is considered additional to the objectives already defined for the node-link approach (Objective 4.1 and Objective 4.2). The new objective, however, introduces new challenges—certain trade-offs between the old and new objectives have to be taken. Due to this more complex visualization problem, the approach presented in the following is restricted to comparing two concepts of code coupling and two modularizations only—comparisons of more than two modularizations or concepts of coupling have to be simulated as several pairwise comparisons.
4.4.2 Visualization Approach Supporting the comparison of two modularizations (i.e., two hierarchies) guided the design of the new visualization approach. However, when choosing a particular comparison paradigm, it already has to be taken into account that code couplings are to be compared along with the modularizations—the approach needs to be open for including code coupling information. Different techniques for comparing hierarchies are discussed in the following with respect to this specific scenario. The new visualization approach combines and extends known hierarchy and graph visualization techniques in a novel way. Hierarchy Comparison Approach Since hierarchies are special kinds of graphs, hierarchy comparison can be considered as a specialization of graph comparison. This perspective, however, detracts from considering visualizations that more effectively visualize hierarchies than usual graph visualizations. A survey on visualizing and also on comparing multiple hierarchies was recently published by Graham and Kennedy [120]. The following paragraphs summarize and discuss their taxonomy of hierarchy comparison approaches; Figure 4.26 illustrates this taxonomy. Edge Drawing: A straightforward approach for visual hierarchy comparison is to place two hierarchies facing each other and to connect identical nodes in the different hierarchies by links (Figure 4.26, edge drawing). While this approach has been used in different visualization tools (e.g., [77, 78, 296]), Holten and van Wijk [139] explore this approach in detail: they work with icicle plots, use edge bundling and reduce edge crossings to increase the readability of the
4.4 Matrix Approach
edge drawing
coloring
animation
matrix
89
agglomeration
Figure 4.26: Paradigms for hierarchy comparison according to the taxonomy of Graham and Kennedy [120, Figure 4].
links connecting the two hierarchies. A similar technique is applied in Code Flows [256] for visualizing the changes of source code documents over multiple versions; each version is represented as an icicle plot, moved code is connected by pipes (i.e., a form of bundled edges). Comparison paradigm: juxtaposition/fusion – The edge drawing approach results in images visually similar to the presented node-link approach for comparing concepts of coupling, though the application is different. The comparison of hierarchies is based on the visual comparison paradigm of juxtapositions. The links connecting the identical nodes add a fusion aspect to the visualization. Coloring: Another form of connecting two juxtaposed hierarchies is by using brushing and linking: elements selected and highlighted in one hierarchy are colorcoded in the other hierarchy as well. In TreeJuxtaposer [200], this approach is applied to compare two large phylogenetic trees. The indirect color connections allow for extending the approach to more than two hierarchies [51]. Comparison paradigm: juxtaposition/fusion – Similar to the previous hierarchy comparison approach, the coloring approach is based on juxtaposed hierarchy diagrams. But it also includes a fusion aspect by synchronizing the selections in the two hierarchies; this indirect connection is a form of explicit encoding of the similarity of the compared data structures. Animation: Instead of showing the hierarchy diagrams side by side, they can be shown one after the other. Changes become apparent when animating the transitions. These animated changes are applied when interactively transforming a hierarchy as demonstrated by Wittenburg and Sigman [286]. Another example is presented by Reitz et al. [225], who animate changes in compound graphs including transformations in the hierarchy. Comparison paradigm: temporal juxtaposition/fusion – Animation can be considered as a special form of juxtaposition: namely, juxtaposition in time [116]. It is similar to the normal spatial juxtaposition because, for comparison, the user has to switch between the two representations remembering the situation
90
4 Visual Comparison of Code Couplings
in the other diagram. If the switching is implemented in smooth, animated transitions, this can be considered as making the difference explicit [116]—a form of fusion approach. Matrix: Instead of direct links, colored cells in a matrix could encode connections between two hierarchies. Therefore, the hierarchies need to be attached at two orthogonal sides of the matrix. Then, the leaf vertices of the two hierarchies are represented as rows and columns of the matrix, which intersect at specific cells—these cells are colored to indicate equivalence between leaf vertices. Please note that this technique, despite looking similar, is clearly different to encoding a single hierarchy in an adjacency matrix. Comparison paradigm: juxtaposition/fusion – Similar to the edge drawing and coloring approach, two hierarchies are juxtaposed in a matrix-based hierarchy comparison. The difference, however, is the encoding of the connection between the hierarchies—the fusion-related part of the approaches: the connection is represented in the cells of the matrix. Agglomeration: Two hierarchies can be merged simply into one as long as only leaf vertices are added or removed—colors may encode the changes (e.g., [122]). When considering arbitrary differences of the hierarchy, either vertices in the merged results need to be cloned [265] or the merged result is a directed acyclic graph [108]. Comparison paradigm: fusion – The agglomeration of multiple hierarchies obviously implements a pure fusion approach. In contrast to all previous approaches, no form of juxtaposition is included by default. The hierarchy comparison approach for the current application is required to clearly show similarities and differences of two possibly very different hierarchies while being open for including graph information. Since interaction is necessary for comparing the hierarchies in the coloring approach, the information needed for comparison is not very accessible there. Edge drawing, in contrast, explicitly shows the similarities between the two hierarchies, which, however, requires some screen space and probably conflicts with additional graph edges. Since the two hierarchies could be very different in the targeted scenario, animation and agglomeration are not an alternative either—these approaches might be more suitable for only showing small differences in the hierarchies. Finally, the most appropriate paradigm for the application seems to be the matrix approach: First, the information needed for comparison is explicitly encoded in the diagram and readily available. Second, the complexity of the diagram is independent of how different the two hierarchies are. And third, the approach can be combined with visualizing graph information—the matrix is only sparsely filled for hierarchy comparison and it can be used as an adjacency matrix to visualize graphs as described in the following.
4.4 Matrix Approach
C a
c
91
D d
b
e
a
self-referencing cells
A b c
B
d e
Figure 4.27: Matrix-based hierarchy comparison by marking self-referencing cells.
Though listed in the taxonomy of Graham and Kennedy [120], the matrix approach seems to be rarely applied—also Graham and Kennedy could not provide any reference directly applying the technique. At least the approach is similar to Cluster Heat Maps [285] where hierarchically clustered entities and hierarchically clustered features of those entities are encoded in a matrix and the two hierarchies are attached at the sides of the matrix. Also matrix-based graph visualizations supporting a hierarchical organization of the vertices and zooming [3, 267] are similar because two parts of the same hierarchy can be compared to some extent. In the concrete realization of the basic approach as depicted in Figure 4.27, all hierarchy-related information in the matrix is encoded in shades of gray. Again, icicle plots are used for representing the modularizations because they are spaceefficient and easy to label. For the matrix-based comparison, equivalent code entities in the two modularizations just need to be indicated by marking certain cells in the matrix. Interpreting the matrix as an adjacency matrix, these cells represent selfedges—code entity v is connected to its counterpart v in the other modularization— and are denoted as self-referencing cells in the following. These cells are textured so that they can be clearly discerned from other colored and shaded cells that depict additional information (see below). Advanced Hierarchy Comparison Approach The highlighted self-referencing cells in the matrix indicate the precise similarities and differences of the two modularizations. The overall pattern of these cells already provides some overview: clusters of self-referencing cells hint at similar higher-level structures in the two hierarchies, whitespace areas show dissimilarities. Nevertheless, these abilities for providing overview are limited because clusters of self-referencing cells might only be visual artifacts and in fact belong to different modules. Moreover, it seems to be quite difficult to estimate and compare the density of self-referencing cells in different areas of the matrix, in particular, if these areas are of different size.
92
4 Visual Comparison of Code Couplings
C a
c
D d
b
e
a
self-referencing cells
A b c
B
d e
Figure 4.28: Advanced matrix-based hierarchy comparison visualizing the similarity of modules as color-coded Jaccard Coefficients.
Thus, extending the approach towards an enhanced support of hierarchy comparison on a higher level of abstraction is desirable. The novel technique for improving the comparison is based on computing and visualizing the similarity between the modules of the two modularizations. Interpreting each module as a set of code entities, standard set similarity measures can be applied—a very simple and intuitive one is the Jaccard Coefficient [254]: the similarity coefficient for two sets V1 and V2 is defined as the number of common elements in the two sets divided by the size of the union of the two sets; or formally, sim(V1 , V2 ) =
|V1 ∩ V2 | |V1 ∪ V2 |
.
Using the Jaccard Coefficient, two arbitrary modules can be compared. The similarity values range from 0 to 1 and are mapped to a linear white-to-black color scale—white representing dissimilarity, black representing similarity. The different colors can be used as a background pattern for the matrix as demonstrated in Figure 4.28: the area representing the intersection of two modules is colored in the shade of gray encoding the similarity of the two modules. This area simply is the rectangle that forms the visual intersection of the rows and columns belonging to the two modules. This approach works well for non-hierarchical modularizations, which can be considered as hierarchies having only one level of modules—the modularizations in Figure 4.28 fall into this category. However, when having multiple levels of modules, combining modules from different levels leads to overlapping areas and, as a consequence, to ambiguous shading. Hence, the advanced comparison approach always has to be restricted to a particular level in the two modularizations—the lowest level seems to be an appropriate default.
4.4 Matrix Approach
C a
c
a
93
D d
b
e self-referencing cells
A b c
B
d
graph edges
e
Figure 4.29: Final matrix-based hierarchy and graph comparison approach.
Graph Comparison Approach As already implied, combining the matrix-based hierarchy comparison with a matrixbased graph visualization is possible: the underlying matrix just needs to be interpreted as an adjacency matrix and the graph information can be added as another layer consisting of highlighted matrix cells. Now, using only shades of gray for the hierarchy comparison pays off because colors can be used to encode the graph structure. Since self-edges are not included in the datasets that should be visualized, highlighted self-referencing cells and colored cells do not conflict. As a consequence of the dual use of the matrix, the ordering of vertices is different from a normal adjacency matrix where rows and columns are usually ordered alike. In contrast, the two hierarchies in the hierarchy comparison approach in general impose different orders for rows and columns. Though unusual for an adjacency matrix, this deviating order, however, does not conflict with encoding the graph information—colored cells still unambiguously identify an edge between the vertices represented by the respective row and column. Figure 4.29 sketches the combined approach. A notable difference to usual adjacency matrices is that self-referencing cells do not form the diagonal of the matrix. It might be more difficult for the user to read the diagram because the diagonal is an important reference. For instance, when following a path in the graph, the user has to switch from the column representing a vertex to the row representing the same vertex, or vice versa, which is easier when the position of the vertex just needs to be reflected through the diagonal of the matrix. Solutions how to restore parts of the diagonal and attenuate the problem are discussed later in Section 4.4.4. The attentive reader might have already noticed that multiple colors are used in Figure 4.29 to represent the graph edges. This is due to comparing different concepts of code coupling—it is a simple, but effective overlay-based comparison approach to use different colors for representing different types of edges. A problem, however,
94
4 Visual Comparison of Code Couplings
occurs when the same edge is represented in multiple types: which color has to be used for the according cell? Split Cells: One solution is to split each cell into subcells (one subcell for each type of edges) and color only those subcells as proposed by Zeckzer [299]. This, however, reduces the scalability of the visualization because colored cells become smaller. Coloring: An alternative approach is to use different colors for these duplicate edges. This does not decrease the size of the cells, but it could decrease the readability when too many colors have to be used—the number of required colors grows exponentially; namely, 2m − 1 are necessary for m types of coupling. Choosing between these two approaches, hence, is a trade-off between scalability and number of concepts of coupling that can be compared. Since scalability is important in the context of analyzing software projects and multiple concepts of code coupling can be already compared with the presented node-link approach, the coloring approach seems to be more appropriate in the current scenario. To circumvent the problem of color ambiguity, not more than two different concepts of coupling are compared using the approach in the following. Thus, three colors are required: one for the first concept, one for the second, and the third for couplings occurring in both concepts. In Figure 4.29 and all following examples, these colors are blue (first concept), red (second concept), and purple (duplicate edges). Final Layout The final layout of the approach conforms to the one already presented in Figure 4.29. To summarize, it is a matrix-based hierarchy comparison approach combined with an adjacency matrix visualization of two concepts of coupling. The hierarchy comparison approach can be classified as a mixture of juxtaposition (two icicle plots) and fusion (self-referencing cells and module similarity). In contrast, the graph comparison approach is based on overlay. The new visualization approach is intended to support the two objectives already formulated for the node-link approach (Section 4.3.1): it enables comparing at least two different concepts of coupling in a scalable way (Objective 4.1) and makes the hierarchical structure of the graph apparent by attaching icicle plots (Objective 4.2). Furthermore, the third and new objective (Objective 4.3) is addressed by integrating the matrix-based hierarchy comparison approach.
4.4.3 Interactive Visualization Tool Like the node-link approach, the introduced matrix approach is implemented as an interactive visualization tool using Java and Processing; it is again based on the
4.4 Matrix Approach
controls (level of detail)
first modularization
95
second modularization
matrix-based hierarchy and graph comparison
Figure 4.30: JFtp project in the matrix approach contrasting the package structure against a clustered modularization based on structural and evolutionary data; the matrix-based graph visualization compares structural (blue cells) and evolutionary couplings (red cells).
implementation of the data model described in Section 3.2.4. The tool elaborates on the matrix approach presented so far with respect to visual details, for instance, how to use shading to better discern modules or how to make module similarities more accessible. Moreover, interaction plays an important role: besides basic interactions, the level of detail for the two modularizations can be adapted interactively, which further helps comparing the modularizations. To get a first impression, Figure 4.30 shows an annotated visualization of the JFtp project created with the tool. Structural dependencies in form of the SCDG (an aggregation of inheritance, aggregation and usage dependencies) are contrasted with evolutionary couplings represented by the ECDG (since the dataset stemmed from the feasibility study, the notation introduced in Section 2.2.1 is used in this example). At the same time, the package structure (left) is compared to a modularization of the JFtp system (top) that was automatically generated by clustering as demonstrated in the feasibility study (Section 2.3.2). The particular clustering modularization was derived from the combined structural and evolutionary information shown as the graph structure. For better readability, Figure 4.30 already anticipates advanced layout concepts discussed later in Section 4.4.4.
96
4 Visual Comparison of Code Couplings
Graph and Hierarchy Representation Different colors can be used to discern the two modularizations: in Figure 4.30, gray is used for the standard package structure and green for the clustered modularization. Again, virtual modules (labeled ‘#’) are inserted for grouping the direct children of modules also having submodules. Similar to the node-link approach, the icicle plots use unobtrusive shading instead of border lines to make neighboring elements discernible. These shadings are continued into the matrix—horizontal and vertical shaded lines continuing the modularizations create a grid pattern reflecting the hierarchical structure into the matrix. These lines also mark the borders of the areas used for encoding the similarity of modules as a grayscale background pattern. Modules are labeled if enough space is available; where necessary, the text is rotated or scaled down. In the two icicle plots, the code entities—the leaf vertices of the hierarchies—are encoded in different shades of gray. This encoding groups neighboring code entities together in one modularization that also belong together in the other modularization. These groups colored in the same shade are called mutual blocks in the following. The particular shade of gray represents the similarity of the two modules in the two modularizations the code entities are part of. A precondition for making use of these mutual blocks, however, is that code entities belonging to the same other module are grouped together—this is guaranteed by a local sorting approach introduced as an advanced layout concept in Section 4.4.4. Example 4.4: The event package in JFtp, as contrasted to a clustered modularization in Figure 4.30, consists only of a single, nearly black mutual block—all code entities of the package belong to the 0.0.2 cluster. Looking at the mutual blocks of the 0.0.2 cluster, however, reveals that the opposite is not the case: the cluster contains two additional code entities not contained in the event package. In contrast to the event package, the gui package is not as well-matched by the clustered modularization as it is indicated by several white to gray mutual blocks: it is only partly similar to the 0.0.4, 0.0.3, and 0.0.0 clusters and shares some code entities with further clusters. The additional encoding of the similarity of modules in the mutual blocks makes the information easier to retrieve because the user only has to look at the icicle plot to see how far the modules of one modularization are matched by the other modularization. Moreover, the mutual blocks help revealing details like small variations between two compared modules, for instance, the difference of two code entities between the event package and the 0.0.2 cluster in the previous example. But still, the encoding of similarities as a background pattern of the matrix is important because only it supports quickly finding the specifically matching counterpart of a module.
4.4 Matrix Approach
97
Besides building mutual blocks, the local sorting approach also leads to selfreferencing cells forming local diagonals in the matrix (Figure 4.30). These cells are indicated by simple, partly transparent black-and-white checkerboard patterns. This technique clearly separates the cells from the shaded background—no matter if it is black, gray, or white—without using additional colors or disproportionately affecting the overall brightness of the respective area. As already discussed previously, two concepts of coupling are encoded by filling the matrix cells in three different colors. A legend shows the assignment of colors to the two concepts—in Figure 4.30, blue is used for structural dependencies, red for evolutionary coupling, and duplicate edges are marked in purple. Weights of edges are encoded in the opaqueness of the colored cells; the weight of duplicate edges is defined as the sum of the two original weights.
Basic Interaction Interactions enable the user to focus the analysis or to retrieve details on demand. The visualization tool implements Shneiderman’s Visual Information Seeking Mantra [240]—overview first, zoom and filter, then details-on-demand —as discussed in the following. Overview: The default view of the visualization—for instance, the one presented in Figure 4.30—provides an overview: No scrolling operations or other interactions are needed to view the whole dataset. The encoding of module similarity allows for comparing the two modularizations on a high level of abstraction. The distribution of colored cells provides a rough outline of the graph structures at first glance. Differences in the two visualized concepts of coupling can be analyzed by comparing the colors of the marked cells. In particular for larger software projects, however, it could get harder to retrieve the exact source and target of an edge or the exact row and column of a self-referencing cell without further interaction. Zoom and Filter: Zooming enlarges parts of the diagram to make details easier to perceive. The implemented zooming approach is similar to the one used in the node-link approach: modules can be zoomed without displacing other modules from screen—focused modules become larger while the other modules get smaller; no scrollbars are necessary. Allowing zooming independently for both modularizations again creates a multi-focus approach similar to Table Lens [223]. Also a filtering technique is implemented: the different types of colored cells representing the two concepts of coupling can be switched on and off independently. This is useful on screens or projectors with a low color contrast or when analyzing large graphs where the cells of the matrix are very small.
98
4 Visual Comparison of Code Couplings
adjacent classes highlighted module incoming
outgoing
color: concept of coupling
Figure 4.31: Details retrieved on demand for the util package showing adjacent code entities.
Details-on-Demand: When hovering the mouse over modules, code entities, or colored cells in the matrix, additional details for the respective entity are displayed and related entities are highlighted in the visualization. For hovered modules or code entities, the respective rows and columns are highlighted by a transparent overlay and the name is provided in an additional label. Moreover, adjacent code entities in the graph structure are marked in the icicle plots as illustrated in Figure 4.31: A code entity gets marked by a small box if there is at least one adjacent code entity among the highlighted ones; the type of adjacency (i.e., the concept of coupling) determines the color of the marker. If the marked code entity is adjacent because of an incoming edge, the marker is added at the left side (in the first modularization) or at the top (in the second modularization); analogously, outgoing edges pointing to highlighted code entities are marked at the right side or at the bottom, respectively. As the example in Figure 4.31 shows, incoming and outgoing edges can, of course, occur concurrently. For hovered colored cells in the matrix, source and target of the respective edge are identified and highlighted also by labels and transparent overlays. As a further details-on-demand technique, the source code can be accessed by double-clicking on the representation of code entities in the icicle plots. These features provide a rich variety of interaction, which often allow for different ways to solve a task—the user may choose the individually convenient solution. For example, the couplings connecting two modules of interest from different modularizations can be analyzed by looking at the intersection of the two modules in the matrix and retrieving details on edges by hovering the colored cells. But the same task can also be tackled by hovering the first module and then looking and the marked adjacent code entities in the second module. Level of Detail Two hierarchies can be different on one level while they are similar on another level (Figure 4.25). When dealing with results of hierarchical clustering the generated
4.4 Matrix Approach
99
Figure 4.32: JFtp with different levels of detail in the modularization: default view with no collapsed nodes (left) and adapted level of detail (right, equivalent to Figure 4.30).
hierarchies could have very different granularity and depth. Hence, it is important that the users are supported in comparing the hierarchies on multiple levels of detail. The encoding of module similarity as the background structure of the matrix supports the comparison of the two hierarchies at the most fine-grained level of modules. For changing the level of comparison, the user needs to interactively collapse modules in the modularization, which is triggered when clicking on the modules in the icicle plot. Collapsing a module neither changes its size nor folds its code entities but only hides all submodules—code entities originally organized in submodules become direct children of the collapsed module. Accordingly, the background structure comparing the two hierarchies also adopts to the more coarse-grained level. A collapsed module is indicated by a gray border line between the module and its containing code entities. It goes without saying that all collapsed modules can be expanded again to its previous state by another click. Example 4.5: Figure 4.32 provides an example where the default, noncollapsed visualization of the JFtp project is contrasted to a variant with an adapted level of detail. Judging according to the background pattern of module similarities, the hierarchies seem to be more different on the fine-grained levels of the default view than when collapsing certain nodes. For instance, when collapsing the 0.0.2 cluster, it becomes apparent that the cluster is very similar to the event package—a nearly black rectangle appears in the upper left corner of the matrix. When collapsing further
100
4 Visual Comparison of Code Couplings
modules targeting at finding such similar modules, the user might transform the view of Figure 4.32 (left) into a view similar to Figure 4.32 (right).
To ease collapsing and expanding of multiple modules, small, stripe-shaped controls are attached at the sides of the hierarchies. They enable the user to hide or unhide complete levels by collapsing or expanding every individual module of the level. The colors of the controls indicate whether a level is totally expanded (black), partly expanded/collapsed (dark gray), or totally collapsed (light gray).
4.4.4 Advanced Layout Although the presented approach is already quite complex, advanced concepts of layout may still enhance the interactive visualization approach. The concepts described in the following aim at automatically finding an appropriate level of detail creating matching partitions in order to relieve the user of manually adapting the modularizations. Moreover, a good ordering of modules and code entities needs to be found that facilitates the hierarchy comparison. In the figures of the matrix visualization presented so far, these advanced layout features were already anticipated, yet not properly discussed in the text. Adaptive Level of Detail While it might be acceptable to manually find similar partitions in different levels of detail of the two modularizations for small projects such as JFtp, the task becomes tedious for larger projects. Hence, it is desirable to provide an algorithm that supports this task. However, there could be multiple levels of modules providing appropriate matches. In the end, the users have to decide whether they are interested either in more fine- or coarse-grained modularizations. When manually collapsing or expanding modules, the user usually aims at finding similar modules represented as dark gray or black boxes in the matrix. Hence, informally, the goal can be defined as maximizing the number of dark rectangles in the visualization. More precisely, this form of seeking conformance between the modularizations might be expressed as the following objective: Objective 4.4: Conformance—The lowest levels of modules are to match as far as possible. Defining an algorithm that meets this objective is trivial: just collapse the root modules of both modularizations; then, the root modules form the lowest levels of
4.4 Matrix Approach
101
modules and are equivalent because both modularizations contain the same set of code entities. Since this is not the intended solution, conformance cannot be the only criterion for the algorithm. It also has to be assured that the modularizations still contain significant information and are not collapsed beyond a certain level. Objective 4.5: Significance—The structure of both modularizations is to be preserved to a certain extent.
As the example of collapsing the root modules shows, the two objectives might be competing—an algorithm has to find a trade-off between the two. Optimization Criterion To maximize the conformance between the current states of the two modularizations (Objective 4.4), a precise metric is required that assigns a similarity value to the two states. A state of the modularization is determined by the currently lowest level of modules, which can be represented as a partition P of the set of code entities (i.e., a non-hierarchical modularization instead of a hierarchical one as defined in Definition 3.8). The Jaccard Coefficient, as used before to express the similarity of two modules, can also be applied for comparing the modules of the two partitions. The overall similarity of two partitions P1 and P2 can be determined by summing up all pairwise similarity values: X X sim(P1 , P2 ) = ωA,B · sim(A, B) A∈P1 B∈P2
A factor ω is inserted in order to take into account the different sizes of the modules: combinations of larger modules should be rated higher than those of smaller ones— otherwise, optimizing the similarity of partitions, an algorithm would preferably opt for the most fine-grained partitions. In particular, the factor can be defined as the summed sizes of the two modules: ωA,B = |A| + |B|. Significance Level Thresholds When optimizing the above similarity function, only conformance is considered (Objective 4.4), not the significance criterion (Objective 4.5). While it would be possible, but complicated to define a further optimization criterion and then apply multi-objective optimization, introducing user-defined thresholds for assuring the significance of the modularizations is quite simple and straightforward: For each modularization, a threshold defines a level that restricts the algorithm in collapsing modules; beyond that threshold, modules are not allowed to be collapsed. Defining two levels independently for the two modularizations, the user is also able to switch between different matching partitions on different levels of detail.
102
4 Visual Comparison of Code Couplings
Figure 4.33: Controls for selecting the significance level thresholds for the adaptive level-of-detail algorithm (detail of Figure 4.30).
Setting the two thresholds—one for each modularization—requires additional controls in the visualization. These are provided by the grid pattern in the upper left part of the visualization, which is already included in Figure 4.30 and depicted enlarged in Figure 4.33. Each combination of levels is represented by an individual control in the grid structure, which is aligned to the two icicle plots. Clicking on one of the controls not only defines the thresholds but also starts the optimization algorithm.
Example 4.6: In Figure 4.33, the user clicked on the control in the fourth row and third column of the grid pattern, which is indicated by highlighting the control in dark gray: the algorithm is not allowed to collapse modules higher than the third level of the first modularization (package structure) and higher than the fourth level of the second modularization (clustered modularization). This can be confirmed in Figure 4.30, which shows the resulting visualization completely.
Optimization Algorithm Optimization criterion and thresholds together form a constrained optimization problem that is to be solved by an algorithm. The straightforward, brute-force approach is to test every combination of collapsed and expanded modules in the two modularizations. This, however, is only feasible for very small modularizations because the number of modularization states could grow exponentially in the number of code entities n, already for a single modularization: In case of a complete binary tree, there exist n2 modules on the lowest level of and n4 on the level above. In particular, the modules on the level above the lowest one need to n be collapsed and expanded in all combinations, which already results in 2 4 different partitions for the first modularization.
4.4 Matrix Approach
103
Hence, a heuristic needs to be applied to solve the problem for a realistic dataset: A hill climbing algorithm is implemented in the tool that starts from collapsed modules (collapsed as far as the significance thresholds allow) and tests expanding modules step by step. If the optimization criterion can be improved by the expansion of a module, the expansion is preserved for all following steps; otherwise, the module is collapsed again. In detail, the algorithm works as follows: Algorithm 4.1 (Adaptive Level of Detail): 1. Collapse all modules up to the levels provided by the significance thresholds in the two modularizations. 2. For each collapsed module of the first modularization: a) Expand the module (partition P1 is transformed into P10 ). b) Compare the new partition to the second partition P2 : if sim(P10 , P2 ) > sim(P1 , P2 ) (improved similarity), the expand operation is preserved; otherwise, it is undone. 3. Test expanding modules and preserve improvements for the second modularization analogously to (2). 4. If (2–3) did not improve the similarity, expand each combination of a collapsed module from the first modularization and a collapsed module of the second modularization; preserve improvements analogously to (2). 5. While (2–4) improved the similarity of the partitions, repeat from (2).
As some ad-hoc experiments showed, costly operation (4), which tests all combinations, appears to be necessary for skipping early local optima. Otherwise, when only expanding the modules individually, the algorithm would terminate in these suboptimal solutions. Evaluation A small evaluation of the algorithm is conducted to analyze the impact of the algorithm on the task of finding matching partitions in the two modularizations. To this end, with and without the algorithm, the numbers of interactions are counted that are required to reach a certain reference state. Namely, three conditions are discerned: modules can be collapsed and expanded (a) manually only one by one, (b) manually by level, and (c) by applying the algorithm. Each condition also includes the interactions allowed in the previous conditions. It is assumed that the user takes the shortest path to reach the goal in each condition. Each interaction requires one click (also applying the algorithm) and is counted as one operation consequently. The hypothesis is that using the algorithm in condition (c) requires
104
4 Visual Comparison of Code Couplings
much fewer operations than using the manual interactions alone in conditions (a) and (b). The evaluation considers the six real-world software projects that are also analyzed in the case study (Section 4.4.5). For each project, its package structure is compared to a clustered modularization. To make the evaluation fair, subjectively matching partitions are searched manually without using the algorithm or knowing the result of the algorithm. Then, for each condition, this reference state is retrieved by applying the allowed interactions starting from totally expanded modularizations. The results confirm the initial hypothesis: To reach the reference states, 36.7 interactions are required on average in condition (a), 16.0 interactions in condition (b), and 7.3 interaction in condition (c). Thus, using the algorithm in condition (c), the user would only need 20% of the number of interactions required when only manipulating the modules one by one in condition (a) or 46% of the number of interactions when also using the level manipulation mechanism in condition (b). Moreover, the low number of interactions in condition (c) suggests that the algorithm creates meaningful results not far from the manually created solutions. Sorting Comparable to the node layout in a node-link diagram, ordering the rows and columns of a matrix visualization is an important layout decision. Without a meaningful order, it is hard to read a matrix diagram—it might even get difficult to distinguish its structure from a random structure [197]. In contrast, a good ordering can reveal clusters, outliers, hub-nodes, etc. Mueller et al. [197] as well as Henry and Fekete [131] discuss different algorithms for finding a good matrix layout. While general ordering algorithms assume that each row or column can be rearranged without restrictions, an additional hierarchy limits the degrees of freedom for a layout algorithm: only sibling elements can be switched without destroying the hierarchical structure. As the hierarchy usually provides a meaningful order, these restrictions, however, could be an advantage: no matter what further ordering is applied, the layout does not fall below a certain standard provided by the hierarchy. Nevertheless, the layout can still be improved to some extent. In comparison to usual matrix-based graph visualizations, the ordering problem is somewhat different for the presented matrix approach: instead of one hierarchy, two hierarchies restrict the ordering. This also destroys the former diagonal of the matrix containing the self-referencing cells—these cells are now spread across the whole diagram. The diagonal, however, is an important reference for interpreting a matrix visualization [198]. Two sorting approaches are introduced in the following, which try to restore the diagonal as far as possible: the first one tackles the local sorting of code entities in the modules, the second one regards the global layout of the modularizations.
4.4 Matrix Approach
105
Local Sorting When looking at a module from the lowest level in one of the two modularizations, the contained code entities are distributed across the other modularization. This distribution is reflected by the initially chaotic arrangement of self-referencing cells belonging to code entities of the module. The goal is now to arrange these cells into a structure that is similar to a diagonal—these structures are denoted as local diagonals. If all pairs of self-referencing cells of the current module form a descending line (read from left to right), this goal can be considered as met for this module: at least from the viewpoint of the module, the cells build a diagonal, which is only interfered by some code entities belonging to other modules; the imaginary curve of self-referencing cells forms a monotonously decreasing line. The sorting algorithm, hence, needs to switch all pairs of code entities within a single module that form an ascending line, for each module on the lowest level in the two modularizations. But instead of checking all pairs of code entities, it is easier to just search for the code entity of the current module that comes first in the other hierarchy, then for the second code entity, etc. Arranging the code entities of each module like this—first for the first modularization, later for the second—also guarantees descending lines and creates local diagonals in the matrix. Algorithm 4.2 (Local Sorting): 1. For each module on the lowest level of the first modularization, sort all code entities of the current module in the order they are listed in the second modularization. 2. Repeat the same procedure vice versa for each module of the second modularization.
Besides restoring local diagonals, the algorithm automatically groups those code entities together that belong to the same module in the other hierarchy. These groups, which were already introduced as mutual blocks in Section 4.4.3, are visually encoded by assigning the same background color to the respective code entity representations in the icicle plots—they ease the comparison of a module to the modules in the other hierarchy. Example 4.7: Figure 4.34 illustrates the local sorting algorithm in a small example: First, module A (first hierarchy) is processed: the selfreferencing cells of a and b form an ascending line; hence, a and b need to be switched. Though, in module B, d and e are ordered properly, c needs to move up. Finally, the first modularization is ready: all pairs of code entities within the two modules form descending lines. Continuing with ordering the second hierarchy, only e and b in module D are to be
106
4 Visual Comparison of Code Couplings
1st
C D a c d e b
b a d B e c
3rd
A
C D a c d e b
a b c B d e
ascending line
4th
C D a c d b e
a b c B d e
A second modularization
C D a c d e b
a b c B d e
A first modularization
2nd
A
descending line
incorrect order
correct order
. Figure 4.34: Example illustrating the local sorting algorithm; descending pairs of self-referencing cells are indicated as green lines, ascending ones as dashed red lines.
4.4 Matrix Approach
107
switched. In the end, also the second modularization is ordered properly. Please note that reordering the second modularization in general does not destroy any sorted pairs (i.e., descending lines) with respect to the first modularization.
When collapsing or expanding a module in the visualization, the local sorting algorithm needs to be reapplied because the lowest level of modules changed. The current, straightforward implementation of the algorithm is fast enough for not notably decreasing the responsiveness of the tool when changing the level of detail, even for larger projects. Global Sorting While local sorting changes the arrangement of the code entities within the modules, the order of the modules themselves has not been touched yet. Optimizing the order of sibling modules promises to bring the retrieved local diagonals closer to the original global diagonal. This would make the visualization easier to interpret: Similar modules can be found near the diagonal at first glance and are placed in the two modularizations at similar positions. Moreover, modules that could not be matched by the other modularization, may catch the eye of the user because they show up as mid or light gray rectangles far from the diagonal. Since there is not a one-to-one mapping of modules between the two modularizations, global sorting is more complex than local sorting and the local sorting algorithm cannot be applied. Nevertheless, the goal of reducing ascending lines between pairs of self-referencing cells can be transferred from within the modules to the global scale: the optimization criterion for a global sorting algorithm is to minimize the overall number of ascending lines between arbitrary pairs of self-referencing cells. This optimization problem, however, is NP-hard because it is equivalent to the problem of minimizing edge crossings in a hierarchy comparison approach based on edge drawing (compare to Figure 4.26), which is denoted as the tanglegram layout problem [202] or the two-tree crossing minimization problem [99]. Example 4.8: Figure 4.35 (top) illustrates the equivalence of the two problems in a small example: The matrix on the left shows the selfreferencing cells and all ascending lines between them—descending lines are omitted for simplification. Drawing additional links on top of the matrix connecting the equivalent code entities, as it is done in the middle of the figure, produces a number of edge crossings. Counting the number of ascending lines a and the number of crossings b, it turns out that a = b = 5. Blending out the matrix and moving the second modularization from top to right leads to a diagram that is defined in the tanglegram layout problem.
108
4 Visual Comparison of Code Couplings
Example C
D
A
E
B
C
E
A
D
B
B
C
C
C
D
D
D
E
E
E
crossings: b = 5
ascending lines: a = 5
B
B
E
B
A
A
D
A
C
A
crossings: c = 5
Induction: a = b = c n=1
1
1
1
a1 = 0 n-1 → n
1
1
n
c1 = 0
b1 = 0 k vertices
1
n n k lines k vertices
n
n
an = an-1 + k
n
bn = bn-1 + k
cn = cn-1 + k
Figure 4.35: Example and illustrated proof by induction showing the equivalence of minimizing ascending lines between self-referencing cells and the tanglegram layout problem.
4.4 Matrix Approach
109
The number of edge crossings c in this tanglegram is the same as before in the example: a = b = c = 5.
As the example suggests, the equivalence between the two problems can be verified by showing that a = b = c holds in general, which is proved by induction in the following (the proof is illustrated in Figure 4.35, bottom). For n = 1 vertex, the situation is trivial because there neither can be any ascending lines nor any edge crossings; hence, a1 = b1 = c1 = 0. When assuming that the equation holds for n − 1 (an−1 = bn−1 = cn−1 ), it can, furthermore, be shown that it is also true for n: Without loss of generality, the nth vertex is inserted in the first hierarchy as the last element. • In the matrix, the nth vertex is positioned in the last row. The position of the column, however, depends on the second hierarchy—k columns, where 0 ≤ k ≤ n − 1, follow the column of the nth vertex. Since the k columns have to include k self-referencing cells, this introduces k new ascending lines while the number of previously ascending lines stays unchanged; thus, an = an−1 +k. • When switching to edges, no lines are crossed in the horizontal part of the edge, because the nth vertex is the last element in the first hierarchy. In the vertical part of the edge, however, there appear k new crossings, again because of the k self-referencing cells in the k last columns: bn = bn−1 + k. • Finally, in the tanglegram layout, the new edge has to cross k vertices in the second hierarchy, each having an incoming edge that starts somewhere above the new vertex in the first hierarchy; this again introduces k new crossings: cn = cn−1 + k. Hence, an = bn = cn because inserting the nth element increases the number of ascending lines or the number of edge crossings respectively by a constant number k. This proved, the consequence is that there does not exist any efficient exact solution for minimizing the number of ascending lines for globally sorting the modules of the matrix visualization. Nevertheless, heuristic solutions developed for the tanglegram layout problem can be directly applied in the current sorting scenario. In particular, a simple and fast heuristic proposed by Holten and van Wijk [139] is implemented in the tool; it is based on the barycenter method that was originally introduced by Sugiyama et al. [251] for computing the ordering of nodes in layers of a hierarchical graph layout. Alternative heuristics for the problem as those evaluated by N¨ollenburg et al. [202] cannot be applied because they require binary hierarchies.
110
4 Visual Comparison of Code Couplings
Algorithm 4.3 (Global Sorting): Wijk [139])
(according to Holten and van
1. Determine the currently deepest level of modules as the maximum level in each of the modularizations and consider these as the current level. 2. Process the modules of the current level in the first modularization as follows: a) Compute the barycenter of each module by averaging the index of all contained code entities determined by the positions of the code entities in the second modularization. b) Rearrange the modules in the order of their barycenters. 3. Rearrange all modules of the current level in the second modularization analogously to (2). 4. If the current level is not the level of the root module in both modularizations, collapse all modules on the current level in both modularizations and continue with (1). 5. Start from totally collapsed modularizations and apply an analogous procedure to (1–4) while stepwise expanding the levels of the modularizations. 6. As long as (1–5) still changed the ordering, repeat from (1).
If the number of repetitions in (6) is restricted to a constant maximum and in case of binary hierarchies, the algorithm runs in O(n · h) for n vertices and a maximum hierarchy height h [202]. In contrast to local sorting, the global sorting algorithm only needs to be applied once on startup because collapsing a module only changes the local structure of the modularization, not the global one. Although it would be possible to also use the global sorting algorithm for local sorting, it is not applied: the global algorithm is just a heuristic solution while the local sorting algorithm computes the exact solution for the simpler problem. Evaluation As a brief ad-hoc evaluation of the two sorting approaches, the effect of sorting is demonstrated in an example by contrasting images of sorted visualizations to equivalent non-sorted ones. Local sorting and global sorting have different impact and are discussed independently. Figure 4.36 shows a clustered modularization of the Azureus project without applying any sorting (top) and with applying local sorting (bottom). The main difference
4.4 Matrix Approach
111
Figure 4.36: Visualization detail of a clustered modularization for the Azureus project without local sorting (top) and with local sorting (bottom).
Figure 4.37: Comparing the package structure and a clustered modularization for the Azureus project without global sorting (left) and with global sorting (right).
is that mutual blocks are not grouped properly without local sorting—the code entity representations in the first diagram look more like a bar code than blocks of grouped elements. Moreover, without sorting, no local diagonals show up in the matrix (not in the figure), which makes the visualized graph structure harder to read. The effect of global sorting is demonstrated in Figure 4.37—while both diagrams use local sorting, global sorting is only applied in the second diagram: Without global sorting, dark gray boxes are scattered across the matrix; retrieving which module is matched by which modules of the other hierarchy requires inspecting each module individually. In contrast, in the sorted version, matching modules can be found at first glance as dark gray rectangles on, or at least near, the diagonal. Moreover, it is easy to find modules that are not matched by the other modularization because of gaps in the diagonal. These non-matched modules can also be detected by mid gray
112
4 Visual Comparison of Code Couplings
boxes off the diagonal. In Figure 4.37 the util package in the first modularization is an example for that.
4.4.5 Case Study Like applied for the node-link approach, a case study demonstrates the usefulness of the approach—the formulated objectives (Section 4.3.1 and Section 4.4.1) provide different usage scenarios. Since the motivation for designing the new visualization mainly goes back to analyzing the results of the feasibility study (Chapter 2), this dataset is investigated in closer detail. The observations described in the following are based on visually analyzing six software projects: Azureus, JEdit, JFreeChart, JFtp, JUnit and Tomcat—these were the projects originally studied in the first version of the clustering study [21]. Since large images cannot be presented for all six systems, only diagrams for Azureus are included in the thesis; Azureus consists of 477 classes and interfaces organized in 69 packages. As the dataset of the feasibility study is analyzed, again the Structural Class Dependencies Graph (SCDG) and the Evolutionary Class Dependency Graph (ECDG) as defined in Section 2.2.1 come into play. These graphs are similar to the concepts of coupling defined later, but not equivalent: In particular, the SCDG is a union of the three concepts SD.Inh, SD.Agg, and SD.Use. The ECDG, in contrast, is a filtered version of the SD.Sup and the SD.Conf graphs, where support and confidence values serve as filtering thresholds. Hence, the results of the case study can be transferred with minor restrictions to the respective concepts introduced in Section 3.3. Compare Couplings Derived from Objective 4.1 and Objective 4.2, the first usage scenario is to compare different concepts of coupling in the context of a modularization. Like empirically compared in the feasibility study, structural dependencies (SCDG) are compared against evolutionary couplings (ECDG). At first, only the package structure is attached to both sides of the matrix. Figure 4.38 presents the according visualization for Azureus: SCDG edges are depicted in blue while ECDG edges are encoded in red; purple is used for duplicate edges. All features related to the comparison of modularizations—background patterns, adaptive level-of-detail algorithm, etc.—are automatically turned off because only one modularization is provided in this example. As it can be retrieved from Figure 4.38 and respective figures for the five other projects, the two concepts of code coupling form different kinds of graph structures: Structural Dependencies (SCDG): The structural dependencies are spread across nearly all code entities, but the graphs are quite sparse. Often clusters show up at the diagonal indicating cohesive packages; the coupling between the
4.4 Matrix Approach
Figure 4.38: Azureus project comparing the SCDG and the unfiltered ECDG00.0 having the package structure attached.
113
114
4 Visual Comparison of Code Couplings
packages in contrast is fairly low. Some code entities, often concentrated in a few packages per system, form key entities with a high in-degree or out-degree, which can be detected by looking for vertical or horizontal lines of colored cells. Evolutionary Couplings (ECDG): In contrast, the graph of unfiltered evolutionary couplings is quite dense; but when increasing the filtering thresholds of the ECDG, the graphs become rather sparse (not in the figure). Only some clusters of edges can be found on the diagonal. These clusters, however, form denser subgraphs than the clusters of the structural dependencies (e.g., the tracker.protocol.udp package in Azureus). But in general, the packages are coupled quite strongly. Analyzing the intersection of both concepts which is represented by purple edges in Figure 4.38, it is interesting to note that only few duplicate edges exist—this is also the case in the other studied systems. Hence, structural dependency does not imply evolutionary coupling, or vice versa. Nevertheless, the few duplicate edges primarily seem to connect code entities from within the same package. Compare Modularizations While the previous scenario could have already been tested in the node-link approach, the second usage scenario covers the hierarchy comparison—the distinctive feature of the matrix approach. In the following, the package structures of the systems are compared to clustered modularizations. Moreover, structural dependencies are again contrasted to evolutionary couplings—the clustered modularization was generated based on the combined information of the two concepts. Figure 4.39 shows the according visualization for the Azureus project and Figure 4.30 already an equivalent visualization for JFtp. The adaptive level-of-detail algorithm is applied for finding matching modules at a mid-level of detail. Contrasting the two modularizations, the packages can be grouped by their degree of similarity to the clustered modularization: Well-Matched Packages: Dark mutual blocks in the icicle plots or dark rectangles in the matrix indicate packages that are very similar to one of the clusters. Looking at the colored cells within the rectangles helps to retrieve why the clustering algorithm grouped those code entities together. Partly-Matched Packages: A weaker form of matching is when a package would only be well-matched by the union of a small set of clusters or by a part of a larger cluster. The first case results in a set of vertical mid-gray rectangles in the rows of the package, the latter case in a set of horizontal mid-gray rectangles in the column of the respective cluster. Usually, a better match is not available for these partly-matched packages or the thresholds of the level-of-detail algorithm needs to be adapted.
4.4 Matrix Approach
115
Figure 4.39: Azureus project comparing the SCDG and the filtered ECDG00.8 ; the package structure is contrasted to a clustered modularization based on combined structural and evolutionary data.
116
4 Visual Comparison of Code Couplings
Non-Matched Packages: Packages that are distributed over diverse clusters cannot be considered as matched. They show light-gray mutual blocks and respective light-gray rectangles in the rows of the package.
Example 4.9: In Figure 4.39, a large well-matched package is the disk package; its dark rectangle includes many blue cells, but only a few red and purple cells—this implies that the package was retrieved by the clustering algorithm mainly due to structural dependencies. A well-matched package based on evolutionary couplings is the tracker.protocol.udp package, which mostly contains red cells. In contrast, the client package is only partly matched by two clusters. Examples for partly-matched packages contained in the same cluster are the peer and download packages. Finally, an example for a non-matched package is the util package.
All analyzed projects, like also Azureus and JFtp, contain only a few well-matched packages. Those can usually be traced back to structural dependencies, but sometimes also to evolutionary coupling or a combination of both concepts. Most other packages are partly-matched in the majority of projects. While in Azureus the dark and mid-gray rectangles of matched packages form a clear diagonal structure, other projects show a more decomposed pattern such as the JUnit project in Figure 4.40 (left). This indicates that the package structure and the clustered modularization are only similar on a fine-grained level, not on a higher level of abstraction. Normally, only a few packages have to be counted as non-matched—examples for that are often utility packages, which are hard to retrieve for coupling-based clustering approaches due to their special purpose [8]. In some runs of the clustering algorithm, however, the whole package structure is not well-matched on any level—Figure 4.40 (right) presents an example for JEdit. In these cases, the first level of the clustered modularization usually was already too fine-grained for being matched with the package structure. These observations help understanding the clustering results of the feasibility study and hint at their practical applicability: The large amount of partly-matched and well-matched packages suggests that the clustering results are meaningful in general. However, the differences are still too big so that restructuring the complete system strictly according to a clustered modularization probably would confuse the developers. The fact that well-matched clusters are often based on structural information fits the result of the feasibility study: clustering based on structural information performs better than on evolutionary information only. But combining both improves the clustering—a few more packages become well-matched. This provides an intuition on the results of the feasibility study, which the raw numbers, in terms of MoJoFM values, cannot provide.
4.4 Matrix Approach
117
Figure 4.40: Examples for limitedly matching package structures and clustered modularizations: JUnit (left), JEdit (right).
Moreover, the visualization reveals weaknesses of the applied clustering approach. First, packages having a special purpose like utility packages are often not wellmatched—a preprocessing step identifying those as proposed by Mancoridis et al. [176] may ease this problem. Second, the clustered modularizations are sometimes too flat so that they do not include an appropriate level of granularity. A solution might be forcing the clustering algorithm to compute more intermediate steps.
4.4.6 Summary The second presented visualization technique facilitates the comparison of two modularizations by applying a matrix-based comparison approach; an adjacency matrix visualization of code couplings is integrated into the approach and allows also contrasting two concepts of coupling (Section 4.4.2). Different static and interactive features improve the hierarchy comparison: First, encoding the similarity of modules between the two modularizations lifts the level of abstraction from code entities to modules (Section 4.4.2). Second, by interactively adapting the level of detail for the modules, which is supported by an algorithm, different levels of modules can be compared (Section 4.4.3 and Section 4.4.4). Third, partly restoring the diagonal of the matrix by local and global sorting promises to increase the readability of the visualization (Section 4.4.4). A case study provides first evidence on the usefulness of the approach (Section 4.4.5).
118
4 Visual Comparison of Code Couplings
4.5 Explorative Evaluation Additional to the two case studies, a user study was conducted for exploring how software developers compare different concepts of coupling with the help of visualizations. In particular, the node-link approach presented in this thesis was contrasted to the matrix approach by Zeckzer [299], which is similar to the matrix approach introduced above—directly comparing the two visualization approaches of this thesis would have been difficult because of their different focus and the limited abilities of the matrix approach concerning the representation of multiple concepts of coupling. The objective of the user study was observing participants use the visualization for analyzing software systems in a realistic scenario: What visual patterns do they identify? How are these related to software engineering tasks? How do the participants apply a visual comparison between multiple concepts of coupling? The matrix visualization that is used as the second visualization in the study is shown in Figure 4.41 for the JFtp project complementing the node-link representation in Figure 4.21. This matrix approach is based on an adjacency matrix representation of the coupling graph. As already illustrated in Figure 4.8, it divides the cells of the matrix into subcells, each cell representing a different concept of coupling at a fixed position. Like shown in the legend attached to Figure 4.41, different colors additionally discern the concepts of coupling. Besides using subcells, another distinction between this multi-matrix approach and the matrix approach presented in this thesis is that the same, not different hierarchies are shown as icicle plots attached to the rows and columns of the multi-matrix.
4.5.1 Experimental Design The user study was designed as a within-subject lab experiment, that is, visualizations of both kinds were shown to each participant. The study started with a short tutorial on the dataset and the multiple types of couplings. Then, each participant was familiarized with one of the visualization techniques by another short tutorial and a trial period for working with the interactive visualization tools. As a first test, a printed version of the visualization was handed to the participant, who was asked to mark interesting visual patterns in the visualization. As a second test, the participant then was intended to further analyze three of the marked patterns using the interactive visualization tool, which was showing the same dataset. This procedure was repeated for the other visualization techniques—to counterbalance for possible biases, the order of the visualization techniques was systematically varied across all participants. Finally, the participant filled in a questionnaire. Multiple concepts of coupling were explored for different software projects in the study:
4.5 Explorative Evaluation
119
Figure 4.41: JFtp with multiple concepts of coupling visualized in the multimatrix approach; legend for subcell division and coloring.
• Six different concepts of coupling were employed, namely, the three concepts of direct structural dependencies (SD.Inh, SD.Agg, SD.Use), evolutionary couplings based on support (EC.Sup), type I code clone couplings (CC.I ) and semantic similarity based on tf-idf (SS.Tfidf ). To simplify the dataset for the participants, couplings with low weight were excluded and, for the remaining couplings, weights were evened out. • For the tests, four Java software projects were used as dataset in pairs of similar sizes: JFtp and JUnit as small datasets, Checkstyle and Stripes as medium ones. A participant either investigated the two small or the two medium datasets, each with a different visualization technique; the order of the datasets was also varied systematically. Further details on the dataset are listed as parts of Table 5.2. To design a fair experiment, the features of the two interactive visualization tools were adjusted: features not implemented in one tool were deactivated in the other tool. Namely, zooming, advanced selection and interactive comparison features were deactivated in the node-link tool. To reduce possible obstacles for the participants, also edges bundling was disabled. Eight software developers—four from industry, four from academia—volunteered for the experiment. They were experienced software developers with a median of 11 years of programming experience and having at least a Master’s degree in Computer
120
4 Visual Comparison of Code Couplings
visualization node-link multi-matrix
identify
infer visual patterns
interpret graph structures
domain-specific insights software engineering
Figure 4.42: Interpretation process for deriving software engineering insights from the presented visualizations in the explorative study.
Science or Mathematics; 7 of 8 used Java regularly as a programming language. None of them had deficiencies in seeing colors. On average, the experiment took 82 minutes including 30 minutes for the node-link part and 26 minutes for the multimatrix part.
4.5.2 Results The objective for the study was more on finding qualitative than quantitative differences between the visualization techniques. The results of the experiment were analyzed largely by applying methods such as the categorization of the users’ findings and interaction. In particular, the interpretation process of the visualizations as sketched in Figure 4.42 was investigated in detail: Looking at the visualization, the users first identify visual patterns that seem to be interesting. In order to make sense of these patterns, the users then have to infer to which underlying graph structures these patterns map. Only then, domain-specific insights on software engineering can be gained by interpreting the graph structures. In the paper-based test, the participants identified visual patterns that, nearly all, could be classified into four categories per visualization technique (Table 4.3, Visual Pattern). For the node-link approach these patterns largely match those discussed in Section 4.3.5 and are named accordingly: fan, beam, cross beam, and gap; only hour glass patterns were not identified independently. These four visual patterns each map to a graph structure (Table 4.3, Graph Structure): a fan indicates a vertex with high in-degree or out-degree, a beam hints at a group of similar edges within a single package, a cross beam also refers to a group of similar edges but between different packages, and finally a gap identifies a vertex without incoming or outgoing edges. Despite the different visualization paradigm applied, the four visual patterns in the multi-matrix visualization—named line, diagonal cluster, off-diagonal cluster, and empty area—refer to the same graph structures. What is even more, the number of participants that identified a pattern of a certain kind is pairwise virtually the same for node-link and matrix (Table 4.3, numbers in parentheses). Observing the participants explore the identified visual patterns, insights on software engineering tasks that potentially can be solved with the visualization techniques were inferred. In general, all conducted interactive explorations could be classified
4.5 Explorative Evaluation
121
Table 4.3: Categorization of identified visual patterns (number of participants in parentheses), their relation to graph structures and to software engineering tasks. Visual Pattern Node-Link
Multi-Matrix
Graph Structure
Software Engineering Task
fan (7)
line (8)
high degree
find a key entity
beam (8)
diagonal cluster (8)
within-package edges
understand a package
cross beam (6)
off-diagonal cluster (7)
cross-package edges
identify a high-level coupling
gap (2)
empty area (2)
no edges
into three tasks, again alike for the node-link and multi-matrix approach (Table 4.3, Software Engineering Task ): First, exploring vertices with a high degree results in finding key entities of the system. Second, a group of within-package edges usually initializes trying to understand the purpose of a package. And third, investigating a group of edges connecting different packages leads to identifying and understanding a high-level coupling between the two packages. Only exploring gap patterns or empty areas could not be assigned unambiguously to a certain software engineering task but was occasionally used also for the above other tasks. Compared to the application scenarios described in the case study for the node-link approach (Section 4.3.6), these task are similar: While identifying key entities is equivalent, understanding packages maps to cohesiveness and coupling and identifying high-level couplings is related to coupling outliers. Although gap patterns were found, participants did not explore loose ends or independent components. The ability of comparing multiple concepts of code coupling seems to have a positive impact on the interpretation process: a comparison was applied in 72% of the interactively analyzed patterns. Though the node-link approach separates the concepts of coupling in different columns while the multi-matrix approach integrates them in each cell, this percentage was, once more, nearly the same for node-link (74%) and matrix (70%). Among the software engineering task, particularly understanding a package (82%) and identifying a high-level coupling (89%) appear to profit from a comparison of concepts. Finally, the questionnaire confirmed the abstract similarity of the two approaches: While four participants overall preferred the multi-matrix approach, three participants liked the node-link approach more (one participant did not decide). Also, the participants rated the usefulness of the approaches alike—on a scale from 1 (positive) to 5 (negative), the node-link approach received 2.75 points on average and the multi-matrix approach 2.88 points.
122
4 Visual Comparison of Code Couplings
4.5.3 Limitations The results of the study are limited with respect to a number of factors: Besides a restricted generalizability and possible biases that could not all be controlled, the with-in subject design might level out difference of the two approaches to some extent: having already worked with one of the visualization techniques, participants might tend to retrieve similar information in the second visualization although the presented dataset is different. Another limitation is that, due to the qualitative method applied, quantitative statements with respect to efficiency and accuracy on potential differences between the approaches can hardly be made.
4.6 Discussion Two novel interactive visualization approaches for comparing concepts of code coupling are introduced in this chapter. Although designed for similar tasks, the two presented approaches follow a different paradigm: while the first is based on nodelink diagrams, the second is an adjacency matrix approach. The following paragraphs contrast the two approaches in further detail and discuss application scenarios in a broader context.
4.6.1 Contrasting the Two Approaches Different criteria can be considered for comparing the two approaches. Since the approaches were developed to meet certain objectives (Section 4.3.1 and Section 4.4.1), these objectives provide a first scale for assessing the techniques. Furthermore, interactivity played an important role in the two implementations and might not be directly reflected by the objectives. Considering the possibly large size of the datasets, another important criterion that is only partly included in the objectives is scalability. Contrasting the two approaches, these three aspects are discussed in the following and summarized in Table 4.4. Moreover, the explorative evaluation (Section 4.5) provides some additional insights. Objectives The difference in the objectives for the two visualization approaches is small: Both are supposed to enable the comparison of different concepts of code coupling (Objective 4.1) and to relate a modularization of the system to its coupling structure (Objective 4.2). The discriminating difference is that the second scenario also demands the comparison of different modularizations (Objective 4.3). Since this hierarchy comparison could not be included in the first visualization, this additional objective required a different visualization approach.
4.6 Discussion
123
Table 4.4: Summarized comparison of the two presented visualization approaches; differences are highlighted in italics.
Objectives
Node-Link Approach
Matrix Approach
comparison of coupling
comparison of coupling
related hierarchy
related hierarchy comparison of hierarchies
Interaction
Scalability
multiple focus approach
multiple focus approach
advanced highlighting
simple highlighting
interactive comparison of coupling
interactive level-of-detail
hundreds of vertices
hundreds of vertices
sparse graphs
sparse and dense graphs
n concepts of coupling
two concepts of coupling
Mainly testing the comparison of multiple concepts of coupling (Objective 4.1), the explorative study (Section 4.5) showed that the node-link as well as the matrix paradigm are suitable for this scenario. And despite the fundamental difference in the approaches, participants of the study were able to address very similar tasks in the two investigated visualization approaches and frequently compared multiple concepts of coupling without being explicitly instructed to do it. While these results apply directly to the introduced node-link approach, they can only be considered indirectly as an evaluation of the introduced matrix approach because a different matrix approach had to be tested due to reasons of comparability. The two approaches presented by this work fulfill their shared objectives with different focus: In the node-link-based comparison approach, comparing concepts of coupling (Objective 4.1) clearly is the main concern; it is already possible to compare a dozen concepts based on the juxtaposed node-link diagrams, but multiple interactive features further ease the task by supporting additional comparison strategies. In contrast, only two concepts can be compared with the matrix visualization. Here, the main focus is on the comparison of modularizations (Objective 4.3); many advanced features of the visualization tool—such as visualizing module similarities, local and global sorting, as well as adapting the level of detail—target at enhancing this form of comparison.
124
4 Visual Comparison of Code Couplings
Hence, choosing between the two approaches is simple for scenarios matching the objectives: If, in the application considered, two modularizations are to be compared (Objective 4.3), the matrix approach is the appropriate visualization technique. Otherwise, and particularly when contrasting more than two concepts of coupling (Objective 4.1), the premier choice among the two visualization approaches is probably the node-link approach. But as the explorative study showed, the multi-matrix approach by Zeckzer [299] can be applied as well for comparing multiple concepts of coupling. In scenarios where not all objectives match with those defined, simpler visualization techniques could be preferable. For instance, only visualizing a compound graph without comparing concepts of coupling, a traditional node-link representation might be chosen. Nevertheless, it is neither obvious nor yet evaluated that traditional approaches outperform the two introduced ones in simpler scenarios like these. Interaction Both visualization approaches as implemented support a set of standard interactive features such as focusing and highlighting (Section 4.3.3 and Section 4.4.3). Though following contrary basic layouts, the two visualization tools realize a similar focusing approach: a multi-focus technique comparable to Table Lens [223]. To preserve overview, in both tools, enlarging parts of the visualization does not lead to displacing other parts from screen, but just to reducing the size of non-focused elements. Also the highlighting approaches are similar for both visualization approaches, not visually but with respect to the information provided: highlighting a module by clicking or hovering, its label is displayed and adjacent code entities and related edges are visually marked. The two approaches, however, differ in the form of highlighting: in the node-link approach, edges are drawn in different colors, in contrast to the matrix approach, where small markers are added to the icicle plots. Moreover, highlighting is more important for the node-link approach—elaborate selection features help shaping the set of highlighted elements. Additional to standard interactions, the two approaches also support advanced, application-specific interactions: the interactive comparison features in the node-link approach (Section 4.3.3) and to the computer-supported selection of an appropriate level of detail for comparing two modularizations in the matrix (Section 4.4.4). These advanced interactions reflect the importance of the different objectives in the two visualization techniques. Though not vital for the approaches, the interactive enhancements seem to considerably increase the efficiency of the visualizations as indicated by the case studies (Section 4.3.6 and Section 4.4.5) and an ad-hoc evaluation of the adaptive level-of-detail algorithm (Section 4.4.4).
4.6 Discussion
125
Scalability One of the most challenging aspects of visualizing code couplings is scalability because coupling graphs usually consist of hundreds of vertices and thousands of edges, or even more. Since node-link representations might be intuitive, but usually not very scalable, serious effort had to be put into designing a scalable node-link representation (Section 4.3.2): the split linearized node layout finally allows for depicting a few hundreds of vertices in a readable way as demonstrated for Checkstyle with 261 code entities by the case study (Section 4.3.6) and by the explorative study (Section 4.5). Graphs with more vertices are getting harder to read because the small leaf nodes of the hierarchy cannot be unambiguously distinguished. Nevertheless, the coarse graph structure is still accessible, in particular when hierarchical edge bundling is applied and zooming can be used to enlarge areas of interests. A certain scalability is also suggested by the large scale datasets used in case studies for the related parallel edge splatting approach [22, 61]. However, it is still unclear which edge routing technique—straight lines, some form of bundled edges, or edge splatting—provides the most scalable visualizations. Some participants of the explorative study, where no bundling or splatting was applied, complained about edge clutter in the node-link tool. In contrast to node-link diagrams, matrix-based graph visualizations seem to be more scalable in general [115, 149]. Hence, less effort was necessary to come up with a scalable matrix approach. Again, a few hundreds of vertices are not problematic because colored cells are still easy to distinguish. When the cells are getting smaller with an even higher number of vertices, however, the colors of the cells become harder to discern—the different types of edges perhaps need to be switched on and off interactively for analyzing differences. But also zooming helps to interactively increase the readability of the visualization. With respect to a matrix-based hierarchy comparison, Graham and Kennedy [120] criticized the underutilization of the available screen space—something that does not apply to the same extent when integrating a graph and hierarchy comparison approach into the same matrix. Besides the number of vertices, the density of edges is an important aspect for the scalability of a graph visualization. With an increasing number of edges (for the same number of vertices), the matrix visualization gains against the node-link approach because of its inherent layout: while screen space is reserved exclusively for each possible edge in the matrix, the space is shared among different edges in the node-link representation leading to increasing edge overlap and clutter. Hence, the node-link approach benefits from sparse graphs while the edge density is not likely to have a strong effect on the readability of the matrix approach. Finally, the number of concepts of coupling that can be compared with the visualization approaches constitutes another aspect of scalability. As already discussed for the objectives, the node-link approach is more flexible because a dozen different concepts or more can easily be compared while only two concepts can be depicted
126
4 Visual Comparison of Code Couplings
at once in the matrix approach. But using split cells as done in the evaluated multimatrix approach [299] would extend the matrix approach for comparing more than two concepts.
4.6.2 Extended Application Scenarios First and foremost, the two visualization approaches were designed to meet the concrete needs for exploring code couplings in the context of this project. Nevertheless, the approaches are applicable as general software engineering tools for understanding and improving software systems. As the explorative evaluation (Section 4.5) shows, the premier application for comparing multiple concepts of coupling (Objective 4.1) seems to be program comprehension: the identified tasks are typical aspects of program comprehension; moreover, in the questionnaire, participants listed program comprehension as the main area of application. Building on that, the visualizations can also be used as a first step towards improving the design of a software system as rated as a second important area of application by the participants of the evaluation and as partly demonstrated in the case studies (Section 4.3.6 and Section 4.4.5). On a higher level of abstraction, in the taxonomy of Chikofsky and Cross [70], the objectives of the two visualization approaches (Section 4.3.1 and Section 4.4.1) can be considered as part of reverse engineering (in particular, design recovery) and restructuring. The level of abstraction, according to the taxonomy, is design. The two case studies (Section 4.3.6 and Section 4.4.5) supported by the explorative evaluation (Section 4.5) suggest concrete tasks the approaches can be applied for: Understanding the Architecture of a System: A modularization and couplings are the essential parts of a software architecture and need to be analyzed for comprehending a software system. This dataset can be visualized in a scalable way by both presented approaches, but also by other visualization techniques. The main discriminating features of the novel approaches are their capabilities of comparing different concepts of coupling. These capabilities promise to increase the understanding of the studied system because different concepts of coupling—which, otherwise, would need to be aggregated or shown in hardly comparable, separate diagrams—explain the system in different ways and tell different stories. For instance, the inheritance structure shows strong connections between code entities, evolutionary couplings tell which parts need to be changed together, or semantic similarity may identify similar features in the code. Finding Unwanted Couplings: For developers already familiar with a system, the visualization approaches may help to find unwanted and unexpected couplings in the system, which could be sources of bugs or obstacles for the future evolution of the system. Similar to architecture comprehension, a single concept of coupling may not provide the complete picture and aggregated concepts
4.6 Discussion
127
lose too much information. In contrast, the two approaches allow for checking whether a detected outlier coupling and potential unwanted dependency is also present in other concepts of coupling. For instance, for an unexpected evolutionary coupling, other concepts could provide explanations why the coupling appears (e.g., a code clone that need to be changed consistently). Restructuring the System: Often the quality of the software architecture erodes during the evolution of a software project and at some point the developers may want to restructure the system. Here, the matrix approach may have strong impact because two modularizations can be compared against each other—this is important when contrasting the current modularization to a new design, which might be created manually or generated automatically by clustering. And in contrast to other hierarchy comparison approaches, the couplings can be visualized along with the comparison—they might provide explanations why and how to restructure certain modules. However, the approaches are not limited to visualizing software systems and couplings within such systems: They can also be considered as a general approach for comparing different types of edges in compound graphs. This point of view opens up a variety of other applications because compound graphs are a versatile concept and different types of relations appear in many scenarios. To provide an example, the following scenario sketches how the two approaches can be used for social network analysis: Example 4.10: A social network consists of people connected to each other—hence, is a graph. The connections might be of different type: family, friendship, co-workers, or even opponents. Moreover, people could be hierarchically organized: for instance, in the context of work they belong to teams, departments, and companies. In other contexts there might not be a formal hierarchy, but by applying clustering, a hierarchical structure can be created out of the relationships between the people. Hence, the two approaches can be applied for comparing the different types of relationships, for instance, for investigating in which departments co-workers are also connected by friendship. Furthermore, it might be of interest to contrast different hierarchies. As an example, consider a collaboration network of colleagues and a hierarchical clustering derived from it: the clustering can be compared against the department structure of the company in the matrix approach also showing the concrete collaboration connections. Interesting findings could be pairs of highly coupled departments or departments which fall into multiple parts and may require restructuring.
128
4 Visual Comparison of Code Couplings
CHAPTER 5 Empirically Analyzing the Congruence
Clusters of code couplings—no matter to which concept one refers to—indicate cohesive structures within a software system. These clusters should be placed into the same module to make the system more comprehensible and to ease future changes. Applying one of the two visualization techniques presented in the previous chapter, such clusters of couplings can be detected. And having the hierarchical structure attached at the sides of the visualization, it can also be checked whether these clusters conform to a module. While this is feasible for single clusters and modules, it is, however, hard to judge whether a particular concept of coupling conforms to the modularization in general. It would be interesting to find which concept provides the highest similarity to the modularization in existing software projects. Empirical methods need to be applied to analyze this congruence between couplings and modularity in closer detail. On the one hand, such analysis helps understanding how software developers structure their systems—different concepts of coupling can
129
130
5 Empirically Analyzing the Congruence
be connected with different modularity principles. On the other hand, it prepares the ground for applications, such as software clustering, making statements on the modularity of a software system. First, objectives for an empirical analysis are derived (Section 5.1). Then, popular principles for modularizing software systems are introduced and their connection to different concepts of coupling are discussed (Section 5.2). A metric for measuring the congruence between code couplings and modularity is designed (Section 5.3). This metric is used to analyze 16 open source software systems in a threefold empirical study (Section 5.4): first, the independence of the concepts of coupling is investigated (Section 5.4.1), second, the congruence is measured for different concepts of coupling on system level (Section 5.4.2), and third, the analysis is repeated on module level with respect to different types of modules (Section 5.4.3). Finally, related studies are reported and the results are discussed in a broader context (Section 5.5).
5.1 Objectives Empirically comparing the multiple concepts of coupling with respect to modularity involves several tasks. But the first question that needs to be answered before conducting further analyses is: are the concepts of coupling independent of each other? If the concepts interact too much, they measure similar things and hence cannot be considered as individual concepts. Contrasting non-independent concepts as if they were independent could lead to misinterpretation and flawed conclusions. Hence, the first objective is to investigate those interactions.
Objective 5.1: Find if the different concepts of coupling are independent of each other.
For those concepts that are sufficiently independent, the central step is exploring their relation to the modularizations of the studied systems. The goal is to find whether the particular couplings of a concept connect entities within single modules (congruent couplings) or across different modules (non-congruent couplings). The hypothesis is that most concepts are congruent to the modularization at least to some extent, but it need to be checked whether there are exceptions. Moreover, it is desirable to quantify the congruence in comparison between the different concepts.
Objective 5.2: Quantify the congruence of the concepts of coupling to the modularization.
5.2 Modularity Principles
131
Software systems include certain generic types of modules, for instance, utility or io modules. Since these modules have a specific purpose, they might share common characteristics across different systems, which might be reflected in the structure of the couplings. Hence, a further objective is to investigate those generic types of modules with respect to specific patterns of congruence. Objective 5.3: Analyze differences in the impact of congruence with respect to different types of modules. These objectives analyze the relationship between multi-dimensional couplings and the modularization of a software system. Findings are directly applicable to scenarios where a high congruence between couplings and modularization is of central importance such as it is the case for software clustering. But beyond that, the findings might also tell something on strategies the developers applied for modularizing their systems—different modularity principles may relate to different concepts of coupling.
5.2 Modularity Principles The idea of making complex systems manageable by modularization is inevitably connected to developing software systems: the idea is reflected in the design of programming languages, which usually provide mechanisms for modularizations. Moreover, the specifications of software architectures document modularizations and embed them into a broader context. But these are only the technical means to specify and work with modularizations; the task of modularizing a system is done by the developers. A set of modularity principles exists that provides developers with guidelines for creating modularizations. Most of these principles—motivated by theories or observations on developing software systems—were proposed in the sixties and seventies of the previous century. This section presents existing modularity principles in detail and discusses conjectured relationships between the principles and different concepts of coupling. Where possible, the principles are expressed as direct quotes from the original source—terms in quotes are sometimes used slightly deviating from the nomenclature used in this work. Conjectured relationships and their underlying rationale are summarized in Table 5.1.
5.2.1 Low Coupling and High Cohesion Under the title of structured design, Stevens, Myers, and Constantine proposed an intuitive modularity principle in 1974 [247]: the entities of different modules should
132
5 Empirically Analyzing the Congruence
Table 5.1: Summary of conjectured relationships between modularity principles and concepts of coupling. Modularity Principle
Concepts of Coupling
Rationale
low coupling and high cohesion
SD.Inh, SD.Agg, SD.Use
directly addressing direct structural dependencies
information hiding
FO.InhI, FO.AggI, FO.UseI
depending on the same design decision (hidden in other code entities)
EC.Sup, EC.Conf
locality of co-changes; past changes predict future changes
Conway’s law
CO.Bin, CO.Prop
organization structure similar to product (modularization) ⇒ ownership locality
domain knowledge
SS.Tfidf, SS.LSI
domain-related terms are reflected in the vocabulary
separation of concerns
FO.InhE, FO.AggE, FO.UseE
usage of the same functionality
[not classified]
CC.I, CC.II
mutiple aspects
only be loosely coupled while the entities within the same modules should be highly cohesive. This idea is usually referred to as the principle of low coupling and high cohesion. Quoting the original source, the principle can be expressed as follows.
Principle 1 (Low Coupling and High Cohesion): “[. . . ] minimizing the relationships among modules and maximizing relationships among elements in the same module.” [247]
Impact As it is reflected in many software metrics, low coupling and high cohesion is an accepted attribute of quality for modules. A well-known and frequently referenced example is the metric suite by Chidamber and Kemerer [69]. They define the coupling between object classes metric which follows the idea of low coupling: “In order to improve modularity [. . . ], inter-object class couples should be kept to a minimum” [69]. Moreover, they introduce the lack of cohesion in methods reflecting that “Cohesiveness of methods within a class is desirable, since it promotes encapsulation” [69]. Also software clustering approaches are based on the principle, among those the algorithm of Bunch [177, 193], which is applied in the feasibility study (Chapter 2). In particular, the hill-climbing approach of Bunch optimizes an objective function capturing the principle. Other approaches applying the principle are, for instance,
5.2 Modularity Principles
133
the Rigi tool by M¨ uller et al. [199] or a component extraction process proposed by Lee et al. [166]. Conjecture When discussing coupling and cohesion of modules, usually structural dependencies are investigated as the connections between modules. This conforms to the initial definition for structured design by Stevens et al. [247]: “A connection is a reference to some label or address defined [. . . ] elsewhere.” Analyzing structural dependencies from an object-oriented point of view, there exist, however, several type of such structural dependencies such as inheritance (SD.Inh), aggregation (SD.Agg), and usage dependencies (SD.Use) like introduced in Section 3.3.2. Since object orientation was postulated after structured design, it is not clear, how these different subconcepts are to be considered applying the principle. Hence, all three types are potentially related to the principle, but are investigated separately in the following.
5.2.2 Information Hiding In 1972, Parnas [207, 208] introduced the well-known concept of information hiding—hiding design decisions in modules; slim interfaces should represent the facade of the module. When working for Philips Computer Industry, Parnas felt that something in designing software system was going wrong [209]. The key situation was that two colleagues were exchanging detail information on their modules, which later on actually led to a bug. In a systematic case study [208], Parnas observed that systems modularized by their features are often hard to maintain and proposed an alternative modularization strategy: Principle 2 (Information Hiding): “Every module [. . . ] is characterized by its knowledge of a design decision which it hides from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings.” [208]
Impact As information hiding became one of the main foundations of object orientation, the principle is considered to have a high impact. The idea of hiding design decisions is particularly important for designing classes [191]. Information hiding also influenced designing software architectures [16] and aspect-oriented programming [255]. But although information hiding had become a well-established principle, Parnas criticizes in his 2002 retrospect [209] that still information hiding often is not satisfactorily applied in practice; he names several reasons, among them, low educational standards, difficulties in planning for change, and inadequate documentation.
134
5 Empirically Analyzing the Congruence
Conjecture Following the rationale of Schwanke [236], relying on another module means relying on the design decision that is reflected in that module. Hence, two code entities that depend on the same other code entity also depend on the same design decision and, according to the principle of information hiding, should be placed into the same module. Since external libraries neither represent design decisions of the project itself nor are likely to be changed, this rationale applies only to structural dependencies to internal code entities. Similar internal dependencies are represented by the internal structural fan-out couplings (FO.InhI, FO.AggI, and FO.UseI ; Section 3.3.2). As a second indicator, also evolutionary couplings can be considered as being connected to information hiding: hiding design decisions into a module is supposed to foster that most future adaption leads to co-changes only within the module, not across module borders [208]. These co-changes are reflected in evolutionary couplings (EC.Sup and EC.Conf ; Section 3.3.3). Although these changes refer to past modifications, they can also predict future changes to some extent [303].
5.2.3 Conway’s Law Studying the organizational structures of teams, Conway [74] observed that the communication structure of the team is often reflected in the system the team is designing: Like the system falls into subsystems, the team is organized in subteams; instead of interfaces, coordinators control the communication between the subteams. Now, subsystems can be matched to the subteams that designed them; as well, communication through interface can be mapped to communication through coordinators. Since the communication structure of a team is roughly restricted to its general organization, this structure impacts the design of the system. Conway concludes:
Principle 3 (Conway’s Law): “[. . . ] organizations which design systems [. . . ] are constrained to produce designs which are copies of the communication structures of these organizations.” [74]
Impact Conway’s law applies to general engineering processes and as such is also applicable to software engineering: Bowman and Holt [47] extract the architecture of software systems based on code ownership and confirm significant overlap to the actual architecture. Herbsleb and Grinter [135] argue that Conway’s law has a particular impact for software projects that are distributed across several sites because of communication obstacles. Moreover, Kwan et al. [159] propose a taskbased perspective on Conway’s law applied to software engineering: instead of the
5.2 Modularity Principles
135
architecture, it could also be the development tasks that match the organization structure. Conjecture Similarly as conceptualized by Bowman and Holt [47], Conway’s law can be connected to coupling based code ownership (CO.Bin and CO.Prop; Section 3.3.3): If the law applies, it is to assume that code developed by the same developers is placed in the same or similar modules—these developers work together on the same code and probably communicate with each other. The borderline case that the respective code was created by a single developer can be considered as perfect communication.
5.2.4 Further Principles and Guidelines Apart from these principles discussed in detail, there exist other principles not as well-established or well-defined; a selection is presented in the following. While the first two of the principles (domain knowledge and separation of concerns) can also be mapped to concepts of coupling (Table 5.1), the others are difficult to relate to coupling or reach beyond the scope of this study. Domain Knowledge Knowledge on the application domain is an important foundation for designing a software system. For instance, Meyer [191] describes it as one of the key strategies for an object-oriented design: “The modular structure devised in the process of building a software system should remain compatible with any modular structure devised in the process of modeling the problem domain.” Though domain knowledge is not directly represented in the code of a system, it is to assume that the identifiers and comments still contain some trace of this knowledge. Hence, code entities that are semantically similar judged on this vocabulary (SS.Tfidf and SS.LSI ; Section 3.3.4) are likely to reflect similar domain knowledge; to be compatible with the modular structure, they need to be assigned to the same or similar modules. Separation of Concerns Another principle that is repeatedly mentioned in the context of modularity is the separation of concerns. The term is connected to aspect-oriented programming where, in one of the central works, Tarr et al. [255] worked with the term for describing the problem of the multi-dimensional separation of concerns and the tyranny of the dominant decomposition. Concerns that cross-cut the modularization of a system can be encapsulated and separated in so-called aspects. Examples for usually cross-cutting concerns are logging and exception handling. In general, a concern can
136
5 Empirically Analyzing the Congruence
be considered as a certain high-level feature or functionality of the software. When a set of code entities uses the same external functionality, the contained entities are likely to implement similar functionality and might be covered by the same concerns. This idea ties external structural fan-out similarity (FO.InhE, FO.AggE, and FO.UseE ; Section 3.3.2) to the separation of concerns: code entities that are similar with respect to these concepts should be placed in the same module to separate the concerns. Martin’s Principles on Package Design In his work on agile software development [182], Martin proposes six principles on package design for object-oriented systems. Related to the principle of low coupling and high cohesion (Principle 1), he divides the set of principles into three cohesion principles and three coupling principles: The cohesion principles postulate that code reused together is also to be released together and vice versa (reuserelease equivalence principle), that the elements of a packages should also be reused together (common-reuse principle), and that changes to a package should not affect other packages (common-closure principle). And as coupling principles, he requests that there should not be any cyclic dependencies among packages (acyclicdependencies principle), that packages should only depend on more stable packages (stable-dependencies principle), and that abstract packages should also be stable and vice versa (stable-abstractions principle). These principles mainly summarize previously existing guidelines and paradigms and tailor them for object-oriented software. Since they collect a mixture of concepts covering the development process (e.g., reuse) as well as specific characteristics of the code (e.g., abstraction), it is in general hard to relate them to specific concepts of code coupling. Architectural Constraints Also a specific architecture of a system can impose specific requirements on the modularization. For instance, in a layered architecture, modules have to be precisely assigned to one of the layers and structural dependencies should only point into a specific direction with respect to these layers. Other examples are pipesand-filters or client-server architectures, which impose other individual constraints. These restrictions influence the modularization, but cannot be considered as general modularity principles because they are project-specific.
5.2.5 Conjectured Relationships The above discussion shows that modularity principles are closely connected to code couplings. While it is easy to connect some of the principles to particular
5.3 Coupling-Modularity Congruence
137
concepts of coupling, it is harder for others. Problems are the ambiguous usage or imprecise definition of the principles and their age (most discussed principles were introduced before the advent of object orientation). Hence, the relationships between modularity principles and concepts of code coupling can only be considered as working hypotheses or conjectures. Interpreting the results of the following study with respect to modularity principles is promising, but requires certain caution. Comparing the list of introduced concepts of coupling in Section 3.3 to the mappings of modularity principles in Table 5.1, only couplings based on code clones have not been directly linked to one of the principles. Although code clones can just be regarded as bad smells, they are often introduced deliberately and well-considered, for instance, for performance improvements, forking of code, or reducing structural dependencies [228]. Hence, they could serve different purposes and might replace or stand in for other kinds of couplings. This diversity makes it hard to classify those couplings based on code clones with respect to modularity principles. As a consequence, no particular conjecture is applied for code clone couplings.
5.3 Coupling-Modularity Congruence Although the conjectured relationships are diverse and are founded on diverse rationale, they share a specific characteristic: assumed that the relationships are correct, the particular modularity principle is met if the code couplings of the respective concept are largely local with respect to the modularity. Local, in this context, means that the couplings mainly connect code entities contained in the same or similar modules instead of entities from very different modules. The coupling-modularity congruence, which is introduced in the following, denotes the measure for empirically investigating this locality. This measure of congruence is intended to quantify the conformance of the respective coupling structure to the modularization, hence, compares a graph structure to a hierarchy.
Example 5.1: To illustrate what the congruence metric is intended to model, Figure 5.1 provides a small example: Five code entities are distributed across two modules. The couplings in the scenario on the left are quite congruent to the structure of the two modules because most couplings are local and do not cross module borders (intra-module couplings), in contrast to the scenario on the right, where most couplings cross borders (inter-module couplings). Couplings are congruent to the modularization if the ratio of intra-module couplings versus inter-module couplings is high.
138
5 Empirically Analyzing the Congruence
mroot mA
mroot mB
mA
a
c
mB a
intra-module coupling
c
inter-module coupling
b
d congruent
e
b
d
e
non-congruent
Figure 5.1: Illustrating example showing a congruent and non-congruent scenario between couplings and modularization.
5.3.1 Module Cohesion and Coupling Modularizations of software systems are usually hierarchical. Dividing code couplings into intra- and inter-module couplings, however, ignores the hierarchical structure because classifying code couplings as inter-module couplings does not consider what distance the modules have in the hierarchy. A more elaborate approach, which is presented in the following, is considering each coupling as contributing to the cohesion of all modules (for which it is an intra-module coupling) and contributing to the coupling of all pairs of modules (for which it is an inter-module coupling). For example, in Figure 5.1, inter-module couplings between the two modules mA and mB concurrently are intra-module couplings for the parent module mroot and should add to the cohesion of mroot . For splitting the impact of a code coupling into module cohesion and module coupling, hence, the distance that the coupling spans in the hierarchy is an important parameter. For a code coupling e = (v1 , v2 , ω), the idea is to count the number of intermediate modules on the shortest path through the hierarchy from source v1 to target v2 . This value can be derived by retrieving all modules that include either the source or the target as direct or indirect elements—the number of these modules plus one is the required value. Please recall that V (m) denotes the set of entities directly and indirectly contained in a module m (Definition 3.7). ˆ = (V, EV , MV ) be a Definition 5.1 (Coupling Distance): Let G modularized coupling graph (Definition 3.9), then, for a coupling e = (v1 , v2 , ω) ∈ EV (Definition 3.3), the coupling distance is distGˆ (e) = |{m : v1 ∈ V (m) XOR v2 ∈ V (m)}| + 1 where MV = (mroot , V ) denotes the modularization (Definition 3.8) and modules m are (direct or indirect) submodules of mroot .
5.3 Coupling-Modularity Congruence
139
ˆ 1 shown in Figure 5.1 Example 5.2: In the modularized coupling graph G (congruent), distGˆ 1 (eab ) = 1 for a coupling eab = (a, b, ω) connecting the code entities a and b, which are included in the same module A. The distance is larger for a coupling connecting entities of different modules, e.g., distGˆ 1 (ead ) = 3 where ead = (a, d, ω) (the shortest path through the hierarchy consists of three modules: mA , mroot , and mB , or in other words, the entity is exclusively contained each in mA and mB ). The weight ω does not influence the distance.
The higher the distance, the less a code coupling should contribute to the overall module cohesion and the more to the overall module coupling. Moreover, code couplings with a higher weight are to have a higher impact. Based on these two considerations, the module cohesion and coupling can be defined for a single code coupling so that the sum of the two is equal to the weight of the coupling. Furthermore, the definition is extended from single code couplings to the module cohesion and coupling of sets of code entities.
Definition 5.2 (Module Cohesion and Coupling): ˆ = (V, EV , MV ) be a modularized coupling graph (Definition 3.9), Let G then the module cohesion and coupling for a single code coupling e = (v1 , v2 , ω) ∈ EV is provided by mcohGˆ (e) =
ω distGˆ (e)
mcoupGˆ (e) = ω − mcohGˆ (e) if v1 6= v2 ; otherwise, mcohGˆ (e) = mcoupGˆ (e) = 0. Let furthermore ∅ = 6 V 0 ⊆ V be a set of code entities (Definition 3.2), then the definitions of the two functions are extended as follows: X X mcohGˆ (V 0 ) = mcohGˆ (e) + mcohGˆ (e) e∈out(V 0 )
mcoupGˆ (V 0 ) =
X e∈out(V
e∈in(V 0 )
mcoupGˆ (e) + 0)
X e∈in(V
mcoupGˆ (e) 0)
where out(V 0 ) = {(v, v 0 , ω) ∈ EV : v ∈ V 0 } is the set of outgoing couplings and in(V 0 ) = {(v 0 , v, ω) ∈ EV : v ∈ V 0 } is the set of incoming couplings for code entities contained in V 0 .
140
5 Empirically Analyzing the Congruence
In order to ignore self-couplings (v1 = v2 ), their module cohesion and coupling is set to 0. The extension of the metrics from single code couplings to arbitrary subsets of code entities just takes those code couplings into account relevant for the code entities in the set. This set of code couplings consists of those starting or ending in the set of code couplings—code couplings connecting code entities that start and end in the set of selected code entities are considered twice. Applying the two metrics to all code entities of the graph V , the sum of the two metric values mcohGˆ (V ) + mcoupGˆ (V ) is always twice the sum of the weights of all code couplings contained in the graph (self-edges are not considered). ˆ 1 shown in Example 5.3: In the first modularized coupling graph G Figure 5.1 (congruent), module cohesion and module coupling are evaluated as follows for the set of entities Vab = V (mA ) = {a, b} contained in module mA : mcohGˆ 1 (Vab ) = 73 [= (1 + 31 ) + 1] mcoupGˆ 1 (Vab ) =
2 3
[= (0 + 32 ) + 0]
ˆ 2 shown in Figure 5.1 And in the second modularized coupling graph G (non-congruent), analogous module cohesion and module coupling can be computed: mcohGˆ 2 (Vab )
=
mcoupGˆ 2 (Vab ) =
4 3 8 3
[= [=
1 3 2 3
+ ( 13 + 13 + 13 )] + ( 23 + 23 + 23 )]
Please note that in the congruent example the module cohesion is higher than module coupling while the non-congruent example shows an inverse relationship.
5.3.2 Congruence Metric Based on module cohesion and coupling, the congruence between the coupling structure and the modularity of the system can be defined. While a high overall module cohesion indicates a high congruence, a high module coupling hints at a lower congruence. This can be expressed by dividing the module cohesion by the sum of module cohesion and coupling—resulting values are between 0 and 1. ˆ = Definition 5.3 (Coupling-Modularity Congruence): Let G (V, EV , MV ) be a modularized coupling graph (Definition 3.9) with |V | > 1
5.3 Coupling-Modularity Congruence
141
(non-trivial), then the coupling-modularity congruence for a set of code entities ∅ = 6 V 0 ⊆ V is congGˆ (V 0 ) =
mcohGˆ (V 0 ) mcohGˆ (V 0 ) + mcoupGˆ (V 0 )
if
mcohGˆ (V 0 )+mcoupGˆ (V 0 ) > 0 .
ˆ c = (V, V × V × {1}, MV ) Otherwise, congGˆ (V 0 ) = congGˆ c (V 0 ) where G ˆ denotes a complete graph with the same modularization MV as G.
Discerning the two cases is necessary because, when there does not exist any incoming or outgoing code couplings for any code entities v ∈ V 0 , the denominator is 0. In this case, the congruence metric is supposed to provide a baseline value—this value, however, is not 0, but higher because even couplings crossing the complete modularization contribute somewhat to the module cohesion. To derive a better baseline, the congruence is instead computed on a complete graph—every code entity is connected with every other code entity. In such graph, the couplings are independent of the modularization. The recursive definition congGˆ (V 0 ) = congGˆ c (V 0 ) is valid because in every case mcohGˆ c (V 0 ) + mcoupGˆ c (V 0 ) > 0 ˆ c is a complete graph and |V | > 1. as G Though the congruence metric is defined on arbitrary set of code entities V 0 ⊆ V , it is intended to be usually applied to the complete system V or at least to the code entities of a module V (m). In such application, the metric measures the congruence between the coupling graph and the complete modularization or a particular module of the modularization.
ˆ 1 (conExample 5.4: Applied to the two modularized coupling graphs G ˆ 2 (non-congruent) from Figure 5.1, the coupling-modularity gruent) and G congruence for the set of entities Vab = V (mA ) = {a, b} is: h i 7 7 3 congGˆ 1 (Vab ) = 9 = 7+2 3 3 h i 4 1 3 congGˆ 2 (Vab ) = 3 = 4+8 3
3
Hence, as intuitive and intended, the congruence of module mA is much ˆ 1 than for G ˆ 2. higher for G
142
5 Empirically Analyzing the Congruence
The congruence metric investigates whether the existing code couplings conform to the modular structure regardless of how many code couplings exist. This is a desired characteristic because the metric should be independent of the density of couplings. However, it would be also of interest to see whether there is enough information so that each code entity can be clearly connected to a particular module. This can be addressed by computing the congruence for a single code entity—all outgoing and incoming code couplings are considered. The average summarizes the individual, entity-specific congruence values as follows: Definition 5.4 (Average Coupling-Modularity Congruence): Let ˆ = (V, EV , MV ) be a modularized coupling graph (Definition 3.9) with G |V | > 1 (non-trivial), then the average coupling-modularity congruence for a set of code entities ∅ = 6 V 0 ⊆ V is 0 congavg ˆ (V ) = G
1 X congGˆ ({v}) . |V 0 | v∈V 0
If the coupling graph is only sparse, the does not exist any coupling information for many code entities. In such cases, the baseline congruence is taken into account as it is specified in Definition 5.3. Hence, for a graph without any couplings, the baseline values are averaged, which is a desired outcome. Every further coupling information roughly congruent to the modularization would increase the average congruence, but a single congruent coupling could not change the average congruence significantly. Example 5.5: Analogous to the previous example, the average couplingmodularity congruence can be evaluated for the set of entities Vab = ˆ 1 (congruent) V (mA ) = {a, b} in the two modularized coupling graphs G ˆ 2 (non-congruent) from Figure 5.1: and G h 4 i 1 1 5 3 = + congavg (V ) = 4 ab ˆ1 6 2 1+0 + 23 G 3 h 2 i 2 1 1 3 3 congavg (V ) = = + 2 2 ab ˆ 4 2 +6 +6 G 2
3
3
3
3
Again, as intuitive and intended, the average congruence of module mA is ˆ 1 than for G ˆ 2. much higher for G
Finally, the two congruence metrics provide the means for analyzing how a concepts of coupling conforms to the whole modularization or a particular module (Definition 5.3) and how the code entities are covered by this congruence (Definition 5.4).
5.3 Coupling-Modularity Congruence
143
But although the metrics are normalized, one has to beware of comparing metric values across different software projects: through the different modularizations of the systems, cohesion and coupling are weighted differently. As a consequence, the baseline values are project-specific. Hence, direct comparisons of congruence values between projects are not valid. Nevertheless, it is possible to contrast congruence values of different concepts of coupling to each other. And relative congruence patterns resulting from comparisons like those provide a way to indirectly compare different projects or different sets of code entities.
5.3.3 Related Metrics Studying software metrics is a large subfield of software engineering research—plenty of metrics have been proposed and applied to assess the quality of software systems. Among those, many consider code couplings as a data source and try to minimize modules coupling, maximize module cohesion, or capture both concepts at the same time. Briand et al. [54] survey and contrast coupling metrics and present a unified framework for coupling measurement. These metrics measure module coupling on different level of abstraction considering different aspects of coupling. For instance, interpreting a class as a module, coupling between object classes [69] counts the number of other classes to which a class is coupled, message passing coupling [169] quantifies method invocations to other classes, or data abstraction coupling [169] looks at the number of abstract data types used in the class. On a higher level of abstraction, Martin [182] discerns afferent and efferent coupling, the first denoting “the number of classes outside this package that depend on classes within this package”, the latter “the number of classes inside this package that depend on classes outside this package”. Gupta and Chhabra [123] propose an approach called package coupling measurement where they count the number of direct couplings between elements of packages. Analogous to the framework for coupling measurement, Briand et al. [53] also introduce a framework for cohesion measurement. For instance, among the surveyed metrics, the metric lack of cohesion in methods [69] is based on how many pairs of methods of a class do not access common instance variables—several variants of the original metric exist. While the above metrics either consider coupling or cohesion, there exist some modularity metrics that consider both. Similar to the coupling-modularity congruence (Definition 5.3 and 5.4), many metrics implement the basic idea of putting the number of intra-module dependencies in relation to the number of inter-module dependencies, for instance, the clustering factor employed in Bunch [177, 193], the score of a cluster used for the EVM metric [127], or the intra-modular coupling density as a part of the modularization merit factor [4]. Also related is the general network metric degree of modularity [298], which compares intra-module couplings to inter-module couplings as a difference and can be applied to software systems.
144
5 Empirically Analyzing the Congruence
Table 5.2: Properties of the sample of software projects and their repositories (#Pa: number of packages; #V: number of classes and interfaces; Rep: repository type; #Tr: number of transactions; #Dev: number of developers). Project
Description
Version
#Pa
#V
Rep
Time frame
#Tr
#Dev
Checkstyle Cobertura
coding conventions
5.1
21
261
SVN
2001-06-22 – 2010-02-16
1,335
6
test coverage
1.9.4.1
19
99
SVN
2005-02-12 – 2010-03-03
226
CruiseControl
6
continuous integration
2.8.4
27
295
SVN
2001-03-26 – 2010-09-16
1,615
10
iText
PDF library
5.0.5
24
402
SVN
2007-12-20 – 2010-11-02
817
7
JabRef
BibTeX management
2.6
37
499
SVN
2003-10-16 – 2010-04-14
1,348
23 23
JEdit
text editor
4.3.2
28
488
SVN
2001-09-03 – 2010-05-09
2,927
JFreeChart
chart library
1.0.13
37
587
SVN
2007-06-19 – 2009-04-20
551
2
JFtp
FTP client
1.0
7
78
CVS
2002-02-06 – 2003-03-23
155
5
JHotDraw
GUI framework
7.6
65
679
SVN
2006-11-22 – 2011-01-09
302
2
JUnit
regression testing
4.5
23
119
CVS
2007-12-07 – 2008-08-08
126
2
LWJGL
gaming library
2.7.1
27
564
SVN
2002-08-09 – 2011-02-10
1,557
11
PMD
code problems
4.2
47
565
SVN
2002-06-24 – 2008-03-26
2,041
18
Stripes
web framework
1.5.5
19
238
SVN
2005-09-07 – 2011-01-04
812
7
SweetHome3D
interior design
3.1
8
167
CVS
2006-04-11 – 2011-02-13
1,807
1
TV-Browser
program guide
2.7.6
62
485
SVN
2003-04-25 – 2010-12-19
4,602
12
Wicket
web framework
1.2.2
86
622
SVN
2004-12-21 – 2006-08-27
3,456
12
Although those modularity metrics target a similar scenario than the proposed congruence metrics, they do not consider the modularization of the system as a hierarchical structure. Elaborating on this issue, the coupling distance (Definition 5.1) is an elementary building block in the definition of the two congruence metrics used in this study.
5.4 Study The conducted empirical study applies the proposed congruence metrics (Definition 5.3 and 5.4) to a set of open source software systems. Since the congruence metrics are generic and not restricted to a certain concept of coupling, multiple concepts can be analyzed and compared. The study is organized in three stages, each implementing one of the objectives discussed in Section 5.1: First, the independence of the concepts needs to be checked (Objective 5.1). Then, the congruence is analyzed on system-level comparing different concepts of coupling (Objective 5.2). Finally, characteristics specific to different types of modules are investigated (Objective 5.3). The 16 open source software projects listed in Table 5.2 are examined. They cover a broad spectrum of different application types—development tools, programming libraries, text and graphics editors, etc. The main programming language of these
5.4 Study
145
Table 5.3: Overview of concepts of coupling considered in the study (compare to Section 3.3). Group
Subgroup
Concepts of Coupling
Data Source
structure
structural dependencies
SD.Inh, SD.Agg, SD.Use
bytecode
fan-out (external)
FO.InhE, FO.AggE, FO.UseE
fan-out (internal)
FO.InhI, FO.AggI, FO.UseI
evolutionary coupling
EC.Sup, EC.Conf
code ownership
CO.Bin, CO.Prop
code clones
CC.I, CC.II
semantic similarity
SS.Tfidf, SS.LSI
history semantics
repository code
systems is Java (only the Java code is analyzed); all systems are hosted at sourceforge.net. They are small- to mid-size projects consisting of 7 to 86 packages (#Pa) or 78 to 679 classes and interfaces (#V ). The code is stored either in CVS or SVN repositories (Rep) and covers development spans of 10 months to 9 years or 126 to 4602 relevant transactions (#Tr )—transaction that did not involve changing relevant Java code are not considered. The number of developers varies from 1 to 23 (#Dev ). The study covers all concepts of coupling introduced in greater detail in Section 3.3; Table 5.3 recalls and structures the 17 concepts: The first group of concepts refers to the structure of the code and covers direct structural dependencies as well as indirect couplings relating code entities having a similar fan-out, external (to libraries) or internal (to other code entities). This structural information is retrieved from the bytecode of the program (jar files). History-related concepts of coupling, namely evolutionary couplings and code ownership, form the second group of concepts. They are mined from the source code repositories analyzing all check-in transactions. Finally, semantic concepts such as semantic similarity and code clones are generated from the source code of the systems: while type I and type II clones are employed for computing code clone couplings, semantic similarity analyzes and compares the vocabulary used in the identifiers and comments of the code entities.
5.4.1 Independence of Concepts To cover Objective 5.1, it needs to be checked how the different concepts of coupling relate to each other. In terms of statistics, a relationship like this can be expressed as a correlation of two vectors (i.e., variables). However, the concepts are not described as such vectors but as edges of a coupling graph—how these can be transformed into vectors is described in the following.
146
5 Empirically Analyzing the Congruence
a
a a 0 b 0 c 0
b 1 0 1
c 1 0 0
a a 0 b 0 c 1
b 0 0 1
c 0 0 0
1
b
c
coupling graphs
2
adjacency matrices
0 1 1 0 0 0 0 1 0
0 0 0 0 0 0 1 1 0
coupling vectors
3
p1
p1
sampling
sampled vectors
4
p0
p0
p1
p1
p2
p2
stacked vectors
5
0.29
Pearson corellation
Figure 5.2: Computing correlations between concepts of code coupling by transforming coupling graphs into vectors and sampling them across multiple projects.
Method A multi-dimensional coupling graph (Definition 3.6) usually includes several concept of coupling, which each consists of a set of weighted edges (Definition 3.4). The following transformations describe how to compute a correlation between two concepts of coupling across multiple software projects. Figure 5.2 depicts a graph containing two concepts of coupling on the left side and illustrates the transformation process into a correlation value from left to right. 1. An alternative to considering a concept of coupling as a set of weighted edges is to represent it in an adjacency matrix. In such a matrix, each cell value represents the weight of the respective coupling; if no such coupling exists, the value is 0. Two concepts produce two different matrices. 2. For n code entities, each matrix contains n2 values. Linearizing these matrices leads to two vectors, each consisting of n2 dimensions. It is required to apply the exact same linearization order to both matrices to get comparable vectors. 3. To get equally sized vectors for all studied software projects the vectors need to be sampled. A random sampling with repetition of 20,000 values is applied. Again it is crucial to apply the exact same sampling to both vectors. 4. For each concept of coupling, all projects can be merged into a single vector by concatenating the project-specific vectors. 5. The two vectors representing the two concepts of coupling for all project can be correlated. To detect linear relationships, the Pearson correlation coefficient is used: a value of 1 indicates a perfect positive linear relationship, 0 indicates independent measures, and -1 indicates a perfect negative linear relationship.
5.4 Study
147
This procedure is applied to all pairs of concepts of coupling and produces each a single correlation value summarizing all studied software systems. The fixed size of the vector warrants that larger projects do not dominate the smaller ones.
Results The results of the correlation analysis are presented as a matrix in Figure 5.3. The matrix includes all pairwise comparison of concepts; labeled cells on the diagonal identify the concepts. Since the Pearson correlation is symmetric, the matrix is symmetric as well with respect to the diagonal. To provide a better overview, whiteto-blue color coding redundantly encodes the correlation values: white representing values around 0, blue larger positive values. Considerable negative values do not appear. As a first result analyzing the correlation coefficient presented in Figure 5.3, it becomes apparent that there are only a few strong relationships between the concepts. Only variants of the same concept produce values above 0.33. Most closely related are the two code ownership concepts (CO.Bin and CO.Prop: 0.93), followed by the semantic similarity concepts (SS.Tfidf and SS.LSI : 0.83), and the code clone concepts (CC.I and CC.II : 0.82). Since the definitions of the two concepts of each pair only differ slightly, this is not a surprising result. For each pair, the two concepts of coupling are to be considered as instances of the same underlying concept rather than independent concepts. Perhaps somewhat more surprising is that such strong relationships cannot be found for all instances of the same underlying concepts: While the evolutionary concepts of coupling still are considerably related (EC.Sup and EC.Conf : 0.42), the triples representing variants of structural dependencies and fan-out coupling (external and internal) are not as closely related. Among the three variants—inheritance, aggregation, and usage—aggregation and usage at least seem to be somewhat connected (SD.Agg and SD.Use: 0.31; FO.AggE and FO.UseE : 0.30; FO.AggI and FO.UseI : 0.23). In contrast, inheritance is less correlated (structural dependencies: ≤ 0.012; external fan-out: ≤ 0.064) except for internal fan-out (0.13 and 0.30). Moreover, there is no considerable correlation between structural dependencies and fan-out coupling (≤ 0.058) and only weak correlations between external and internal fanout coupling (≤ 0.17). Hence, all defined concepts based on structural information are rather to be considered as independent concepts than slightly differing instances of the same underlying idea. In particular, inheritance is independent of aggregation and usage. Off the diagonal formed by variants of the same concepts, the correlation matrix only provides weaker correlations (≤ 0.33), which indicates that the concepts—if not instances of the same underlying concepts—are independent to a large extent. The
148
5 Empirically Analyzing the Congruence
SD Inh
0.012
0.012
SD Agg 0.31
0.0018
0.015
0.009
SD 0.31 Use
0.00024
0.0014
0.0018
0.00024
FO InhE
0.0041
0.015
0.022
0.015
0.028
0.0045
0.053
0.071
0.022
0.024 0.0048 0.011
0.12
0.094
0.028 0.0007 0.0065 0.011
0.056
0.04
0.022
0.025 0.0019 0.0027 0.052
0.039
0.022
0.013
5.6e−05
0.014
0.043
0.019 0.0066 0.0073 0.0009 0.0007 0.034
0.025
0.044
0.064
0.11
0.073 0.0029 0.052
0.061
0.14 0.14
0.097
0.15 0.17 0.13
0.044
FO AggE 0.30
0.047
0.15
0.059
0.063
0.032
0.15 0.13 0.12
0.013
0.064
FO 0.30 UseE 0.15 0.07 0.17 0.13 0.13 0.10 0.10 0.11 0.18 0.22 0.21
0.0007
5.6e−05
0.11
0.047
FO 0.13 0.30 0.15 InhI
0.085
0.12
0.042
0.044
0.0047
0.0065
0.014
0.073
FO 0.23 0.15 0.07 0.13 AggI
0.064
0.045
0.09
0.077 0.0021 0.032
0.058
0.011
0.017 0.0029 0.092
FO 0.17 0.30 0.23 UseI
0.093
0.084
0.071
0.067
0.053
0.056
0.043
0.052
0.095
0.13
0.085
0.064
0.093
EC Sup 0.42 0.15 0.17
0.015
0.049
0.23 0.19
0.071
0.04
0.019
0.061
0.059
0.13 0.12
0.045
0.084
EC 0.19 0.20 0.42 Conf
0.043
0.068
0.28 0.22
0.022
0.022 0.0066
0.14
0.063
0.10
0.042
0.09
0.071
CO 0.93 0.15 0.19 Bin
0.0097
0.069
0.14 0.13
0.024
0.025 0.0073
0.14
0.057
0.10
0.044
0.077
0.067
CO 0.17 0.20 0.93 Prop
0.0084
0.065
0.15 0.14
0.0048
0.0019
0.097
0.032
0.11 0.18
0.0021
0.17
0.015
0.043 0.0097 0.0084
CC I 0.82 0.32 0.24
0.011 0.0027 0.0007
0.15 0.15 0.18 0.21
0.032
0.19
0.049
0.068
0.069
0.82 CC II 0.33 0.26
0.12
0.052
0.034
SS 0.17 0.13 0.22 0.25 0.13 0.29 0.23 0.28 0.14 0.15 0.32 0.33 Tfidf 0.83
0.094
0.039
0.025
SS 0.13 0.12 0.21 0.24 0.13 0.31 0.19 0.22 0.13 0.14 0.24 0.26 0.83 LSI
0.009 0.0014 0.0041 0.015 0.0045 0.0047 0.058
0.0009
0.017
0.092
0.095
0.057
0.065
0.18 0.21 0.25 0.24 0.13 0.13
0.17 0.19 0.29 0.31
Figure 5.3: Pearson correlations between different concepts of coupling sampled from all studied systems.
5.4 Study
149
still somewhat stronger correlations (0.10–0.33) can be summarized and explained as follows: • Evolutionary couplings are somewhat related to code ownership couplings (EC and CO: 0.15–0.20)—both are based on the history of the code, namely, the change transactions of the developers. • The two concepts of code clone coupling (CC.I, CC.II ) are correlated to some extent with external and internal fan-out, particularly, for the inheritance and usage variants (FO.InhE, FO.UseE, FO.InhI, FO.UseI : 0.097–0.21), less for the aggregation variants (FO.AggE, FO.AggI : ≤ 0.15). Possibly, the inheritance-based correlations are caused by implementing or overriding the same methods in a very similar way. Moreover, usage-based correlations could be effects of code clones required to call the same methods. • Finally, semantic similarity (SS.Tfidf, SS.LSI ) seems to be linked to some degree to most other concepts (0.094–0.33) except direct aggregation and usage dependencies (SD.Agg, SD.Use: ≤ 0.052). Based on the vocabulary used in the code, semantic similarity aggregates parts of other concepts: concrete reasons could be that code entities share a certain vocabulary as their parent code entities due to implementing or overriding methods (SD.Inh–SS.Tfidf : 0.12), code entities having a similar fan-out automatically use a similar vocabulary (FO–SS : 0.12–0.31), code entities coupled by evolution might be changed together because of renaming which implicates common vocabulary (EC –SS : 0.19–0.28), the author is mentioned in the code entity or has a tendency to use particular vocabulary (CO–SS : 0.13–0.15), code clones express a related form of semantic similarity (FO–SS : 0.24–0.33). In conclusion, the general categories of concepts of coupling—structure, history, and semantics—can be considered as independent. Moreover, also the concepts within the categories are largely independent if they are not slight variants of each other (such as CO.Bin and CO.Prop). In particular, inheritance is independent from aggregation and usage at least for direct and external fan-out couplings. Only semantic similarity correlates somewhat with a number of concepts, but is not clearly related to a single other concept—it is probably still sufficiently independent to be regarded as an individual concept.
5.4.2 Coupling-Modularity Congruence In the next step, as central part of the study, the congruence of the different concepts and the modularization of the systems is quantified (Objective 5.2). To this end, the congruence metrics introduced in Section 5.3.2 are computed on each individual sample project for each concept of coupling.
150
5 Empirically Analyzing the Congruence
Method ˆ = (V, EV , MV ) (Definition 3.9), Applied to a specific modularized coupling graph G 0 the coupling-modularity congruence congGˆ (V ) (Definition 5.3) provides a measure to indicate the strength of relationship between the concept of coupling EV (Definition 3.4) and the modularization MV (Definition 3.8) for a specific set of code entities ∅ 6= V 0 ⊆ V . When setting V 0 = V , the metric congGˆ (V ) is computed for the complete project. Analogously, the average coupling-modularity congruence congavg ˆ (V ) (Definition 5.4), additionally reflecting the information density, can be G derived for a specific modularization on project-level. For the study, congGˆ ip (Vp ) as well as congavg ˆ i (Vp ) G p
are computed for each concept of coupling and each project modularized according to its package structure, where Gp = (Vp , (EV1p , EV2p , . . . , EVmp ), MVp ) is a modularized multi-dimensional coupling graph (Definition 3.10) for a project p and ˆ i = (Vp , E i , MVp ) G p Vp the according modularized coupling graphs for each concept (Definition 3.9). This enables the comparison of the congruence of different concepts, but only with respect to the same project—the modularization MV as well as the selected set of code entities have to be the same to warrant a valid comparison. Moreover, a baseline congruence value is computed for each project by applying the two congruence metrics congGˆ c,p (Vp ) as well as congavg ˆ (Vp ) G c,p
ˆ c,p of project p as described in Section 5.3.2. to the respective complete graph G Concepts of coupling producing congruence values clearly above this project-specific baseline can be considered as congruent to the modularization.
Results The results of this experiment are presented in Figure 5.4 as boxplots, one for the coupling-modularity congruence values (top), the other for the average couplingmodularity congruence values (bottom). A boxplot is a diagram to show certain statistical properties of sets of values as simple glyphs (horizontal line: median; box: the two mid-quartiles; dashed line and circles: outliers). Here, each column summarizes the congruence values for a single concept of coupling across the 16 studied software systems. Please note that the project-specific baseline values are
5.4 Study
151
represented separately in the last column. The depicted congruence values are systematically discussed in the following from left to right for both congruence metrics. Structural dependencies (SD) seem to be congruent to the modularizations of the studied system because their coupling-modularity congruence values (Figure 5.4, top) clearly exceed the baseline value, for inheritance (SD.Inh) as well as for aggregation (SD.Agg) and usage (SD.Use). Among the three concepts, inheritance (SD.Inh) provides the highest congruence, nearly topping all other concepts of coupling. Taking into account how these congruence values are distributed across the individual code entities of the systems and switching to the average coupling-modularity congruence (Figure 5.4, bottom), the results are similar: the average congruence values clearly exceed the baseline and inheritance (SD.Inh) performs best among the three. The latter observation is somewhat surprising because direct inheritance dependencies are sparse and do not exist for all code entities: there exist many entities that neither extend nor implement other entities of the system (excluding library elements). Nevertheless, aggregation dependencies (SD.Agg) gain against the others—this data source is denser and thereby counterbalances the somewhat lower general congruence when looking at the average congruence. Analyzing the fan-out similarity, results for external fan-out are clearly to be discerned from those of internal fan-out because the respective congruence values considerably differ: while, for external fan-out, only inheritance-based couplings (FO.InhE ) outperform the baseline values, all internal fan-out concepts of coupling (FO.InhI, FO.AggI, and FO.UseI ) can be considered as congruent to the modularization (Figure 5.4, top); this difference is similar for the average congruence values (Figure 5.4, bottom). A particularly high congruence can be observed for internal inheritance fan-out coupling (FO.InhI )—code entities that are siblings in the inheritance hierarchy seem to be often organized in the same packages. These congruence values are even somewhat higher than those of direct inheritance dependencies (SD.Inh) for congruence and at least among the best for average congruence. In general, the three internal fan-out concepts show similar results than the respective direct structural dependencies. For the two evolutionary concepts of coupling (EC.Sup and EC.Conf ), the congruence values are high, clearly above the baseline; the average congruence values are even among the highest. The difference between the two concepts is only small, but consistently better for evolutionary coupling based on the confidence metric (EC.Conf )—the normalization by the number of total changes of a code entity seems to pay off. Surprisingly, code ownership (CO.Bin and CO.Prop) has no clear relationship to modularity as the two congruence metrics do not considerably exceed the baseline values. The first guess was that the modularizations are too fine-grained to be congruent with the possibly more coarse-grained ownership coupling information.
●
0.2
0.0 FO.UseI
FO.AggI
FO.InhI
FO.UseE
FO.AggE
FO.InhE
SD.Use
SD.Agg
SD.Inh
CO.Bin CO.Prop CC.I CC.II SS.Tfidf SS.LSI baseline
CO.Prop
CC.I
CC.II
SS.Tfidf
SS.LSI
baseline
●
CO.Bin
EC.Conf
0.6 ●
EC.Conf
0.8 EC.Sup
1.0
EC.Sup
FO.UseI
FO.AggI
FO.InhI
FO.UseE
FO.AggE
FO.InhE
SD.Use
0.4
SD.Agg
SD.Inh
average class coupling−modularity congruence
coupling−modularity congruence
152 5 Empirically Analyzing the Congruence
1.0 ●
0.8
0.6
0.4
0.2
0.0
Figure 5.4: Coupling-modularity congruence (top) and average couplingmodularity congruence (bottom) for each concept of code coupling summarized as boxplots across all sample projects.
5.4 Study
153
Evaluating the couplings against a simplified package structures ignoring the lowest level of packages, however, did not reasonably improve the congruence values. In contrast, code clones seem to frequently connect code entities of the same package or similar packages, in particular, type I clones: the congruence for the respective concept of coupling (CC.I ) is relatively high for the congruence and the average congruence. Couplings based on type II clones (CC.II ) are less congruent, nevertheless still exceed the baseline values. The difference between type I and type II becomes smaller for the average congruence (type II clone are more frequent because they form a superset of type I clones), but still type I clones outperform type II clones. Finally, analyzing semantic similarities, certain congruence can be observed—for both congruence metrics, the results exceed the baseline values, but are quite low compared to other concepts of coupling. Comparing the tf-idf couplings (SS.Tfidf ) against the LSI variant (SS.LSI ), the additional effort in preprocessing does not seem to be profitable because the simpler tf-idf variant consistently performs slightly better. An explanation could be that the positive effect of noise reduction is outweighed by the loss of information in the particular setup applied for LSI. To summarize the results, the overall best general congruence values (Figure 5.4, top) are reached by internal inheritance fan-out coupling (FO.InhI ) followed by direct inheritance dependencies (SD.Inh). Considering also the information density (Figure 5.4, bottom), again structural inheritance dependencies (SD.Inh and FO.InhI ) but also evolutionary couplings (EC.Sup and EC.Conf ) provide high congruent results. Abstracting from the individual concepts of coupling, structural dependencies (SD), internal fan-out coupling (FO.*I ), and evolutionary couplings (EC ) are reasonably congruent to the modularizations of the systems. In contrast, not significantly exceeding the baseline, external aggregation and usage fan-out couplings (FO.AggE and FO.UseE ) as well as code ownership couplings (CO.Bin and CO.Prop) cannot be considered as congruent. All other concepts show a mid-level of congruence.
5.4.3 Module Type Congruence The third and last part of the study investigates whether different patterns of congruence can be found in different types of modules (Objective 5.3). To this end, the main packages of the 16 projects are manually classified into different types. Similar to the previous part of the study, the congruence metrics can be applied; but now, the metrics are evaluated on the packages of a certain type instead of the complete project. Contrasting the results for different types of modules might reveal differences in their style of design.
154
5 Empirically Analyzing the Congruence
Table 5.4: Manually detected types of modules (packages) and the number of projects they occur in (at least 20 code entities). Type
Description
#Projects
core
implements the core functionality
data
encapsulates data and manages data structures
4
event
handles temporal events, actions, messages or exceptions
2
graphics
draws 2D or 3D graphics
2
gui
creates and controls the graphical user interface
6
io
reads or writes data from/to a device
text
parses, transforms, or creates textual data
util
provides supporting functionality
11
7 10 6
Method The manual classification of packages was organized as an iterative process consisting of assigning packages to types and adapting those types. This was repeated until most of the main packages (packages at the main level of modularization) of the 16 projects were consistently assigned to a type. Not all of those packages, however, could be unambiguously classified due to lack of domain knowledge; they are excluded from the following analyses. Assigning a package to a particular type, all subpackages were also assigned to the same type. As an outcome of the classification, the packages are grouped into the eight types of modules listed in Table 5.4. Since not all of those types could be identified in every project, the last column of the table lists the number of projects the types occur in (at least 20 code entities belonging to a particular type were required). To increase validity, only types covering at least four projects are considered in the following. For each type of module, the coupling-modularity congruence congGˆ (V 0 ) (Definition 5.3) is applied where V 0 ⊂ V is the set of code entities contained in a package classified as the current type. Again, this is applied to each concept of coupling and each project. Since based on different sets of code entities and hence different modularizations, multiple types of modules should not be compared directly to each other. Nevertheless, it is possible to compare patterns in the congruence values found for different types—the relative congruence values need to be contrasted.
Results Figure 5.5 shows the results as a set of six boxplot diagrams, each representing a particular type of module. Only the six types are listed that at least occur in 4 of the projects (compare to Table 5.4)—the number of projects is again provided
0.2
SD.Inh SD.Agg SD.Use FO.InhE FO.AggE FO.UseE FO.InhI FO.AggI FO.UseI EC.Sup EC.Conf CO.Bin CO.Prop CC.I CC.II SS.Tfidf SS.LSI baseline
0.6
1.0
0.8
0.6
0.4
0.2
0.0
coupling−modularity congruence
0.8 SD.Inh SD.Agg SD.Use FO.InhE FO.AggE FO.UseE FO.InhI FO.AggI FO.UseI EC.Sup EC.Conf CO.Bin CO.Prop CC.I CC.II SS.Tfidf SS.LSI baseline
0.6
0.4
0.2
0.0 coupling−modularity congruence
●
1.0
●
● ●
● ● ● ●
●
0.4 ●
●
0.0 coupling−modularity congruence
SD.Inh SD.Agg SD.Use FO.InhE FO.AggE FO.UseE FO.InhI FO.AggI FO.UseI EC.Sup EC.Conf CO.Bin CO.Prop CC.I CC.II SS.Tfidf SS.LSI baseline
coupling−modularity congruence 0.8
SD.Inh SD.Agg SD.Use FO.InhE FO.AggE FO.UseE FO.InhI FO.AggI FO.UseI EC.Sup EC.Conf CO.Bin CO.Prop CC.I CC.II SS.Tfidf SS.LSI baseline
coupling−modularity congruence 1.0
core (11) 1.0
SD.Inh SD.Agg SD.Use FO.InhE FO.AggE FO.UseE FO.InhI FO.AggI FO.UseI EC.Sup EC.Conf CO.Bin CO.Prop CC.I CC.II SS.Tfidf SS.LSI baseline
SD.Inh SD.Agg SD.Use FO.InhE FO.AggE FO.UseE FO.InhI FO.AggI FO.UseI EC.Sup EC.Conf CO.Bin CO.Prop CC.I CC.II SS.Tfidf SS.LSI baseline
coupling−modularity congruence
5.4 Study
155
text (10) ●
0.8
0.6 ●
●
0.4 ●
0.2
0.0
io (7) gui (6)
1.0 ●
0.8
0.6
0.4 ●
0.2
0.0
util (6) data (4)
1.0
0.8
0.6
0.4
0.2
0.0
Figure 5.5: Coupling-modularity congruence for each concept of coupling discerned by frequently occurring types of modules.
156
5 Empirically Analyzing the Congruence
coupling-modularity congruence (median)
1
package types
SS.LSI
core data gui io text util
baseline
SS.Tfidf
CC.I
CC.II
CO.Bin
CO.Prop
EC.Conf
EC.Sup
FO.UseI
FO.AggI
FO.InhI
FO.UseE
FO.AggE
SD.Use
FO.InhE
SD.Inh
SD.Agg
0
Figure 5.6: Overlay of all congruence medians of the six diagrams in Figure 5.5.
in brackets. As these diagrams show the coupling-modularity congruence, not the average congruence, they form the complements to Figure 5.4 (top). Although, at first glance, the diagrams might look different, a closer inspection shows that the congruence values roughly follow the same patterns and all produce similar results that match the previously described observations: In general, direct structural dependencies (SD) and internal fan-out couplings (FO.*I ) produce high congruence values, particularly, internal inheritance fan-out coupling (FO.InhI ) and direct inheritance dependencies (SD.Inh). Also the mid- and non-congruent concepts are similar across all diagrams. These similar patterns become even clearer when overlaying the median values of each concept of coupling for the different diagrams. The result is presented as a line diagram in Figure 5.6. The absolute congruence values vary somewhat, but only by a small constant; this probably is an effect of the different underlying sets of entities that are considered for the different diagrams. However, the overall pattern is the same for every type of module. Only small difference can be observed between the different types. But since some of the types only occur in a few projects, these differences, as listed in the following, can only be considered as preliminary evidence: • A particularly high congruence can be observed for internal inheritance fanout coupling (FO.InhI ) in the io and gui packages—sibling relations in the inheritance hierarchy might play a special role in these kinds of modules. • The congruence values of the core packages do not exceed the baseline values as clearly than in other types of packages. Maybe another factor not considered by the studied set of concepts might play a more important role for assembling those modules.
5.5 Discussion
157
• Text packages show some reasonably high congruence values with respect to direct structural dependencies (SD), internal fan-out coupling (FO.*I ), and evolutionary coupling (EC ). These modules might be particularly wellmodularized.
5.4.4 Result Summary The empirical study based on 16 open source projects investigated the three initial objectives step by step. By showing that the concepts of coupling are sufficiently independent of each other (except variants of the same underlying concept), it was substantiated that the concepts really cover different aspects of coupling. In the main part of the study, the concepts of coupling showed quite different congruence to the modularizations of the analyzed systems. In general, direct and indirect structural dependencies, evolutionary couplings, and code clone couplings provided high congruence values; the highest values were reaches by fan-out inheritance similarity (FO.InhI ) and direct structural inheritance dependencies (SD.Inh). Finally, no distinguished variance was observed for the congruence patterns of different types of modules.
5.5 Discussion In order to put the results of the performed study into a broader context, limitations, related findings, and possible implications are discussed. Considering the initially conjectured relationships between modularity principles and concepts of code coupling, educated guesses can be made on the usage of these principles in the studied systems. Moreover, the results might have direct implications for designing and generating well-structured modularizations of software systems.
5.5.1 Threats to Validity Different aspects limit the validity of the results. According to the taxonomy of Cook and Campbell [75], the following kinds of validity can be discerned for a systematic review: Conclusion Validity—Is there a relationship between the varied input and the observed outcome? The different concepts of coupling (i.e., the varied input) produced different outcomes with respect to congruence values. By analyzing a reasonable number of software projects, it becomes unlikely that the observed differences are a product of chance. Additional information on the differences is provided by showing boxplots instead of plain bar charts. However, not meeting the requirements of
158
5 Empirically Analyzing the Congruence
a controlled experiment, applying inference statistics to test the statistical significance of the observed differences would have been questionable and thus was not performed. Finally, only clear differences between congruence distributions can be interpreted with reasonable confidence; smaller differences can at most be considered as first indications. Internal Validity—Is the observed relationship causal? The only varied input is the concept of code coupling; the congruence metric is applied to the same projects. Moreover, the analysis of the independence of the concepts in Section 5.4.1 showed that the general categories of concepts are not reasonably confounded. A bias towards a specific concept, however, is possible. For instance, applying a strict package-based code ownership policy during development would artificially mirror the package structure into the respective concept of coupling. Construct Validity—Are the constructs measured as intended? Multiple constructs are measured in the study. On the one hand, different metrics conceptualize multiple concepts of coupling: where feasible standard metrics are used to measure the concepts as argued in Section 3.3. On the other hand, the congruence metric introduced in Section 5.3.2 captures the relationship between concepts of coupling and a modularization. Potentially, each of these conceptualization and metrics can be flawed or alternative measures might be more suitable. However, each metric is motivated and explained in detail and reasons are provided for selecting it. External Validity—Are the results generalizable? The generalizability of the results is limited with respect to different dimensions: First, the set of sample projects only covers small- to mid-size object-oriented open source systems written in Java. Analyzing other kinds of systems would provide a bigger picture; for instance, closed source systems usually follow a different style of development, which could lead to different outcomes. Second, modularity is studied on a mid-level of abstraction— assembling methods into classes instead of grouping classes into packages might follow other standards. Nevertheless, certain generalizability is warranted by studying a reasonable number of projects having diverse areas of application.
5.5.2 Related Empirical Studies Code couplings and modularity principles were discussed over decades but only few studies investigated them empirically. These studies build upon a multitude of ways of conceptualizing modularity and coupling in metrics as well as they employ various methodologies. This section aims at providing an overview of those studies. Abreu and Goul˜ao [4] present an approach to find out whether coupling and cohesion (Principle 1) are the driving forces of the modularization of a software system. They define a modularization quality metric called modularization merit factor and generate modularizations by applying clustering algorithms that optimize this metric.
5.5 Discussion
159
In a study with 23 software projects, they compared the optimized metric values against the metric values of the original modularization. They were able to improve the original quality and conclude that “the ideal of minimal coupling and maximal cohesion [. . . ] does not match practitioners’ reality at least in what concerns the modularity of object-oriented systems.” However, in my eyes, this conclusion goes too far: They optimize a metric and, regardless of what this metric is measuring, a good optimization is supposed generate modularizations with higher metric values than the ones of the original modularizations. Their conclusion is, hence, based on the assumption that their metric nearly perfectly measures the quality of a modularization, which appears to be unrealistic. Nevertheless, their study shows that coupling and cohesion might not be the only criterion used in practice. In a meta-analysis, Colfer and Baldwin [71] surveyed and summarized empirical work on the congruence between the design of a system and the organization of the development team, which is closely related to Conway’s law (Principle 3). The 102 analyzed empirical works (not only studying software systems but also other systems) are divided into within-firm, across-firm, and open collaboration (e.g., open source) projects. Their results generally support the assumptions of Conway’s law : 77% of the within-firm project works and 74% of the across-firm project works revealed a reasonable congruence. However, only 39% of the works on open collaboration systems provided an equivalent support. They argue that such projects do not depend as much on team organization because they can particularly rely on shared motivations, trust, and understanding; the latter is assumed to be achieved by actionable transparency—every team member possesses the means to change the design. In a similar context, Cataldo et al. [66] investigated in a case study how the congruence between code couplings and the actual communication between developers influences productivity. They found that a higher congruence rate leads to better productivity, for structural couplings as well as for evolutionary couplings. In other words, if the communication structure matches the structural or evolutionary coupling structure, the developers tend to process modification requests faster. Comparing the two types of coupling, their results suggest that evolutionary couplings predict these coordination requirements more precisely. In a further study, Cataldo et al. [67] focused on the impact of different coupling types on failures and investigated structural, co-change, and work-related couplings. They conclude that co-change and work-related couplings have a higher impact on failures than structural couplings. Sarkar et al. [234] propose a set of metrics to measure different aspects of modularity. Among those, they study module relationships such as the similarity of purpose of modules, the commonality of goals, module encapsulation, cyclic dependencies, and unidirectionality of control flow. The introduced metrics are based on function, calls and the concepts (vocabulary) used in the functions. The approach is limited to non-object-oriented software working with explicit API definitions. The authors
160
5 Empirically Analyzing the Congruence
test the metrics in a study on six large open source systems and report that all aspects of modularity mentioned above impacted the modularization of the systems: the respective metrics significantly decrease when switching from the original modularization to a randomly created one. The experiment, however, cannot quantify this impact. In a follow-up work, Sarkar et al. [233] introduce similar metrics for object-oriented systems. They use different types of structural dependencies and measure, among others, different forms of module coupling, API cohesiveness, and common use of module classes. Again, a study showed that the simulated decay of the modularization goes along with a decrease of the modularity metrics as assumed. Related to these approaches, Abdeen et al. [2] present object-oriented modularization metrics that do not depend on the specification of APIs. These metrics are divided into metrics measuring coupling of packages and those measuring cohesion; they also work on structural dependencies. But these metrics have not yet been applied in an empirical study. Dong and Godfrey [89] investigated the types of relations between packages in detail. For example, if a package is only accessed by a single other package, it seems likely that the first package just exists to meet the needs of the second package. Or one package that is used by many other packages may indicate that an abstract resource is implemented in different ways in different packages. They showed in case study how these types of inter-package relations help to analyze the architectural evolution of a software system. This approach reveals important characteristics of single packages. It somehow hints at design principles that were used to design a particular package. But these principles are different kind of principles than those studied in the current work. While they look at local, package specific principles, the presented study investigates mostly global principles for package design. In an extensive case study on the architectural evolution of Eclipse, Wermelinger et al. [280] investigated whether certain laws and guidelines are followed, among them, the principle of low coupling and high cohesion (Priniciple 1) and Martin’s principles on package design [182]. They found that the cohesion of the architecture decreased while coupling with respect to external dependencies stayed constant over time. Their results did not show any general violation of Martin’s cohesion principles (common-reuse principle and common-closure principle) and confirm Martin’s coupling principles (acyclic-dependencies principle and stable-dependencies principle). Moreover, the authors revealed support for aspects of Lehman’s laws on software evolution [167] by observing a steady growth of size and complexity. In general, the focus of the study was more on the evolution of the system than on directly comparing modularity principles. Another study on the evolution of low coupling and high cohesion was performed by Zanetti and Schweitzer [298]: They used a modularity metric on structural dependencies and found projects with decreasing as well as ones with increasing modularity during the course of development. Very recently, Bavota et al. [20] presented a study on the developers’ perception of code coupling. They compared four concepts of coupling to each other: struc-
5.5 Discussion
161
tural coupling based on method calls, dynamic coupling based on executed method calls, evolutionary coupling based on support and confidence, and semantic similarity based on LSI. 76 developers were asked whether they consider specific pairs of classes from three open source Java systems as coupled. The results show that, in particular, semantic coupling matches the intuition of the developers, followed by the structural and dynamic coupling. As part of this study, the authors also investigated the overlap between different concepts of coupling, which is similar to the correlation analysis performed in Section 5.4.1: they observe a high number of unique couplings for structural and semantic coupling, while they find strong evolutionary couplings to be often included in structural or semantical relationships.
5.5.3 Implications on Modularity Principles Based on the conjectured relationships between concepts of code coupling and modularity principles, the impact of these principles in the analyzed software systems can be studied. One must beware, however, of over-interpreting the results with respect to these principles due to several reasons: First, some of the conjectured relationships are indirect and rely on some untested assumptions, for instance, that information hiding is reflected in internal fan-out similarity. Second, the observed couplings might only capture parts of the effect of applying a particular principle— the absence of a congruent coupling-modularity structure does not necessarily mean that the related principle was not applied. And third, an observed congruence can be an effect of applying a certain principle, but may also be caused by applying another principle or development strategy having similar effects. In conclusion, the following findings can be treated as circumstantial evidence. They provide first insights in the potential usage of modularity principles and might serve as hypothesis in future research. To get an overview of the results and their relationships to the modularity principles, Table 5.5 combines the conjectured relationships from Table 5.1 and the main results from Figure 5.4 at a high level of abstraction. The congruence is rated as high if at least one of the listed concepts of coupling exceeds the baseline clearly and is among the highest congruence values for both congruence metrics, as medium if at least one of the listed concepts exceeds the baseline clearly, and as low if none of the listed concepts exceeds the baseline clearly. For the principle of low coupling and high cohesion (Principle 1), the results indicate that the principle is likely to have a reasonable impact on the studied systems because the congruence values are high for all three related concepts (SD.Inh, SD.Agg, and SD.Use). The relatively evident conjectured relationship between the principle and the structural dependencies (Section 5.2.1) substantiates this finding. However, the result is partly contradicting the conclusion that Abreu and Goul˜ao [4] draw based on their study: low coupling and high cohesion well seems to be a relevant
162
5 Empirically Analyzing the Congruence
Table 5.5: Summarized congruence results for the conjectured relationships between modularity principles and concepts of coupling. Modularity Principle
Concepts of Coupling
Congruence
low coupling and high cohesion
SD.Inh, SD.Agg, SD.Use
high
information hiding
FO.InhI, FO.AggI, FO.UseI
high
EC.Sup, EC.Conf
high
Conway’s law
CO.Bin, CO.Prop
low
domain knowledge
SS.Tfidf, SS.LSI
medium
separation of concerns
FO.InhE, FO.AggE, FO.UseE
low–medium
[not classified]
CC.I, CC.II
medium–high
criterion, maybe not the only one. Considering the role of the different kinds of structural dependencies, it could be argued that inheritance plays the most important role because of its higher congruence values and hence can be considered as the strongest dependency with respect to low coupling and high cohesion. The principle of information hiding (Principle 2) is assumed to be connected to internal fan-out couplings (FO.InhI, FO.AggI, and FO.UseI ) as well as to evolutionary couplings (EC.Sup and EC.Conf ) as argued in Section 5.2.2. Since both groups of concepts of coupling show high congruence to the modularizations of the studied systems, information hiding can also be considered as having a substantive impact. Again inheritance plays a distinguished role as the concept based on similar internal inheritance fan-out (FO.InhI ) provided the overall best congruence values. In contrast, Conway’s law (Principle 3) cannot be backed by the presented results: code ownership couplings (CO.Bin and CO.Prop)—presumably related to Conway’s law (Section 5.2.3)—only showed a very low congruence to the modularizations, even not considerably exceeding the baseline. The meta-analysis by Colfer and Baldwin [71] reports similar findings for open source systems (not for within-firm projects). However, the current results may possibly be an artifact of the size of the considered projects or of inappropriately conceptualizing Conway’s law : maybe, taking the task-based perspective that Kwan et al. [159] propose would provide higher congruence between the communication structure and the system design. For the importance of domain knowledge as a modularity principle, the results provide partial support: couplings by semantic similarity (SS.Tfidf and SS.LSI ), which are supposedly related to domain knowledge (Section 5.2.4), provide congruence values clearly above the baseline, but not as high as other concepts of coupling such as direct structural dependencies or evolutionary couplings. This hints that domain knowledge may have a certain impact on the modularization of the systems, but could as well be an artifact of other strategies applied: for instance, calling the same method from different code entities also results in similar vocabulary—semantic
5.5 Discussion
163
similarity has some correlations to other concepts of code coupling as reported in Section 5.4.1. Hence, findings related to semantic similarity have to be looked at with particular caution. But at least semantic coupling seems to match well the developers’ perception of coupling [20]. The impact of the separation of concerns seems to be rather low as the couplings that are assumed to be related show (Section 5.2.4): only inheritance-based couplings (FO.InhE ) among the external fan-out couplings (FO.InhE, FO.AggE, and FO.UseE ) reasonably exceed the baseline. But as the average congruence shows, also this inheritance-based information appears to be quite sparse. Possibly, concerns could not have been separated because they cross-cut the existing modularization. Applying aspect-oriented programming [255] may provide the means for such separation—repeating the study on aspect-oriented systems and comparing those to non-aspect-oriented ones would be an interesting direction for future research. Code clones (CC.I and CC.II ) were the only concept of coupling that could not be connected to a particular concept of coupling because they might stand-in for different other concepts of coupling (Section 5.2.5). Nevertheless, they reach congruence value clearly above the baseline; in particular, clones of type I (CC.I ) nearly reach the high congruence values of other concepts. Hence, code clones may have significantly impacted the modularization of the systems, but it is hard to tell how— detailed investigations on the usage of clones are necessary to clarify their role. Quite surprising, no reasonable difference in congruence were observed for different types of modules (Section 5.4.3); even utility packages, which are said to follow different rules [279], showed results conforming to other types of modules. With respect to modularity principles this suggests that the same principles are applied to all types of modules alike.
5.5.4 Impact on Tools Many software engineering tools use code couplings for supporting a specific aspect of software development. The results of this study might be of particular interest for the automatic or semi-automatic modularization of software systems, such as software clustering, component extraction, or aspect mining tools. While usually only one concept of coupling is used in such tools, the results shed some light on how multiple concept of coupling can be leveraged for improving the approaches. First of all, the study suggests that multiple principles are applied for modularizing software systems: several concepts of coupling provided a high congruence to the modularization. Tools should at least cover those high-congruent concepts, namely, direct structural dependencies, internal fan-out couplings, and evolutionary couplings. Focusing on only one of those groups bears the risk of overlooking important aspects for modularizing a software system.
164
5 Empirically Analyzing the Congruence
Moreover, when using direct or indirect structural dependencies, it seems beneficial to discern at least inheritance-based couplings from other couplings: they are largely independent of aggregation-based and usage-based couplings and provide higher congruence values than those other couplings. Otherwise, mixing all structural couplings together, usage-based and aggregation-based couplings might weaken the quality of the inheritance-based couplings. Also discerning internal and external fan-out couplings surprisingly led to quite different congruence values for the two groups of structural dependencies; these two groups should be discerned as well. Although often considered as bad smells, code clones may have a positive impact when being used as a data source for modularizing a software system: the respective couplings showed medium to high congruence values. Code clones usually replace other couplings such as structural dependencies; omitting those clone-based coupling is comparable to omitting parts of the dataset of other concepts of coupling. In general, the results suggest that the same algorithms can be applied to all types of modules since no considerable type-specific differences were observed. The study furthermore prepares the ground for new applications such as a tool that automatically checks whether the developers follow certain modularity principles and recommends improvements in case of violations of those principles.
CHAPTER 6 Component Extraction
While there exist plenty of applications using code couplings for software engineering tasks, different concepts of coupling are rarely compared systematically and integrated. As the last main part of this thesis, multi-dimensional code couplings are tried to be leveraged for improving the modular structure of software systems. Adapting and focusing the ideas of software clustering, a novel approach is presented that intends to help developers extracting components from their system for independent future development. As an interactive and iterative approach, it supports the developer without dominating the process. An advanced user interface, embedded into the IDE (integrated development environment), enables interacting with the complex data. First, the component extraction approach is outlined (Section 6.1) and concrete objectives are discussed (Section 6.2). An algorithmic solution is then presented that covers the automatic part of the approach (Section 6.3). An interactive tool
165
166
6 Component Extraction
integrates the component extraction approach into the development process (Section 6.4). In an empirical evaluation, it is tested whether multi-dimensional code couplings can be leveraged in this approach (Section 6.5). Finally, related work is presented and the applicability of the approach is discussed (Section 6.6).
6.1 Component Extraction Approach The feasibility study (Chapter 2) analyzed the application of software clustering and employed different concepts of code coupling for improving the clustering. Though this approach turned out to be promising, the lessons learned (Section 2.4) also showed some limitations. Moreover, analyzing the results of the feasibility study with the matrix visualization approach (Section 4.4.5) provided a deeper understanding. Instead of going back to software clustering, the gained insights suggest a more user-centered and focused approach: • Software clustering follows a holistic approach—the whole software project is modularized, no matter if the data density and data quality is high enough in every part of the project. It might often be more beneficial to focus only on parts of the system. • Software clustering usually starts from scratch—most clustering algorithms disregard the original modularization of the system, which often exists and carries important information. However, the developers probably do not want the algorithm to change the whole system, but only to show optimizations for the most severe design weaknesses. • Software clustering often is non-interactive—the algorithm produces a result that the developer can either accept or reject, but the developer usually is not supported in adapting the result in an iterative process. These concerns are shared by other researchers: For instance, M¨ uller et al. [199] observe and argue that “when composing subsystem structures, software engineers make intuitive or subjective decisions based on experience, skill, and insight which cannot and should not be fully automated.”. Concluding a study on software clustering, Glorie et al. [117] further recommend to “make sure that your clustering tool (1) supports a predefined starting solution and (2) does not tear this initial clustering apart.” Rama [222] further points out that, in many application scenarios of software clustering, the software already has some partial modular structure or the existing modularization has just eroded. Considering these issues, the application for further investigating multi-dimensional code couplings is adapted: Instead of modularizing the whole project into multiple parts in an unsupervised approach, the focus becomes extracting a single component from the system aided by the computer. The target is enabling the future independent development of the extracted component.
6.1 Component Extraction Approach
167
6.1.1 Application Scenario The following story illustrates a scenario where tool support for component extraction would considerably ease the work of the developers and smooth the future evolution of the software.
Example 6.1: A software development team works on a small project that grows over time. At some point, the project reaches a size that cannot longer be managed by the team itself—the developers decide to hand over a part of the project to another development team. Since they did not plan this step from the beginning, a well-shaped component of the right size and content that can simply be transferred to the other team probably does not exist. They have to manually compose this component considering all kinds of dependencies and couplings.
Though imaginary, similar examples probably occur in many teams. A particularly prominent use case for component extraction would be outsourcing parts of the development work not only to a different team, but to a different company that might be located at the other side of the globe. Then, even more aspects come into play: communication becomes more difficult, and the original team may not want to share all knowledge and code of the system with the new team due to a lack of trust. Targeting the ease of future development, the component to be extracted is not necessarily a component in terms of component-based software engineering—an early definition of the term component was formulated at the 1st ECOOP Workshop on Component-Oriented Programming in 1997 [253]: A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties. The first sentence, as the core of the definition, refers to a well-defined structure of the component and agrees with the concept of component required in the current scenario. Postulating independent deployment, however, is not required for the intended extraction approach: the components should be developed as independently as possible, but do not need to be deployed as stand-alone packages. Hence, the definition of component applied in the following is somewhat more general: in the context of this work, a component is a well-defined unit of composition with explicit dependencies that can be developed independently to large extents.
168
6 Component Extraction
user interaction
identify key entities
shape the component
generate a contract
computer-aided
Figure 6.1: Three-staged process of interactive computer-aided component extraction.
6.1.2 Code Couplings Similar to software clustering, component extraction is closely related to code couplings. Recalling the definition of Fowler quoted at the beginning of Chapter 1—“If changing one module in a program requires changing another module, then coupling exists.” [102]—future independent development of components requires that the components are not coupled; otherwise, coupling induces changes across different components. While perfect segregation is the idealistic but unreachable goal, component extraction should at least try to minimize coupling between the components. Assumed as being indicators of future co-changes, all concepts of coupling considered in this work (Section 3.3) are relevant for component extraction as a matter of principle.
6.1.3 Extraction Process As a starting point, it is assumed that the developers already have some rough idea which part of the software they want to extract. Based on this, the component extraction tool should propose a component that can be extracted. A user interface is intended to present this result and to support the interactive modification of it. In total, the component extraction approach forms a tool-supported process covering algorithmic aspects, questions of data processing, user interface design, and interaction. The proposed approach is a three-staged procedure; it is described in the following and illustrated in Figure 6.1. Identify Key Entities: A software developer (or a group of developers) planning the extraction of a component probably already knows a set of features or parts of the system that are candidates for the extraction. A simple way to roughly express what should be extracted is to name key entities that are to become
6.2 Objectives
169
part of the extracted component and other key entities that shall remain in the original system. Shape the Component: While key entities are fixed, all other entities are free to be moved during the extraction process. Taking the key entities as seeds, an algorithm may propose a partition of the system into two components, the extracted component and the original component. Based on different concepts of code couplings, the free entities can be moved to minimize the cut between the two components so that co-changes between code entities belonging to different components will be largely avoided in future development. Generate a Contract: Since it will not be possible in general to reach perfect segregation, the two components still will interact with each other and occasionally need to be co-changed. To document the still existing couplings between the two components, a contract is to be generated. Changing an entity in one component that is coupled with the other component should require changing the contract as well. And changes of the contract can only be implemented in agreement of the two development teams. Repetitions of this three-staged cycle allow an iterative procedure. Since classes and interfaces are the smallest entities in object-oriented systems that can be moved independently, they form the atomic entities for generating new components. While the first stage is executed by the user, the two following stages can be performed automatically.
6.2 Objectives As a first objective, an algorithmic solution is required that supports shaping the components: Based on a set of key entities the algorithm should propose a specific component. Rerunning the algorithm with an adapted set of key entities should be possible and should produce similar results. Further, the algorithmic solution is intended to automatically produce a contract for the currently selected component. Objective 6.1: Specify an algorithm for the extraction of software components that includes shaping the component and generating a contract.
A further goal is to develop an interactive tool for component extraction providing an intuitive graphical user interface. The requirements for the user interface are to enable the selection of key entities and the interactive adaption of a proposed component. Presenting the current state of the two components and the contract also involves showing a representation of code couplings. Further, the extraction should be tightly integrated into the software development process.
170
6 Component Extraction
Objective 6.2: Design a user interface that embeds component extraction as an interactive and iterative approach into the software development process.
Finally, the approach needs to be evaluated by estimating the quality of the extracted components. An issue of particular interest thereby is which concepts of coupling should be considered for component extraction. Similar to the feasibility study (Chapter 2), a combination of multiple concepts might improve the results. Objective 6.3: Evaluate the component extraction approach with a specific focus on the use of multi-dimensional code couplings.
6.3 Algorithmic Approach The algorithm supporting the user as demanded by Objective 6.1 forms the core of the component extraction process. As an input, it takes a coupling graph and the two set of key entities identifying the two future components. Based on this data, the algorithm proposes the components. In a second phase, a contract is generated matching the components.
6.3.1 Component Extraction Problem The result of a component extraction algorithm should be a partition of the whole system into two components. Formally, such a partition can be described as follows:
Definition 6.1 (Component Partition): A component partition for a set of code entities V is a tuple of sets of code entities (V1 , V2 ) where V1 ∩ V2 = ∅ and V1 ∪ V2 = V . V1 and V2 are called components.
It is, however, required that the component partition reflects the two sets of key entities that identify the fixed elements of the two components—each of these sets is to be a subset of one of the components. Only component partitions providing this feature are valid with respect to the intended component extraction.
6.3 Algorithmic Approach
171
Definition 6.2 (Valid Component Partition): Given two sets of key entities Korg , Kextr ⊆ V where Korg ∩ Kextr = ∅, the component partition (Vorg , Vextr ) is a valid component partition if Korg ⊆ Vorg ⊆ V and Kextr ⊆ Vextr ⊆ V . While Vorg is called original component, Vextr is referred to as the extracted component.
In a general form, the problem of extracting a component can be modeled as finding an optimal valid component partition for two given sets of key entities. There might be different definitions of optimal —to not restrict these different interpretations in the general problem, an arbitrary objective functions might specify the optimization criterion. Hence, the following optimization problem has to be solved by component extraction algorithm:
Definition 6.3 (General Component Extraction Problem): Given two sets of key entities Korg , Kextr ⊆ V where Korg ∩ Kextr = ∅ and an objective function m that assigns a component partition a real valued number, ∗ ∗ then a valid component partition (Vorg , Vextr ) solves the general component 0 0 ∗ ∗ ) for all valid component extraction problem if m(Vorg , Vextr ) ≤ m(Vorg , Vextr 0 0 partitions (Vorg , Vextr ).
Depending on the objective function, very different criteria can be defined for component extraction. For instance, the objective function can reflect the number of couplings that still connect the two component, may apply some software quality metrics on the two components, might consider the complexity of the contract that has to be generated, or could penalize deviations from particular component sizes. While this mechanism is very flexible, it makes the problem hard to solve because, without further restrictions or information on the objective function, all possible 2|V −(Korg ∪Kextr )| valid component partitions need to be evaluated. For a particular objective function, characteristics of this function may, however, allow for simplifying the problem and its solution. Implementing the previously discussed idea of avoiding future co-changes between the components, a particularly natural objective is minimizing the number of couplings that connect the two components, or more precisely, the accumulated weights of these couplings. For a pair of code entities, these accumulated weights are denoted as coupling capacity. Since the direction of the couplings should not make a difference for minimizing the capacity, the following metric is designed to be symmetric.
172
6 Component Extraction
Definition 6.4 (Coupling Capacity): Let G = (V, EV ) be a coupling graph (Definition 3.5) and v1 , v2 ∈ V two code entities, then X X µ(v1 , v2 ) = w+ w (v1 ,v2 ,w)∈EV
(v2 ,v1 ,w)∈EV
is the coupling capacity between v1 and v2 .
The goal is minimizing the overall coupling capacity between to the two components. Expressing this as an objective function, a simplified version of the component extraction problem can be defined: Definition 6.5 (Simple Component Extraction Problem): Given two sets of key entities Korg , Kextr ⊆ V where Korg ∩Kextr = ∅, then a valid ∗ ∗ component partition (Vorg , Vextr ) solves the simple component extraction problem if it is a solution for the general component extraction problem applying the objective function X X m(Vorg , Vextr ) = µ(vorg , vextr ) . vorg ∈Vorg vextr ∈Vextr
6.3.2 Algorithmic Solution Experiments with the general component extraction problem showed that applying an exhaustive algorithm testing all valid partitions is only feasible for unrealistically small sets of code entities. If the objective function, however, provides some locality, heuristics like a hill climbing approach can be applied for finding good solutions. But still the runtime largely depends on the complexity of the objective function. The specific objective function based on code couplings as defined above does not only narrow down the problem, but also allows and efficient and precise solution of the component extraction problem due to additional assumptions that can be made on the objective function. In particular, the extraction problem becomes equivalent to a min-st-cut problem [76]: for a given source vertex s and target vertex t in a weighted graph, the minimal cut through the graph is computed so that s is on one side of the cut and t on the other side. The objective function m of the simple component extraction problem is equivalent to the capacity of the cut. The only difference is that, in case of the component extraction, there are multiple entities identifying the components instead of a single source s and target t. But if the two
173
6.3 Algorithmic Approach
coupling graph
min-st-cut graph
v1
v2
v3
v4
v5
v6
t
key classes original
original component
v3 cut
v5 t
key classes extracted
v7
v8
v9
v7
v8
extracted component
Figure 6.2: Transformation of a coupling graph into a graph for solving the min-stcut problem; key entities and component assignments are indicated in green (original component) and red (extracted component).
sets of key entities each are summarized to a single vertex in a transformed graph and the coupling weights are modified accordingly, solving the cut problem directly solves the component extraction problem. Hence, the cut algorithm needs be performed on a modified graph structure based on the coupling capacity and working with summarized vertices. The transformation of the coupling graph into a modified graph for computing the min-st-cut is visualized in Figure 6.2. The following algorithm describes how the transformation works in detail and is applied together with a min-st-cut algorithm to solve the simple component extraction problem.
Algorithm 6.1 (ST-Cut Component Extraction): 1. Generate a new graph and add a vertex for each free entity. 2. Add a vertex s to the graph as a representative of all key entities of the original component and a vertex t as a respective representative for the extracted component. 3. For each pair of code entities v1 , v2 compute the coupling capacity µ(v1 , v2 ) and, if µ(v1 , v2 ) > 0, add an undirected edge between the respective representatives to the graph that has the weight µ(v1 , v2 ). 4. Summarize multi-edges and delete self-edges that may have been generated by mapping multiple key entities to a single vertex. 5. Apply a min-st-cut algorithm on the generated graph using vertex s as source and vertex t as target. 6. Apply the cut to the original code entities by reversing the mapping: all entities belonging to s in the cut graph become elements of the
174
6 Component Extraction
original component, all others are assigned to the extracted component.
The min-st-cut problem is equivalent to the max-flow problem [76]—finding a maximal flow from source to target. An algorithm that efficiently solves this problem is the Ford-Fulkerson algorithm [76]; it is applied in the following.
6.3.3 Inertia The proposed algorithm solves the simple component extraction problem. For practical application, however, some special cases might be of relevance that are not addressed satisfyingly so far: • What to do with unconnected code entities having no couplings to other code entities? This problem frequently occurs in sparse datasets where coupling information is only available for parts of the system. Because of the missing information, there does not really exist a satisfying solution, but at least it will probably be better to take a more conservative approach and assign those entities to the original component by default. • What might be a solution when no key entities are provided for a specific component? The component extraction approach as introduced proposes the following: if only one non-empty set of key entities is provided, all entities are assigned to this component; if both sets of key entities are empty, the assignment can be arbitrary. While two empty sets of key entities do not provide any sensible information, for one non-empty set, there could be better solutions than just refusing to extract a component by assigning everything to one side. For instance, if the users only identified key entities for the extracted component, they probably want to extract only closely related ones. A solution to both problems is introducing inertia, that is, each entity has a certain reluctance to be moved to the extracted component. The extraction approach can be extended easily to implement this by adding additional, very small coupling capacities from the source, which represents the original component, to each vertex representing a free code entity. When applying the component extraction algorithm, isolated entities automatically become part of the original component. And in case that no key entities are selected for the original component, a virtual source is created that automatically is coupled to all free entities to some extent. However, defining a universally applicable value for the inertia capacity is difficult because usage scenarios and coupling structures are too diverse. Instead, it seems more reasonable to let the user adapt the inertia capacity with respect to the current usage scenario. Thereby, also the size of the extracted component can be controlled.
6.3 Algorithmic Approach
175
6.3.4 Component Contract The contract is intended to document and encapsulate couplings between the extracted and the original component. In this context, structural dependencies play a distinguished role: they are the only forms of coupling directly defined in the source code and, in contrast to others, can simply be changed through source code transformations. The goal is to formulate the contract as part of the source code. Refactorings [103] provide the means for adapting the code accordingly without changing the semantics of the software. Among the applied refactorings, extracting interfaces is one of the most important ones. In the end, the contract should contain two groups of interfaces: one encapsulating the extracted component being used by the original component and, vice versa, an encapsulation of the original component. Implementing this, the contract addresses two issues: first, the cross-component couplings become documented in those interfaces, and second, changing a part of a component that requires changing the other component due to structural dependencies involves changing the interfaces contained in the contract. Redirecting Structural Dependencies If two code entities assigned to different components are structurally coupled, the coupling should be redirected through an interface in the contract. In most cases, the redirection requires only a few standard types of refactorings, namely, Extract Interface, Replace Constructor with Factory Method, and Encapsulate Field [103]; only resolving inheritance dependencies is more difficult. The specific steps for constructing the contract are discussed in the following for classes; interfaces are handled alike because they can be considered as special forms of classes only lacking some abilities. In order to keep the size of the contract minimal and to respect the Interface Segregation Principle (“clients should not be forced to depend on methods that they do not use”) [182], also additional, specialpurpose interfaces are extracted for coupled interfaces and not the complete interface is moved to the contract. Usage As defined in Section 3.3.2, usage couplings (SD.Use) are a container of different concrete types of structural couplings, which are not distinguished further in most parts of this work for simplification. In context of generating a contract, however, these subtypes of coupling need to be treated separately: a) Type Usage: Using another class as a type of a local variable, of a method parameter, or of a return value creates a usage coupling. Extracting an interface for the respective class and replacing every usage of this class as a type by the extracted interface redirects this form of coupling; the extracted interface is
176
6 Component Extraction
assigned to the contract. Of course, type usage normally occurs in the context of other usage couplings, which, as a consequence, have to be adapted as well like discussed below. b) Method Call: When replacing the usage of a class by an equivalent interface, all called methods also have to be represented in the interface. Though the implementation of the called method itself does not need to be changed, the method now implements the one declared in the interface. A positive side effect is that this procedure realizes the Dependency Inversion Principle (“details should depend on abstraction”) [182] because concrete class implementations only depend on abstract interfaces. c) Constructor Call: Although a constructor call is a special form of method call, handling constructor calls just like method calls is not possible: interfaces cannot contain constructors. A solution is to introduce a factory method that redirects the constructor call and returns the generated object. But also the factory method cannot be contained in an interface but needs to be part of a class—an additional class ContractFactory is generated as part of the contract for containing all required factory methods. Though feasible, this solution is not as clean as those discussed for the other subtypes of usage couplings: for invoking the constructor, it creates undesirable dependencies from the contract to the implementation classes. d) Field Access: Fields or class variables also cannot be represented in the interface, but there exists a simple solution for this issue: getter and setter methods are introduced to encapsulate each field access by method calls; then, the encapsulated field access can be treated like a usual method call—respective getters and setters become part of an interface in the contract. Aggregation Aggregation coupling (SD.Agg, Section 3.3.2) refers to the use of other classes as types for defining class variables. Though aggregation might have a distinguished role because it is defined on class level, it is very similar to type usage (see above) from the perspective of redirecting dependencies. As a consequence, it is handled alike: the class is just replaced by the extracted interface in the type declaration. Inheritance In contrast, inheritance coupling (SD.Inh, Section 3.3.2) is a more complex form of structural dependency: a class extending another class may use or override methods or constructors of the parent class as well as it may access fields. Nevertheless, it is possible to indirect an inheritance coupling through introducing an interface that both, original parent and child class, implement. The original child class, moreover, has to aggregate another instance of the freshly introduced interface containing the respective instance of the original parent class—the interface reflects all functionality that needs to be accessed by the child class. This solution,
6.4 Interactive User Interface
177
however, seems to be too complicated for being performed by default and may not comply with good object-oriented design. Instead, if necessary or wanted, the user may manually resolve the inheritance dependency by implementing this indirection approach or by other means. Contents of the Contract Applying the redirection of structural dependencies as described, a set of interfaces is generated that form the contract and document the dependencies between the original and the extracted component. All structural dependencies except for inheritance dependencies and constructor calls are redirected through these interfaces, which can be divided into two sets: one encapsulating the original component, one wrapping the extracted component. Additionally, a factory class assembles all redirected constructor calls. Inheritance couplings, however, are not automatically adapted, but it is up to the user to add further interfaces or classes to the contract that also document these kinds of dependencies. By encapsulating only those fields and extracting only those methods that are really used by the other component, the automatically created part of the contract is minimal. While the component extraction algorithm is open for any concept of code coupling, generating the contract is tightly connected to structural dependencies and, as described above, has to treat each sub-form of those dependencies differently; other concepts of coupling cannot be encapsulated alike through introducing interfaces. An option, however, for other concepts is to capture them precisely at least, which can be done in an additional documents attached to the contract. Further tool support would allow for notifying the developers when they change a code entity that is coupled to the other component—the other development team may also have to change the coupled entity.
6.4 Interactive User Interface By assigning key entities, the users are able to interact with the algorithm. However, only doing the assignment once at the beginning does not use the full potential of the approach: the users should be able to check the extraction result; if they are not yet satisfied with the result, they may change the assignment of key entities and rerun the algorithm. This requires an elaborate user interface as formulated in Objective 6.2. One of the main challenges is to present the component extraction results in a readable and effective way—an intuitive and scalable representation needs to be found to represent the components, the contract, and, in particular, the couplings in between. This section presents two versions of a user interface for component extraction: the first version, a standalone tool, can be considered as a first prototype and was eval-
178
6 Component Extraction
uated in small user study; based on the experience from this study, an improved interface was designed and implemented as an IDE plug-in. Besides the integration into the IDE, the two user interfaces mainly differ in the approach used for representing couplings between the components: while the first prototype employed explicit links like in a node-link graph visualization approach, the improved interface works with aggregated lists of couplings in order to enhance scalability. Simplifying the data acquisition process, these prototype implementations are only based on structural dependencies, which are of particular importance for component extraction as they are required for generating the contract. Though not yet implemented, the tools can be extended to integrating other concepts of coupling.
6.4.1 Prototype Interface The first implementation of the component extraction approach was designed as a standalone tool visualizing the components similar to UML class diagrams [45]. Starting the tool, a compiled Java project (bytecode as a jar file) is read in and structural dependencies on method level are extracted using the BCEL library (Byte Code Engineering Language) [80]. Aggregating these structural dependencies on class level similar to the SCDG (Section 2.2.1) creates a class dependency graph, which is used for proposing a component partition. In contrast, generating the contract is based on the fine grained method level information. Besides the Ford-Fulkerson algorithm for solving the min-st-cut problem, also other algorithms and optimization criteria were integrated for experimentation purposes, for instance, a hill-climbing approach minimizing the complexity of the contract. While initially, the contract is only a virtual construct, the tool implements an experimental support for exporting the required refactorings and applying them to the code using CatchUp [130], a tool for recording and replaying refactorings. Like in class diagrams, the tool shows classes and interfaces as rectangular boxes. As depicted for a class DrawPanel in Figure 6.3, the box is titled by the name of the class or interface; the background color of the header discerns classes and interfaces. Attached below and again equivalent to class diagrams, a block of attributes and a block of methods contained in the entity are listed. Icons in front of each attribute and method indicate visibility and other modifiers. To save screen space, boxes are collapsed by default, but can be expanded on demand. The threefold division of splitting a system into two components and a contract is reflected in the user interface by dividing the main view into three juxtaposed columns as shown in Figure 6.4: the original component on the left, the extracted component on the right, and—like a buffer in between—the contract in the middle. Within each column, the boxes representing classes and interfaces are automatically organized in a space efficient layout without overlap. If necessary, scrollbars are
6.4 Interactive User Interface
179
Figure 6.3: Representation of a class in the prototype user interface.
Figure 6.4: Prototype component extraction interface showing an extraction result for a small sample project.
180
6 Component Extraction
blended in for exploring larger sets of entities. Moving the entities between these columns, the user interactively controls the component extraction process. Couplings connecting entities in different components are of particular interest as they are tried to be minimized running the algorithm. Since visualizing all couplings would soon lead to a cluttered interface, only those important inter-component couplings are visualized as curved graphical links in a node-link approach as shown in Figure 6.4. The color of the link discerns between different concepts of structural code coupling. Multiple links between the same entities are aggregated: the logarithmically growing strength of the link represents the number of aggregated links; the color is interpolated between the original colors of the aggregated links. If the source or target entity is expanded, the links are visualized on method granularity (i.e., they start or end in the according method), otherwise on class granularity. Details on couplings for a specific entity are provided on demand by tooltips.
6.4.2 User Study A small user study with three participants was performed to test the usability of the prototype interface and the applicability of the component extraction process in general. Three experienced software developers from academia (9 to 12 years of programming experience, 4 to 8 years in Java) volunteered. They extracted a component from a software system they worked on. They were motivated to think aloud (i.e., to speak out their thoughts) during the experiment; their voice and actions were recorded on video. Before the actual experiment started, the idea of component extraction was briefly introduced to the participants. They were asked to select one of their own software projects where they think the extraction of a component is feasible and beneficial for future development. They chose the three very different projects listed in Table 6.1 with sizes varying from 72 to 139 classes and interfaces: a web application that creates SVG visualizations, a computer game, and a source code analysis tool. While two participants (P1 and P2) wanted to extract a component as proposed, the third participant (P3) already had a highly modularized software system but decided to check the existing components by applying component extraction. The latter is a further interesting application scenario for component extraction that was not considered initially. The experiment itself started with a short oral tutorial on the component extraction tool. For the first two participants, this tutorial included a description of the task and a walk through the user interface. However, for the third participant, in order to test the intuitiveness of the user interface, only the task description was provided without further details on the user interface. The main part of the experiment took 50 to 60 minutes and was organized in two stages: First, the participants started with extracting a component in the same small sample system consisting of
6.4 Interactive User Interface
181
Table 6.1: Sample projects selected by the participants for the user study (#V: number of classes and interfaces). ID
Description
Type
#V
Extracted Component
P1
web-based visualization
research project
139
database connection
P2
poker game
student project
72
GUI and AI
P3
code clone detection tool
research project
123
[check existing components]
23 classes and interfaces; they could select any feature of the sample system that they considered useful to be extracted. Second, the participants switched to their own project and tried to extract the component as planed beforehand. While the first stage mainly targeted at comparing the usability and intuitiveness of the user interface in a controlled setting, the second stage was intended to test the component extraction approach in a realistic scenario.
User Interface Results Besides very specific aspects of usability such as misleading labels, unintuitive interactions, or missing help texts, the results of the user study mainly point out two more general issues that are relevant for designing a good interface for component extraction. Intuitiveness and Familiarity: The intuitiveness of aspects of the user interface largely depended on familiarity: while those parts of the user interface that follow a notation like used in UML class diagrams were directly understood (also by P3, who only got a very quick tutorial), problems mostly occurred for deviations from the UML notation; for instance, the applied color-coded visibility modifiers were harder to understand and remember. Representation of Code Couplings: Although the representation of code couplings was already optimized by showing only inter-component dependencies, participants criticized the lack of overview and found it difficult to follow the links or to retrieve their directions. The studied systems were already too large to fit onto a single screen—users had to scroll to explore the complete list of classes. While the first issue, which is addressing the intuitiveness, can be handled by following existing conventions more thoroughly, the second is issue is a fundamental problem: using node-link representations become problematic when scrolling is required because target and source may not be displayed together on screen and links become very hard to follow. Making nodes smaller is not an alternative because labels are essential for working with the tool.
182
6 Component Extraction
Component Extraction Results In all cases, the initial selection of key entities and application of component extraction did not create the final solution. The participants started to reconfigure the extraction and restarted the algorithm. Moreover, all participants found dependencies in their own source code that they had not been aware of or that they had not expected. They wanted to change their source code to remove the dependencies before proceeding with component extraction—however, this was not possible during the experiment due to technical reasons. Reporting the experiences of the participants in detail, P1 identified a database component as intended but was not completely satisfied because the code included two obsolete classes that P1 wanted to remove before applying the final component extraction. P2 realized by trying to extract GUI and AI that the classes of the project were to strongly coupled in general to perform a sound component extraction without first improving the lower-level design of the software. In contrast, P3 was able to largely confirm the already modular structure of the investigated system by performing several hypothetical extractions. In general, the results again indicate that component extraction needs to be an interactive process applied in multiple iterations: key entities need to be changed, the parameters of the extraction algorithm can be adapted, and also the source code might have to be modified. Moreover, the participants got new insights into their own software during component extraction; in particular, they detected unexpected dependencies. Component extraction, hence, is also considered a program comprehension tool. But although these results provide an insight into the component extraction process as it could be applied in practice, they do not provide much information on the quality of the extracted components. This issue is evaluated in a further study in Section 6.5.
6.4.3 Improved Interface Based on the results of the user study, the goal was to develop an improved user interface for component extraction. The frequent request of the participants to change the source code during component extraction showed that the improved interface has to be integrated more tightly into the environment used for software development—the users want to quickly switch between component extraction and source code editing. This motivated the decision, instead of implementing incremental improvements, to do a complete reimplementation of the user interface as a plug-in for Eclipse, a popular IDE. Additional to this tighter integration, also the scalability of the visualization approach should be improved so that larger projects can be handled with the tool.
6.4 Interactive User Interface
183
Figure 6.5: Main view of the improved interface showing the extraction results for a sample project.
Implementing the approach as an Eclipse plug-in also provided the advantage that code analysis and transformation features of Eclipse could be used: The required structural dependencies were extracted from the Java model and the abstract syntax tree automatically build and updated by Eclipse. Moreover, Eclipse provides automatic refactorings that were used in a partial implementation for constructing the contract. In contrast, the algorithmic solution for component extraction was not reimplemented but reused and adapted from the standalone component extraction tool. Splitting the main view of the visual interface into three parts for original component, contract, and extracted component seemed to be an intuitive solution: participants got quickly familiar with this representation and did not request any changes. Hence, the view that is added to Eclipse by the component extraction plug-in again follows this basic layout, as depicted in Figure 6.5. To avoid long lists of classes and interfaces, the three parts themselves, however, are organized differently in contrast to the prototype: similar to the package explorer in Eclipse (i.e., the main view for navigating through a software system), code entities are organize hierarchically based on the package structure of the system in an indented outline plot (compare to Section 4.3.2). Packages are collapsed by default providing an initial overview and expanded on demand for retrieving details down to the level of methods. Individual vertical scrollbars appear if necessary. But the main difference to the previous implementation of user interface is the representation of couplings—while direct links were used before, the new interface works with aggregated lists of coupled code entities: For each code entity or package in one of the lists, the number of outgoing links to one of the other components is counted. This information, discerned by concept of coupling, is displayed next to the representation of the entity in the respective list. Symbols adapted from UML inheritance, class diagrams represent three forms of structural dependencies: aggregation, and usage. The target of the outgoing coupling is identified by another symbol: original component, contract, and extracted component.
184
6 Component Extraction
Figure 6.6: Tooltip showing detail coupling information on demand in the improved interface.
Still, only inter-component couplings are listed. Ordering the packages and contained entities by the total number of inter-component couplings, it becomes easier to spot entities having many undesirable couplings. For further exploring cross-component couplings, additional details are available on demand: hovering the mouse over a representation of a package or code entity, an extensive tooltip appears, like the one shown in Figure 6.6. From the perspective of the selected package or entity, this view provides the precise targets of all couplings as a form of adjacency list; the lists are divided by the component which is the target of the couplings. Similar to the main view, the targets are collapsed by default on package level but can be expanded analogously. Different sortable columns in the list count the number of couplings discerned by type; color coding from green (few couplings) to red (many couplings) hints at entities with many inter-component couplings. The interactions in the improved interface are similar to the prototype interface. Entities can be moved between the component and assigned as key entities by dragand-drop or by options in the context menu (Figure 6.5). Starting the component extraction algorithm, the assignment of the free entities is optimized and the contract is generated (initially, without changing the actual code). The user might adapt the key entities and restart the extraction algorithm.
6.5 Evaluating Component Extraction
185
6.5 Evaluating Component Extraction The component extraction tool already includes different concepts of structural dependencies to compute the optimal cut between the components. An open question, however, still is what concepts of coupling are most suitable for component extraction and how they might be combined to further improve the results. These questions, related to Objective 6.3, are addressed by an empirical evaluation of the approach where multiple concepts of coupling are contrasted to each other, similar to the empirical study on modularity (Chapter 5); but they are also tested in combination, comparable to the feasibility study (Chapter 2). As a complement to the user study (Section 6.4.2), the evaluation conducted in the following only tests the algorithmic part of the approach by simulating component extraction; it does not involve actual users.
6.5.1 Experimental Design The evaluation is designed as a controlled empirical study on a set of 16 open source Java systems—the same dataset as used for measuring the congruence between coupling and modularity (Section 5.4, Table 5.2). For each project, repeatedly, different sets of key entities are selected and a hypothetic component extraction is performed as a simulation. The quality of the extracted components is assessed; to this end, two measures of independence are specified in the following. By plugging in different coupling data, this design allows for comparing different concepts of coupling including combinations of concepts. Measuring Independence Central aspect of evaluating the quality of the component extraction algorithm is specifying a method that assesses the component partitions. To this end, the general goal of the approach—the independent development of the components—has to be conceptualized as a metric. The following two ideas form the basis for developing heuristics to measure independence. Modular Independence: Assumed that information hiding was applied by the developers to some extent, the current modularization of the studied system is already capturing the needs for future independent development as discussed in greater detail in Section 5.2.2. Hence, the two components are independent if they do not mix code entities from different modules. This approach is similar to the assessment approach applied in the feasibility study, where the existing package structure is taken as a reference (Section 2.2.3). Evolutionary Independence: Evolutionary couplings seems to be a reasonable predictor of future changes [294, 303]. Hence, if the two components are to be
186
6 Component Extraction
developed independently in the future, they should have only been loosely coupled by co-changes in the past. Similar to the congruence metric defined in Section 5.3.2, which relates code couplings to the modularity of the system; the independence metric introduced in the following connects code couplings and a component partition: two components are independent if neither the first component is strongly coupled to the second nor the second to the first. For implementing the two concepts of independence, different concepts of coupling are used: while inserting evolutionary couplings leads to measuring evolutionary independence, a new form of coupling capturing the modularization is introduced for specifying modular independence. As a first step towards defining these metrics, the component coupling metric quantifies the coupling of single component to the whole system (including the component itself). As a counterpart, the intra-component coupling specifies only those couplings within a component. As a general measure of coupling, the undirected coupling capacity µ as introduced in Definition 6.4 is used. Please note that the capacity of self-references is 0 (∀v ∈ V : µ(v, v) = 0).
Definition 6.6 (Component Coupling and Intra-Component Coupling): Let V 0 ⊆ V be a component of a software system consisting of code entities V and µ a coupling capacity defined on V , then X X cµ,V (V 0 ) = µ( v1 , v2 ) v1 ∈V 0 v2 ∈V
is called component coupling and cµ,V (V 0 ) =
X X
µ(v1 , v2 )
v1 ∈V 0 v2 ∈V 0
is called intra-component coupling.
Relating the intra-component coupling to the component coupling provides a measure of how strong a component is coupled itself in relation to the coupling to the other component. Retrieving this value for both components and multiplying the resulting values creates a measure of independence.
Definition 6.7 (Independence of Components): Let (V1 , V2 ) be a component partition (Definition 6.1) of a software system consisting of code
6.5 Evaluating Component Extraction
187
entities V and µ a coupling capacity defined on V , then the independence of components is defined as Iµ,V (V1 , V2 ) =
cµ,V (V1 ) cµ,V (V2 ) · . cµ,V (V1 ) cµ,V (V2 )
Please note that I(V1 , V2 ) is not defined for cµ (V1 ) = 0 or cµ (V2 ) = 0, that is, no code entity of V1 or V2 is coupled to any other entity. When applying the metric, it hence needs to be assured that each component at least has one element connected to another element by some capacity. The defined metric is applicable to arbitrary coupling capacity metrics. For conceptualizing modular independence and evolutionary independence specific capacity metrics based on different concepts of coupling are employed. In case of the evolutionary independence, only a concept of evolutionary coupling (here, EC.Conf ) needs to be plugged in—independence then refers to that the two components were not considerably changed together in the past. In case of the modular independence, there is not any concept of coupling already available, but a suitable concept can be easily constructed from the package structure of the system: two classes are coupled if they are in the same package. Then, as intended, classes of the same package assigned to different components decrease the independence of the respective partition. Baseline A direct comparison of independence values, however, is only valid for the same project and the same sizes of the extracted components: The independence measures are biased by the size of the extracted component because, for instance, a small component cannot collect as many within-component couplings in relation to all possible couplings as a larger one. Since the component extraction approach does not directly allow for controlling the size of the components, an individual baseline value needs to be found for each extraction result, fitting the size of the extracted component. Randomly assembled components of the required size are a simple default baseline: a meaningful component extraction approach should at least be able to clearly produce better results than a random approach. For a proposed extracted component, a random component of the same size can be generated; both component partitions are assessed by the same independence metric and the respective values can be compared (e.g., by computing the difference). A more elaborate approach for defining a baseline value is to assemble the elements of an extracted component based on the package structure of the system: Code
188
6 Component Extraction
entities are added to the extracted component if they are contained in the same package as one of the code entities already contained in the extracted component (or in the respective set of key entities). If not enough entities like this exist for creating a component of the required size, this process is continued with classes that have the least distance (referring to Definition 5.1) to one of the entities of the extracted component. This presents a second baseline for assessing the component extraction results, which is much harder to outperform because it requires improving the already existing modularization. While it is valid to use the first baseline for both independence metrics, the second baseline should not be applied on the modular independence because the two constructs might interact—both use the existing package structure as a reference. Hence, in the experiment, modular independence values are contrasted to respective independence values based on randomly created components (random baseline); evolutionary independence values, however, can be tested against the stronger baseline taking the package structure into account (package baseline). Extraction Scenarios Simulating component extraction, key entities have to be identified before the extraction algorithm can be applied. Since manually selecting key entities is only feasible for a small set of samples and requires developers that are familiar with the code of the studied software project, an automatic approach has to be employed. While initially, an approach based on selecting code entities from the same package was considered, it finally was discarded because it might interact with the package baseline or the modular independence. Hence, a simple random selection of the key entities was applied—though this simulated selection might not be very realistic, it promises an unbiased selection at least. In order to cover different extraction scenarios, two sizes of sets of key entities are considered. First, in the small scenario, 5% of the code entities are each selected as key entities for the original component as well as for the extracted component (90% are free entities). Second, in the large scenario, sets of key entities each contain 30% of the code entities (40% are free entities). The same sets are used for extracting components based on different concepts of coupling. Regarding the requirements for computing the evolutionary independence, it is warranted that each set of key entities contains at least one entity that is evolutionary coupled to three or more other code entities. Different random selections of key entities are tested for each project and extraction scenario in order to get more reliable results. Procedure Putting the pieces together, the procedure applied in the study consists of the following steps: First, the necessary coupling graphs are assembled; additional to the
6.5 Evaluating Component Extraction
189
17 concepts of coupling defined in Section 3.3, 10 graphs are created by combining the original concepts in different combinations (ngraphs = 27), for details see below. Then, for each of the 16 projects (nprojects = 16), the concrete extraction scenarios (nscenarios = 2) are instantiated by randomly selecting key entities as described above; nrep = 20 instances are created for each project and scenario. After these preparations, the actual component extraction is performed for each coupling graph and each instantiated scenario. Finally, the assessment method is applied to the extracted components: for each component extraction result, the respective baseline components are created; then, the two independence metrics are computed on pairs consisting of an extracted component partition and baseline component partition. Since neither a user interface nor the extraction of the contract is needed for running the simulation, the component extraction algorithm was reimplemented as a lightweight console application that could be executed on a compute server. Extracting the components is the computationally most expensive part of the study. In total, the number of extraction algorithm runs that had to be performed is n = nprojects · nscenario · ngraphs · nrep = 16 · 2 · 27 · 20 = 17, 280 . But since each performed component extraction is independent of all other extractions, the simulation is parallelizable by default.
6.5.2 Results Applying the described procedure, component partitions are generated and assessed. The results are reported as differences between the independence of the component partition generated by the algorithm and the independence of an equally-sized baseline partition. These differences are summarized by computing a mean value per project and concept of coupling. Again, boxplots (Figure 6.7 and Figure 6.8) summarize the results across the different studied software projects. First, results for applying component extraction on single concepts of coupling are discussed; then, promising groups of concepts are tested in combination. In each case, the results are presented separately for the small and large extraction scenario. Moreover, the two assessment metrics—modular independence and evolutionary independence—are applied; as discussed above, modular independence is contrasted to the random baseline while the package baseline is applied to the evolutionary independence. In case of the latter, however, couplings based on the evolution of a software project (evolutionary and code ownership coupling) cannot be considered because they would likely bias the assessment as the evolutionary independence is also based on evolutionary information.
190
●
0.02 ● ● ●
●
●
●
●
SS.LSI
SS.Tfidf
CC.I
CC.II
CO.Bin
CO.Prop
EC.Conf
EC.Sup
FO.UseI
FO.AggI
FO.InhI
FO.UseE
FO.AggE
SD.Use
FO.InhE
SD.Inh
0.00
SS.LSI
SS.Tfidf
CC.I
CC.II
FO.UseI
FO.AggI
FO.InhI
FO.UseE
FO.AggE
0.04 ● ●
0.02
●
● ●
●
●
0.00
● ●
●
●
●
●
●
SS.LSI
●
●
SS.Tfidf
●
CC.II
● ●
●
0.06
CC.I
●
0.04
evolutionary independence: scenario 'large'
FO.UseI
●
●
FO.AggI
● ●
●
●
−0.1
FO.InhI
●
●
0.0
FO.UseE
0.06
SD.Agg
modular independence − random baseline
modular independence: scenario 'large'
●
FO.AggE
CC.I
CC.II
CO.Bin
CO.Prop
EC.Sup
EC.Conf
FO.UseI
FO.InhI
SS.LSI
●
FO.AggI
FO.UseE
FO.AggE
SD.Use
FO.InhE
● ●
0.1
SD.Use
● ●
SS.Tfidf
●
SD.Inh
0.0
● ●
●
FO.InhE
●
● ●
SD.Use
0.1
●
●
FO.InhE
0.2
●
0.2
SD.Inh
● ●
●
SD.Agg
●
●
0.3
SD.Inh
●
0.3
evolutionary independence: scenario 'small'
SD.Agg
●
evolutionary independence − package baseline
● ●
SD.Agg
modular independence − random baseline
modular independence: scenario 'small' 0.4
evolutionary independence − package baseline
6 Component Extraction
Figure 6.7: Boxplots of the relative modular and evolutionary independence for single concepts of coupling.
Single Concepts of Coupling Figure 6.7 depicts the results for using single concepts of coupling for the component extraction. A first observation is that the results are quite similar for the extraction scenario small (top row) and large (bottom row). Also similarities between the modular independence assessment (left column) and the evolutionary independence assessment (right column) can be noted for those concepts of coupling that are included in both assessment approaches. In case of contrasting the modular independence to the random baseline (left part), several concepts of coupling produce component partitions that clearly exceed the baseline while others do not. Among the best results in both extraction scenarios are direct inheritance dependencies (SD.Inh) as well as internal inheritance fanout (FO.InhI ), and in the large scenario, additionally direct usage dependencies (SD.Use), and both evolutionary coupling variants (EC.Sup and EC.Conf ). In contrast, semantic similarity (SS.Tfidf and SS.LSI ) does not outperform the random baseline, neither considerably do FO.AggE, FO.UseE, CO.Bin, CO.Prop, and CC.II. Since all coupling information based on the evolution has to be excluded when assessing the evolutionary independence of the results, the right part of Figure 6.7 contains fewer concepts of coupling. Although applying the harder to beat package
6.5 Evaluating Component Extraction
191
baseline, the results are similar to those reported before. Only some concepts are closer to the baseline or even slightly below, but the independence for the concepts put in relation to each other does not considerably change. Those concepts that still outperform the baseline are SD.Inh, SD.Agg, SD.Use, FO.InhE, FO.InhI, and FO.AggI. Though used in different context, the observed results are largely consistent to the results reported for the congruence between the concepts of coupling and modularity in Section 5.4.2: SD.Inh and FO.InhI perform best, followed by other concepts of direct structural coupling and evolutionary coupling. This general similarity between those two studies is not surprising—on the contrary, expectable—as they are conceptually related: high congruent concepts of coupling are likely to be suitable for component extraction because they match the modularizing a system. A surprising difference, however, is that semantic similarity does not exceed the baseline for component extraction as well—maybe, the dense graph structure is not as suitable for component extraction as the sparser other concepts. Parts of the results can be also contrasted to the results of the feasibility study (Section 2.3); variants of direct structural dependencies as well as evolutionary couplings were already tested there for software clustering, which is related to component extraction. While the general relation between direct structural and evolutionary couplings is similar, some deviations can be observed within the group of structural dependencies: in the clustering experiment, the usage couplings performed best among the three structural concepts of coupling, but in the context of component extraction, inheritance seems to produce better or at least comparable results, though the inheritance coupling graph is much sparser than the one based on usage. Combined Concepts of Coupling For combining multiple concepts of coupling, a simple approach is applied: the sets of couplings are merged (set union operation) and the coupling weights are summed if the same entities are coupled by multiple concepts; for a balanced aggregation, edge weights are normalized before merging by the total weight of all couplings belonging to the respective concept. Testing all combinations of concepts, however, is not feasible because too many possible combinations exist: 2nconcepts − nconcepts − 1 = 217 − 17 − 1 = 131, 054 . Hence, only a small selected set of combinations is tried—a combination is considered either because it merges similar concepts or because previous result suggest that the combination is promising. Namely, the 10 combinations listed in Table 6.2 are employed; the names of the combined concepts are merged or, when reasonable, replaced by a shorter name. In order to weigh the merged concepts appropriately, some combined graphs are constructed from already previously combined graphs.
192
6 Component Extraction
Table 6.2: Selected set of combinations of couplings employed for evaluating the component extraction approach. Name
Combination
Description
SD
SD.Inh + SD.Agg + SD.Use
direct structural dependencies
FO.E
FO.InhE + FO.AggE + FO.UseE
external fan-out similarity
FO.I
FO.InhI + FO.AggI + FO.UseI
internal fan-out similarity
S
SD + FO.E + FO.I
structural dependencies
SD+FO.I
SD + FO.I
selected structural dependencies
Inh
SD.Inh + FO.InhI
selected inheritance dependencies history-based coupling
EC+CO
EC.Conf + CO.Prop
CC+SS
CC.I + SS.Tfidf
semantics-based coupling
Inh+EC
Inh + EC.Conf
inheritance and evolutionary
Inh+CC
Inh + CC.I
inheritance and code clones
The results for the combined concepts of coupling—together with repeating some results for single concepts for a better comparison—are presented in Figure 6.8 analogously to Figure 6.7: while single concepts are colored as previously, merged concepts are depicted in gray. A general observation, which holds across the all extraction and assessment scenarios, is that merging multiple concepts of coupling does not necessarily improve the result but often only averages the assessed quality: For instance in the small scenario, SD, which merges SD.Inh, SD.Agg, and SD.Use, performs worse than SD.Inh but better than SD.Agg. However in the large scenario, the merged concept SD is assessed as good or even slightly better than SD.Inh, the best of the single concepts that are merged. Similar effects can be observed for other merged concepts. Only rarely, the merged concept performs as worse as the worst merged original concepts (e.g., S in the small scenario). In general, there is no merged concept that consistently outperforms the single concepts, but Inh—a combination of SD.Inh and FO.InhI —at least roughly matches the quality of the best single concept in each scenario. In contrast to the feasibility study (Chapter 2), the merging of concepts does not improve the results of the approach reasonably, but acts more as a way to average the outcome of different concepts of coupling. Since the aggregation technique and the application is similar, it is likely that the component extraction algorithm itself is not able to profit from the aggregation rather than that the couplings do not present valuable information for component extraction. Filtered Couplings The previous observations raise the suspicion that the component extraction algorithm might not work as well on dense coupling graphs than on sparse ones: first,
193
● ● ●
0.02 ● ● ●
0.00
●
●
●
●
● ●
●
CC+SS
Inh+CC
SS.Tfidf
Inh
CC.I
S
SD+FO.I
FO.I
FO.UseI
FO.AggI
FO.E
FO.InhI
0.04 ● ●
0.02
● ●
● ●
●
0.00
● ●
●
● ●
●
● ●
●
−0.02 ●
Inh+CC
●
●
0.04
●
CC+SS
●
SS.Tfidf
●
●
Inh
●
●
CC.I
● ●
●
●
SD+FO.I
0.06
● ●
0.06
S
●
evolutionary independence: scenario 'large'
FO.I
● ●
●
FO.UseI
●
●
●
FO.AggI
●
SD.Inh SD.Agg SD.Use SD FO.InhE FO.AggE FO.UseE FO.E FO.InhI FO.AggI FO.UseI FO.I S SD+FO.I Inh EC.Conf CO.Prop EC+CO CC.I SS.Tfidf CC+SS Inh+EC Inh+CC
modular independence − random baseline
modular independence: scenario 'large' 0.08
●
−0.1
FO.InhI
●
FO.UseE
● ● ●
FO.E
● ● ●
● ●
FO.AggE
●
●
●
FO.UseE
●
0.0
●
0.0
FO.AggE
●
● ● ●
SD
●
●
0.1
FO.InhE
0.1
● ●
FO.InhE
●
0.2
● ●
0.2
SD.Use
●
SD
● ●
SD.Use
0.3
●
SD.Inh
●
●
SD.Agg
●
●
0.3
SD.Inh
●
evolutionary independence: scenario 'small'
SD.Agg
●
0.4
evolutionary independence − package baseline
●
SD.Inh SD.Agg SD.Use SD FO.InhE FO.AggE FO.UseE FO.E FO.InhI FO.AggI FO.UseI FO.I S SD+FO.I Inh EC.Conf CO.Prop EC+CO CC.I SS.Tfidf CC+SS Inh+EC Inh+CC
modular independence − random baseline
modular independence: scenario 'small' ●
evolutionary independence − package baseline
6.5 Evaluating Component Extraction
Figure 6.8: Boxplots of the relative modular and evolutionary independence for single and combined concepts of coupling.
inheritance (sparse) performs better than usage (denser) though it was observed the other way round in the feasibility study; second, results based on semantic similarity (very dense) does not exceed the baseline though they did in the previous experiment; and third, the merging of concepts does not improve the quality of the results, again in contrast to previous experience. Testing this hypothesis, the component extraction is performed on strongly filtered versions of the single and combined coupling graphs: for each code entity and concept of coupling, only the three outgoing couplings that have the highest weights are selected, all others are removed. This procedure also applies to merged concepts, whereas the filtering is only applied after merging. Moreover, for merging, coupling weights are multiplied instead of being summed—this leads to filtering only those entities that have a high weight for both merged concepts. The simulation was rerun on these adapted datasets and the results are presented in Figure 6.9, analogous to Figure 6.8. Although the filtered graphs contain much less information, the results are very similar also with respect to absolute improvements of independence. Comparing the two figures more closely, one indeed observes higher independence for semantic similarity (SS.Tfidf ) with respect to both extraction scenarios as well as to both variants of independence. Also FO.UseE, a further dense graph, now performs somewhat better than the random baseline and no concepts
194
● ● ●
0.00
● ●
●
● ●
●
●
● ●
●
●
CC*SS
Inh*CC
SS.Tfidf
Inh
CC.I
S
SD*FO.I
FO.I
FO.UseI
FO.AggI
FO.E
FO.InhI
FO.UseE
0.02 ●
0.01 ● ●
0.00
●
● ● ●
−0.01
Inh*CC
●
● ●
CC*SS
● ●
● ● ●
SS.Tfidf
●
●
●
0.02
●
0.03
Inh
●
CC.I
0.04
0.04
SD*FO.I
●
S
●
●
● ●
FO.I
●
● ●
FO.UseI
0.06
evolutionary independence: scenario 'large_filtered' 0.05
FO.AggI
●
●
FO.InhI
●
SD.Inh SD.Agg SD.Use SD FO.InhE FO.AggE FO.UseE FO.E FO.InhI FO.AggI FO.UseI FO.I S SD*FO.I Inh EC.Conf CO.Prop EC*CO CC.I SS.Tfidf CC*SS Inh*EC Inh*CC
modular independence − random baseline
modular independence: scenario 'large_filtered'
● ●
FO.E
●
●
●
−0.1
FO.AggE
●
FO.UseE
● ●
●
●
FO.AggE
●
0.0
●
SD
●
●
0.0
FO.InhE
●
FO.InhE
●
0.1
0.1
SD.Use
●
SD
● ●
●
●
SD.Use
●
●
●
●
SD.Inh
0.2
SD.Agg
● ●
● ●
0.2
SD.Inh
● ●
●
evolutionary independence: scenario 'small_filtered'
SD.Agg
0.3
evolutionary independence − package baseline
● ●
SD.Inh SD.Agg SD.Use SD FO.InhE FO.AggE FO.UseE FO.E FO.InhI FO.AggI FO.UseI FO.I S SD*FO.I Inh EC.Conf CO.Prop EC*CO CC.I SS.Tfidf CC*SS Inh*EC Inh*CC
modular independence − random baseline
modular independence: scenario 'small_filtered'
evolutionary independence − package baseline
6 Component Extraction
Figure 6.9: Boxplots of the relative modular and evolutionary independence for filtered single and combined concepts of coupling.
of coupling performs worse than the package baseline anymore. For the combined concepts, not many differences can be found: only S, which is a combination of all direct and indirect structural couplings, outperforms the baselines also in the small scenario for the filtered couplings. These findings provide first evidence confirming that component extraction may better work on sparse coupling graphs. In contrast to the clustering approach applied in the feasibility study (Chapter 2), adding more valuable information does not necessarily improve the results. However, the adapted combination approach— multiplying instead of summing coupling weights—does not show any clear advantages.
6.5.3 Threats to Validity Since the evaluation of the component extraction approach shares some features with the conducted study on modularity (Chapter 5), the validity of the evaluation is limited in a similar way as already discussed in Section 5.5.1. For instance, the same set of sample projects is used in the two experiments and limits their generalizability. Also the analyzed concepts of coupling, the studied level of abstraction, and the
6.6 Discussion
195
presentation of the results are comparable. However, some issues are specific to the component extraction evaluation as discussed in the following. First of all, the component extraction was simulated without involving users although the approach is intended to be interactive. While this simulation allows for testing many runs of the component extraction algorithm, it restricts the approach to the algorithmic part—the quality of the results might be decreased: First, the artificial selection of key entities might not be appropriate because there may not exist a meaningful component for a randomly generated collection of key entities. However, there did not seem to exist an efficient alternative way to create a large number of sets of key entities that both produces more meaningful selections and does not bias the results as discussed in Section 6.5.1. Second, in a real application of the component extraction, the users are able to inspect the result, to refine the assignment of key entities, and to rerun the algorithm. In contrast, the simulated component extraction is neither interactive nor iterative—improving the result through interaction is not possible. Moreover, without actually conducting a component extraction and observing two teams trying to further develop the two created components independently of each other, the independence of the two components can never be measured precisely. The two employed variants of conceptualizing the independence are only approximations. By considering two, not just one metric, at least different aspects of the independence are covered. Other, possibly more elaborate metrics could have been used, but would have still been heuristics. Since the assessment metrics require an equally sized extracted component to be compared with, the baseline is computed individually for each component cut. Hence, if the algorithm suggests leaving the extracted component as it is (i.e., it contains only the key entities), the baseline partition necessarily is the same as the extracted partition: neither an increase nor a decrease of independence is observed. Though this may be a perfectly reasonable result for a particular scenario, it cannot be excluded that a much better partition for this set of key entities exists, which is not directly captured by the assessment method. Finally, another kind of combination strategy or other data filtering approaches might be more suitable for preprocessing the data for the applied component extraction approach. Other concepts of coupling as well as other conceptualization, preprocessing strategies, parameters, etc. might also produce better results.
6.6 Discussion The presented component extraction approach is a novel technique for improving the modularization of a software system. It is designed to repair certain flaws of traditional software clustering approaches such as ignoring the status quo and the
196
6 Component Extraction
developers’ opinion. By focusing on splitting a system into two components, the approach, however, looks at a narrower application scenario than software clustering. The objectives as formulated in Section 6.2 were largely accomplished: An algorithmic solution has been specified that shapes the component and is capable of generating a contract acting as an intermediary between the components (Section 6.3). A user interface integrates this algorithmic solution into the software development process in form of an interactive and iterative approach (Section 6.4). Finally, the evaluation reports how different concepts of coupling and combinations thereof perform being employed for component extraction (Section 6.5). This final discussion reports related works as well as it regards the applicability and extensions of the presented approach.
6.6.1 Related Approaches Component extraction as introduced is related to various reverse and re-engineering techniques. The main part of the process is identifying or shaping a component, which is related to other modularization techniques such as software clustering [178], identification of classes [230], or aspect mining [181]. In the following, an overview is given of those works particularly related, which are either applied locally and only extract a part of a system, work iteratively and can be controlled interactively, or use multiple concepts of coupling. Extracting Code Entities There already exist a few approaches that address component extraction similarly as the presented approach. For instance, Washizaki and Fukazawa [273] propose a refactoring for extracting components: starting from a single code entity, their solution adds all entities that are reachable by traversing structural dependencies. A similar reachability-based approach by Tip et al. [263] tailors libraries for the use on mobile devices. These approaches are related to slicing, where reachability is discussed on the level of program statements in the context of data flow: for example, Lanubile and Visaggio [162] introduce an approach for generating candidates of reusable functions; specified by a set of test cases, Hall [126] identifies an executable subset of a software system implementing the tested functionality. Also based on test cases, Selim et al. [237] propose to manually extract libraries from existing projects. In general, the reuse of software artifacts requires identifying and searching independent parts of a software system that implements a specific functionality. Namely, Washizaki and Fukazawa [274] introduce a search system for finding specific components among all extractable ones—queries are specified as keywords. Also starting from keyword searches, McMillan et al. [186] identify software packages for reuse
6.6 Discussion
197
based on implemented features and external structural coupling costs, in particular for the use case of rapid prototyping. Instead of keywords, also a set of lines of code can be selected as a starting point for identifying reusable components [14]. In order to reduce communications costs, Mockus and Weiss [195] propose extracting those components that frequently changed together but were not developed at the same site by the same team. Interactively Identifying Modules Component extraction can be considered as a specialization of software clustering where only two clusters are created. While there exists plenty of clustering techniques [178], particularly those are related to the presented component extraction approach that allow an interactive refinement of the generated clusters: Koschke [151] introduced a framework that generates candidate modules using a set of different clustering approaches; the user may accept some of the modules or may formulate negative constraints specifying that two entities should not be contained in the same module; clustering can be applied iteratively. Recently, two further approaches incorporated the idea of user-defined constraints [18, 125]: in those systems, a constraint decides whether two code entities should be placed into the same cluster (positive) or in different ones (negative), which is similar to assigning key entities to the two components. While the approach of Bavota et al. [18] is based on a genetic algorithm and creates a clustering from scratch, the approach of Hall et al. [125] applies constraint solving and starts from an already existing modularization. Refactorings, in contrast to clustering, aim at improving the quality of a software system locally and can be applied interactively. Rama [222] argues that in most cases applying some high-level refactorings for improving the modularization of a system would be more suitable than remodularizing the complete system—several metrics, called modularity smells, for identifying refactoring opportunities are proposed. In a somewhat broader context, Lippert and Roock [171] as well as Garcia et al. [113] define further typical architectural problems as starting points for refactoring. Since standard refactorings are often not sufficient for resolving these architectural issues, large refactorings—extensive, unsafe refactorings affecting large parts of the project—are required [171]; as already mentioned, Washizaki and Fukazawa [273] introduce a respective extract component refactoring. To increase the impact and efficiency of these refactoring, Bourquin and Keller [46] propose identifying opportunities for large refactorings based on the number of architecture violations. Beck et al. [32] provide a visualization tool—based on radial node-link diagrams—for interactively planning complex architectural refactorings. Related to component extraction from an algorithmic point of view, min-cut clustering or k-cut clustering minimizes the cut between k clusters [146]. In contrast, the presented component extraction approach is restricted to k = 2 and works with preassigned key entities as a starting point. Min-cut clustering has already been
198
6 Component Extraction
used for general software clustering [145] and for refining large modules created by other modularization techniques [148].
Combining Code Couplings In the evaluation of the component extraction approach (Section 6.5), combining multiple concepts of coupling is tested. While different concepts of coupling have rarely been studied to the extent as in this work, pairs or smaller sets of concepts have already been leveraged in combination in different application scenarios. For instance, structural dependencies and evolutionary couplings are used together for software clustering similarly as done in the feasibility study [8, 241, 283], for aspect mining [52], for change impact analysis [128, 288, 300], or for bug prediction [67]. Also other combinations of concepts have been tested such as structural and semantic information [19, 43], structural and dynamic dependencies [210], or evolutionary and code clone coupling [63]. The combination usually improves the results of the respective approach to some extent. Different strategies exist how to combine multiple data sources in those applications. Starting on the lowest level of abstraction, one may merge the raw data before constructing a coupling graph or a similarity matrix out of it [8, 241]. It is also possible to first transform the raw data into couplings that are used for applying an algorithm like it is done for the presented component extraction approach [19, 283]. Instead of merging the data before running the core algorithm, another approach is concatenating multiple runs of the same algorithm or different algorithms, each based on different data [43, 210]. Or results are computed for each data source independently and only the results are finally combined [147, 288]. These options shows the huge design space for combining multiple concepts of coupling for a software engineering application. Often, they can be used interchangeable, but it is neither clear which of the many general combination techniques produces the best results nor how it should be implemented concretely.
6.6.2 Applicability and Extensions The user study conducted with the prototype user interfaces provided first insights into the applicability of the interactive component extraction approach: users were able to extract meaningful components and identified unnecessary or unwanted structural dependencies. However, users were not able to change those dependencies without restarting component extraction and struggled with scalability problems of the initial visual representation. Overcoming these obstacles, the improved interface was tightly integrated into an IDE using more scalable list representations of coupling data.
6.6 Discussion
199
Evaluating different concepts of coupling in a simulated component extraction showed that different concepts of coupling seem to be suitable for component extraction: In particular, direct and indirect internal inheritance couplings (SD.Inh and FO.InhI ) provided good component partitions, but also other structural dependencies (such as SD.Agg, SD.Use, FO.InhE, FO.AggI, and FO.UseI ), evolutionary couplings (EC.Sup and EC.Conf ), code clones couplings of type I (CC.I ), and filtered semantic similarity (SS.Tfidf ). The combination of those concepts, in contrast to the feasibility study (Chapter 2), did not show any further reasonable improvements. Hence, while it is obvious that different concepts of coupling are suitable for component extraction, it still remains unclear whether and how they can be combined for improving the extraction results. Since the results of the evaluation were not yet looped back into the extraction tool, the implementation of the component extraction tool cannot yet be considered as complete. The goal, however, was not to provide a full-fledged software product that can be used out-of-the-box, but to investigate specific aspect of the proposed component extraction approach. Further extensions towards completing the tool are rather straightforward, but require considerable implementation efforts: More concepts of coupling have to be integrated into the IDE plug-in; the user may choose between different concepts and could compare the proposed extraction results. Moreover, applying the component extraction and actually changing the software system was not yet fully implemented. Additional extensions may further increase the applicability of the approach: The package structure already acted as a reference and baseline for component extraction in the evaluation (Section 6.5), but could be as well used for shaping the component—code entities belonging to the same package become more likely to be placed into the same component. By modeling the package information as a coupling graph as done for defining the modular independence metric, this information can even be incorporated just like the other concepts of coupling. Moreover, computing different candidates for component extraction by applying different concepts of coupling raises the question how to present those candidates to the user; while simply switching between the candidates is certainly a feasible first approach, a guided comparison of the candidates may allow the user for better deciding between the solutions.
200
6 Component Extraction
CHAPTER 7 Conclusion
This thesis analyzes multi-dimensional code couplings—i.e., different concepts of code coupling derived from multiple data sources—in software projects. The goal was taking the next step in understanding these couplings by providing means for exploring those couplings, by presenting empirical findings, and by proposing approaches for improving the modularization of software projects. This final chapter concludes the work by summarizing the contributions, limitations, and possible impact of the thesis. The initial feasibility study (Chapter 2) prepared the ground for the later analyses. It shows, looking at two concepts of coupling and the use case of software clustering, that there exist reasonable differences between the concepts and that combining the information from both concepts could help to improve the general data quality. Hence, it confirms the feasibility of this research project and shows that a combination of multiple concepts of coupling is promising.
201
202
7 Conclusion
While the detailed goals of the research are documented as respective objectives in the previous chapters, the major contributions of this work are threefold, reflecting the three steps taken to tackle the overall problem of understanding multidimensional code couplings. • Develop techniques to visually explore and compare multi-dimensional couplings (Chapter 4): The state-of-the-art graph visualizations only supported the scalable visualization of code couplings, but not the comparison of different concepts of coupling. Hence, two novel visualization techniques were developed to meet the objectives for analyzing such datasets. A particular challenge was the scalable representation of the data. The first visualization technique, the node-link approach, supports the comparison of multiple concepts based on juxtaposed diagrams. In contrast, the second technique, the matrix approach, focuses on comparing two modularizations along with two concepts of coupling. Elaborate interaction techniques ease the comparison tasks in both tools. Case studies and a user study demonstrate how the tools can be used for analyzing multi-dimensional couplings. • Provide evidence how multi-dimensional couplings relate to modularity (Chapter 5): An empirical study compares a set of concepts of coupling including structural dependencies, fan-out similarity, evolutionary coupling, code ownership coupling, code clones, and semantic similarity. After showing that the investigated concepts are largely independent, the different concepts of coupling are contrasted with respect to their congruence to the modularization within 16 open source projects. Particularly high congruence can be observed for internal fan-out inheritance coupling, direct inheritance, aggregation, and usage dependencies, evolutionary coupling, and code clone coupling (type I ). Reasonable differences between different package types are not found. In terms of modularity principles, the results hint at a particular impact of the principle of low coupling and high cohesion and of information hiding. • Demonstrate the use of multi-dimensional coupling for component extraction (Chapter 6): Extending the idea of the feasibility study, code couplings are used to adapt the modularization of software systems in form of extracting software components. Additional to an algorithmic solution, an elaborate user interface is presented for controlling component extraction as an interactive, iterative process. Testing the approach on open source systems, different concepts of coupling show considerably varying quality of results. Combining the different concepts for improving the results, however, seems to be more difficult in this context than for software clustering as implemented in the feasibility study. The results of the thesis are limited by the studied datasets—open source Java systems—and cannot be directly generalized to other systems. Also the level of abstraction targeted in this work—classes, interfaces, and packages—narrows down
203
the applicability of the results. But beyond the concrete findings, this work also provides analysis tools (visualizations and software development tools) as well as methods (metrics, evaluation methods, and algorithms)—these can be used for analyzing other datasets and to replicate the results. Distinguishing features of this work are the large set of concepts considered for code coupling and the focus on fundamentals instead of concrete applications scenarios. The first is reflected in the extensive data acquisition, the scalable visualizations to browse the complex datasets, and the empirical work comparing these concepts. The latter manifest itself mainly in the empirical study on coupling-modularity congruence: abstract congruence values and fundamental modularity principles are investigated instead of directly targeting a particular application. In general, the work takes a holistic approach as it covers different aspect of code coupling—exploration, empirical analysis, and application. This thesis considers code coupling as a multi-dimensional construct rather than a one-dimensional one. While, occasionally, a small set of concepts of coupling have been compared or combined in a particular application, this work is one of the first that systematically investigates the idea of multi-dimensional code couplings. For using the full potential of multi-dimensional code couplings, an open research question, however, still is how to best combine the different concepts. In general, the work can be considered as a first step towards the ambitious goal of understanding multi-dimensional code couplings or—to phrase it in the words of Fowler—how changing one module in a program requires changing another module.
204
7 Conclusion
BIBLIOGRAPHY
[1]
H. Abdeen, I. Alloui, S. Ducasse, D. Pollet, and M. Suen. Package Reference Fingerprint: a Rich and Compact Visualization to Understand Package Relationships. In CSMR ’08: Proceedings of the 12th European Conference on Software Maintenance and Reengineering, pages 213–222. IEEE Computer Society, 2008.
[2]
H. Abdeen, S. Ducasse, and H. Sahraoui. Modularization Metrics: Assessing Package Organization in Legacy Large Object-Oriented Software. In WCRE ’11: Proceedings of the 18th Working Conference on Reverse Engineering, pages 394–398. IEEE, 2011.
[3]
J. Abello and F. van Ham. Matrix Zoom: A Visual Interface to Semi-External Graphs. In InfoVis ’04: Proceedings of the 10th IEEE Symposium on Information Visualization, pages 183–190. IEEE Computer Society, 2004.
[4]
F. B. Abreu and M. Goul˜ao. Coupling and Cohesion as Modularization Drivers: Are We Being Over-Persuaded? In CSMR ’01: Proceedings of the 5th European Conference on Software Maintenance and Reengineering, pages 47–57. IEEE Computer Society, 2001.
[5]
A. Abuthawabeh, F. Beck, D. Zeckzer, and S. Diehl. Type Makes a Difference—Finding Structures in Code Couplings with Node-Link and Matrix Visualizations. yet unpublished, 2013.
[6]
S. Alam and P. Dugerdil. EvoSpaces: 3D Visualization of Software Architecture. In SEKE ’07: In Proceedings of the IEEE International Conference on Software Engineering and Knowledge Engineering, pages 500–505. Knowledge Systems Institute Graduate School, 2007.
205
206
Bibliography
[7]
K. Andrews, M. Wohlfahrt, and G. Wurzinger. Visual Graph Comparison. In IV ’09: Proceedings of the 13th Conference on Information Visualisation, pages 62–67. IEEE Computer Society, 2009.
[8]
P. Andritsos and V. Tzerpos. Information-Theoretic Software Clustering. IEEE Transactions on Software Engineering, 31(2):150–165, 2005.
[9]
D. Archambault. Structural Differences Between Two Graphs through Hierarchies. In GI ’09: Proceedings of Graphics Interface 2009, pages 87–94. Canadian Information Processing Society, 2009.
[10] D. Archambault, H. Purchase, and B. Pinaud. Difference Map Readability for Dynamic Graphs Graph Drawing. In Graph Drawing, volume 6502 of Lecture Notes in Computer Science, chapter 5, pages 50–61. Springer, 2011. [11] C. Y. Baldwin and K. B. Clark. Design Rules, Vol. 1: The Power of Modularity. The MIT Press, 1st edition, 2000. [12] M. Balzer and O. Deussen. Level-of-Detail Visualization of Clustered Graph Layouts. In APVIS ’07: Proceedings of the 6th International Asia-Pacific Symposium on Visualization, pages 133–140. IEEE, 2007. [13] M. Balzer, A. Noack, O. Deussen, and C. Lewerentz. Software Landscapes: Visualizing the Structure of Large Software Systems. In VisSym ’04: Proceedings of the Joint Eurographics - IEEE TCVG Symposium on Visualization, pages 261–266. Eurographics Association, 2004. [14] E. L. A. Baniassad and G. C. Murphy. Conceptual Module Querying for Software Reengineering. In ICSE ’98: Proceedings of the 20th International Conference on Software Engineering, pages 64–73. IEEE Computer Society, 1998. [15] A. Barsky, T. Munzner, J. Gardy, and R. Kincaid. Cerebral: Visualizing Multiple Experimental Conditions on a Graph with Biological Context. IEEE Transactions on Visualization and Computer Graphics, 14(6):1253–1260, 2008. [16] L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice. Addison-Wesley Longman Publishing Co., Inc., 2nd edition, 2003. [17] M. Baur, U. Brandes, M. Gaertler, and D. Wagner. Drawing the AS Graph in 2.5 Dimensions. In Graph Drawing, volume 3383 of Lecture Notes in Computer Science, pages 43–48. Springer, 2005. [18] G. Bavota, F. Carnevale, A. Lucia, M. Penta, and R. Oliveto. Putting the Developer in-the-Loop: An Interactive GA for Software Re-modularization Search Based Software Engineering. In G. Fraser and J. Teixeira de Souza,
Bibliography
207
editors, Search Based Software Engineering, volume 7515 of Lecture Notes in Computer Science, chapter 7, pages 75–89. Springer Berlin / Heidelberg, 2012. [19] G. Bavota, A. De Lucia, A. Marcus, and R. Oliveto. Software ReModularization Based on Structural and Semantic Metrics. In WCRE ’10: Proceedings of the 17th Working Conference on Reverse Engineering, pages 195–204. IEEE Computer Society, 2010. [20] G. Bavota, B. Dit, R. Oliveto, M. Di Penta, D. Poshyvanyk, and A. De Lucia. An Empirical Study on the Developers’ Perception of Software Coupling. In ICSE ’13: Proceedings of the 35th ACM/IEEE International Conference on Software Engineering. IEEE Press, 2013. [21] F. Beck. Improving Software Clustering with Evolutionary Data. Diplomarbeit, 2009. [22] F. Beck, M. Burch, C. Vehlow, S. Diehl, and D. Weiskopf. Rapid Serial Visual Presentation in Dynamic Graph Visualization. In VL/HCC ’12: Proceedings of the 2012 IEEE Symposium on Visual Languages and Human-Centric Computing, pages 185–192. IEEE, 2012. [23] F. Beck and S. Diehl. Evaluating the Impact of Software Evolution on Software Clustering. In WCRE ’10: Proceedings of the 17th Working Conference on Reverse Engineering, pages 99–108. IEEE Computer Society, 2010. [24] F. Beck and S. Diehl. Visual Comparison of Software Architectures. In SoftVis ’10: Proceedings of the ACM 2010 Symposium on Software Visualization, pages 183–192. ACM, 2010. [25] F. Beck and S. Diehl. On the Congruence of Modularity and Code Coupling. In SIGSOFT/FSE ’11 and ESEC ’11: Proceedings of the 19th ACM SIGSOFT Symposium on the Foundations of Software Engineering and 13th European Software Engineering Conference, pages 354–364. ACM, 2011. [26] F. Beck and S. Diehl. On the Impact of Software Evolution on Software Clustering. Empirical Software Engineering (online first), pages 1–35, 2012. [27] F. Beck and S. Diehl. Visual comparison of software architectures. Information Visualization (online first), 2012. [28] F. Beck, S. Diehl, T. Dwyer, M. Gleicher, C. Hansen, I. Jusufi, K.-L. Ma, A. Perer, J. C. Roberts, J. Yang, and D. Zeckzer. Dagstuhl Seminar on Information Visualization (10241), Results of the Working Group on Comparison in Infovis, 2010. [29] F. Beck, A. Pavel, and S. Diehl. Interaktive Extraktion von SoftwareKomponenten. Softwaretechnik-Trends, 32(2):1–2, 2012.
208
Bibliography
[30] F. Beck, R. Petkov, and S. Diehl. Visually Exploring Multi-Dimensional Code Couplings. In VISSOFT ’11: Proceedings of the 6th IEEE International Workshop on Visualizing Software for Understanding and Analysis, pages 1–8. IEEE, 2011. [31] F. Beck, M. Puppe, P. Braun, M. Burch, and S. Diehl. Edge Bundling without Reducing the Source to Target Traceability. InfoVis ’11 Poster, 2011. [32] M. Beck, J. Trumper, and J. Dollner. A Visual Analysis and Design Tool for Planning Software Reengineerings. In VISSOFT ’11: Proceedings of the 6th IEEE International Workshop on Visualizing Software for Understanding and Analysis, pages 1–8. IEEE, 2011. [33] A. Begel and R. Deline. Codebook: Social Networking over Code. In ICSE ’09: Proceedings of the 31th International Conference on Software Engineering (Companion Volume), pages 263–266. IEEE, 2009. [34] A. Begel, Y. P. Khoo, and T. Zimmermann. Codebook: Discovering and Exploiting Relationships in Software Repositories. In ICSE ’10: Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering, pages 125–134. ACM, 2010. [35] A. Bergel, S. Ducasse, J. Laval, and R. Piers. Enhanced Dependency Structure Matrix for Moose. In FAMOOSr ’08: Proceeding of the 2nd Workshop on FAMIX and Moose in Reengineering, 2008. [36] D. Beyer and A. E. Hassan. Animated Visualization of Software History using Evolution Storyboards. In WCRE ’06: Proceedings of the 13th Working Conference on Reverse Engineering, pages 199–210. IEEE Computer Society, 2006. [37] D. Beyer and A. Noack. Clustering Software Artifacts Based on Frequent Common Changes. In IWPC ’05: Proceedings of the 13th International Workshop on Program Comprehension, pages 259–268. IEEE Computer Society, 2005. [38] B. Biegel and S. Diehl. Highly Configurable and Extensible Code Clone Detection. In WCRE ’10: Proceedings of the 17th Working Conference on Reverse Engineering, pages 237–241. IEEE Computer Society, 2010. [39] B. Biegel and S. Diehl. JCCD: A Flexible and Extensible API for Implementing Custom Code Clone Detectors. In ASE ’10: Proceedings of 25th IEEE/ACM International Conference on Automated Software Engineering, pages 167–168. ACM, 2010. [40] C. Bird, A. Gourley, P. Devanbu, M. Gertz, and A. Swaminathan. Mining Email Social Networks. In MSR ’06: Proceedings of the 2006 International Workshop on Mining Software Repositories, pages 137–143. ACM, 2006.
Bibliography
209
[41] C. Bird, N. Nagappan, H. Gall, B. Murphy, and P. Devanbu. Putting It All Together: Using Socio-technical Networks to Predict Failures. In ISSRE ’09: Proceedings of the 20th International Symposium on Software Reliability Engineering, pages 109–119. IEEE, 2009. [42] C. Bird, N. Nagappan, B. Murphy, H. Gall, and P. Devanbu. Don’t Touch My Code! Examining the Effects of Ownership on Software Quality. In SIGSOFT/FSE ’11 and ESEC ’11: Proceedings of the 19th ACM SIGSOFT Symposium on the Foundations of Software Engineering and 13rd European Software Engineering Conference, pages 4–14. ACM, 2011. [43] R. A. Bittencourt, G. J. S. Santos, D. D. S. Guerrero, and G. C. Murphy. Improving Automated Mapping in Reflexion Models using Information Retrieval Techniques. In WCRE ’10: Proceedings of the 17th Working Conference on Reverse Engineering, pages 163–172. IEEE Computer Society, 2010. [44] G. Booch. Object-Oriented Design with Applications. Benjamin/Cummings, 1990. [45] G. Booch, J. Rumbaugh, and I. Jacobson. Unified Modeling Language User Guide. Addison-Wesley Professional, 2nd edition, 2005. [46] F. Bourquin and R. K. Keller. High-impact Refactoring Based on Architecture Violations. In CSMR ’07: Proceedings of the 11th European Conference on Software Maintenance and Reengineering, pages 149–158. IEEE Computer Society, 2007. [47] I. T. Bowman and R. C. Holt. Software Architecture Recovery Using Conway’s Law. In CASCON ’98: Proceedings of the 1998 Conference of the Centre for Advanced Studies on Collaborative Research, pages 1–11. IBM Press, 1998. [48] A. Bragdon, S. P. Reiss, R. Zeleznik, S. Karumuri, W. Cheung, J. Kaplan, C. Coleman, F. Adeputra, and J. J. LaViola. Code Bubbles: Rethinking the User Interface Paradigm of Integrated Development Environments. In ICSE ’10: Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering, pages 455–464. ACM, 2010. [49] U. Brandes, T. Dwyer, and F. Schreiber. Visualizing Related Metabolic Pathways in Two and a Half Dimensions Graph Drawing. In G. Liotta, editor, Graph Drawing, volume 2912 of Lecture Notes in Computer Science, chapter 10, pages 111–122. Springer Berlin / Heidelberg, 2004. [50] U. Brandes and B. Nick. Asymmetric Relations in Longitudinal Social Networks. IEEE Transactions on Visualization and Computer Graphics, 17(12):2283–2290, 2011.
210
Bibliography
[51] S. Bremm, T. von Landesberger, M. Hess, T. Schreck, P. Weil, and K. Hamacherk. Interactive Visual Comparison of Multiple Trees. In VAST ’11: Proceedings of the 2011 IEEE Conference on Visual Analytics Science and Technology, pages 31–40. IEEE, 2011. [52] S. Breu and T. Zimmermann. Mining Aspects from Version History. In ASE ’06: Proceedings of the 21st IEEE/ACM International Conference on Automated Software Engineering, pages 221–230. IEEE Computer Society, 2006. [53] L. C. Briand, J. W. Daly, and J. W¨ ust. A Unified Framework for Cohesion Measurement in Object-Oriented Systems. Empirical Software Engineering, 3(1):65–117, 1998. [54] L. C. Briand, J. W. Daly, and J. K. W¨ ust. A Unified Framework for Coupling Measurement in Object-Oriented Systems. IEEE Transactions on Software Engineering, 25(1):91–121, 1999. [55] M. Burch, F. Beck, and S. Diehl. Timeline Trees: Visualizing sequences of transactions in information hierarchies. In AVI ’08: Proceedings of 9th International Working Conference on Advanced Visual Interfaces, pages 75–82. ACM, 2008. [56] M. Burch, F. Beck, and D. Weiskopf. Radial Edge Splatting for Visualizing Dynamic Directed Graphs. In IVAPP ’12: Proceedings of the 4th International Conference on Information Visualization and Applications, pages 603–612. SciTePress, 2012. [57] M. Burch, F. Bott, F. Beck, and S. Diehl. Cartesian vs. Radial – A Comparative Evaluation of Two Visualization Tools. In ISVC ’08: Proceedings of the 4th International Symposium on Advances in Visual Computing, pages 151–160. Springer-Verlag, 2008. [58] M. Burch and S. Diehl. TimeRadarTrees: Visualizing dynamic compound digraphs. Computer Graphics Forum, 27(3):823–830, 2008. [59] M. Burch, S. Diehl, and P. Weißgerber. Visual Data Mining in Software Archives. In SoftVis ’05: Proceedings of the 2005 ACM Symposium on Software Visualization, pages 37–46. ACM Press, 2005. [60] M. Burch, M. Fritz, F. Beck, and S. Diehl. TimeSpiderTrees: A Novel Visual Metaphor for Dynamic Compound Graphs. In VL/HCC ’10: Proceedings of the IEEE Symposium on Visual Languages and Human-Centric Computing, pages 168–175. IEEE, 2010. [61] M. Burch, C. Vehlow, F. Beck, S. Diehl, and D. Weiskopf. Parallel Edge Splatting for Scalable Dynamic Graph Visualization. IEEE Transactions on Visualization and Computer Graphics, 17(12):2344–2353, 2011.
Bibliography
211
[62] H. Byelas and A. Telea. Visualizing Metrics on Areas of Interest in Software Architecture Diagrams. In PacificVis ’09: Proceedings of the 2009 IEEE Pacific Visualization Symposium, pages 33–40. IEEE, 2009. [63] G. Canfora, L. Cerulo, and M. Di Penta. On the Use of Line Co-change for Identifying Crosscutting Concern Code. In ICSM ’06: Proceedings of the 22nd IEEE International Conference on Software Maintenance, pages 213– 222. IEEE Computer Society, 2006. [64] P. Caserta and O. Zendra. Visualization of the Static Aspects of Software: A Survey. Visualization and Computer Graphics, IEEE Transactions on, 17(7):913–933, 2011. [65] P. Caserta, O. Zendra, and D. Bodenes. 3D Hierarchical Edge Bundles to Visualize Relations in a Software City Metaphor. In VISSOFT ’11: Proceedings of the 6th IEEE International Workshop on Visualizing Software for Understanding and Analysis, pages 1–8. IEEE, 2011. [66] M. Cataldo, J. D. Herbsleb, and K. M. Carley. Socio-Technical Congruence: a Framework for Assessing the Impact of Technical and Work Dependencies on Software Development Productivity. In ESEM ’08: Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement, pages 2–11. ACM, 2008. [67] M. Cataldo, A. Mockus, J. A. Roberts, and J. D. Herbsleb. Software Dependencies, Work Dependencies, and Their Impact on Failures. IEEE Transactions on Software Engineering, 35(6):864–878, 2009. [68] A. H. Caudwell. Gource: Visualizing Software Version Control History. In SPLASH/OOPSLA ’10: Companion to the 25th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, pages 73–74. ACM, 2010. [69] S. R. Chidamber and C. F. Kemerer. A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, 20(6):476–493, 1994. [70] E. J. Chikofsky and J. H. Cross. Reverse Engineering and Design Recovery: a Taxonomy. IEEE Software, 7(1):13–17, 1990. [71] L. Colfer and C. Y. Baldwin. The Mirroring Hypothesis: Theory, Evidence and Exceptions. Technical report, Harvard Business School Finance, 2010. [72] C. Collberg, S. Kobourov, J. Nagra, J. Pitts, and K. Wampler. A System for Graph-Based Visualization of the Evolution of Software. In SoftVis ’03: Proceedings of the 2003 ACM Symposium on Software Visualization, pages 77–86. ACM, 2003.
212
Bibliography
[73] C. Collins and S. Carpendale. VisLink: Revealing Relationships Amongst Visualizations. IEEE Transactions on Visualization and Computer Graphics, 13(6):1192–1199, 2007. [74] M. Conway. How do Committees Invent? Datamation Journal, 14(4):28–31, 1968. [75] T. D. Cook and D. T. Campbell. Quasi-Experimentation: Design & Analysis Issues for Field Settings. Houghton Mifflin, 1979. [76] T. H. Cormen, C. E. Leiserson, R. L. Rivest, and C. Stein. Introduction to Algorithms. The MIT Press, 2nd edition, 2001. [77] P. Craig and J. Kennedy. Concept Relationship Editor: A visual interface to support the assertion of synonymy relationships between taxonomic classifications. Proceedings of SPIE, 6809:680906–680912, 2008. [78] I. Cruz, W. Sunna, N. Makar, and S. Bathala. A visual tool for ontology alignment to enable geospatial interoperability. Journal of Visual Languages & Computing, 18(3):230–254, 2007. [79] W. Cui, H. Zhou, H. Qu, P. C. Wong, and X. Li. Geometry-Based Edge Clustering for Graph Visualization. IEEE Transactions on Visualization and Computer Graphics, 14(6):1277–1284, 2008. [80] M. Dahm. Byte Code Engineering. In Java-Informations-Tage, pages 267–277. Springer, 1999. [81] M. D’Ambros, M. Lanza, and R. Robbes. On the Relationship Between Change Coupling and Software Defects. In WCRE ’09: Proceedings of the 16th Working Conference on Reverse Engineering, pages 135–144. IEEE, 2009. [82] S. Davis. Automatic Juxtaposition of Source Files. Master’s thesis, The University Of British Columbia, 2008. [83] S. C. Deerwester, S. T. Dumais, T. K. Landauer, G. W. Furnas, and R. A. Harshman. Indexing by Latent Semantic Analysis. Journal of the American Society of Information Science, 41(6):391–407, 1990. [84] R. DeLine and K. Rowan. Code Canvas: Zooming towards Better Development Environments. In ICSE ’10: Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 2, pages 207–210. ACM, 2010. [85] G. Di Battista, P. Eades, R. Tamassia, and I. G. Tollis. Graph Drawing: Algorithms for the Visualization of Graphs. Prentice Hall PTR, 1st edition, 1998.
Bibliography
213
[86] E. Di Giacomo, W. Didimo, G. Liotta, and P. Palladino. Visual Analysis of One-To-Many Matched Graphs. Journal of Graph Algorithms and Applications, 14(1):97–119, 2010. [87] S. Diehl, F. Beck, and M. Burch. Uncovering Strengths and Weaknesses of Radial Visualizations—an Empirical Approach. IEEE Transactions on Visualization and Computer Graphics, 16(6):935–942, 2010. [88] S. Diehl and C. G¨org. Graphs, They Are Changing. In Graph Drawing, volume 2528 of Lecture Notes in Computer Science, pages 23–31. SpringerVerlag, 2002. [89] X. Dong and M. W. Godfrey. Understanding Source Package Organization using the Hybrid Model. In ICSM ’09: Proceedings of the International Conference on Software Maintenance, pages 575–578. IEEE, 2009. [90] S. Ducasse and M. Lanza. The Class Blueprint: Visually Supporting the Understanding of Classes. IEEE Transactions on Software Engineering, 31(1):75– 90, 2005. [91] T. Dwyer. Three Dimensional UML Using Force Directed Layout. In APVIS ’01: Proceedings of the 2001 Asia-Pacific Symposium on Information Visualisation - Volume 9, pages 77–85. Australian Computer Society, Inc., 2001. [92] P. Eades and M. L. Huang. Navigating Clustered Graphs using Force-Directed Methods. Journal of Graph Algorithms and Applications, 4(3):157–181, 2000. [93] H. Eichelberger. Aesthetics of Class Diagrams. In VISSOFT ’01: Proceedings of the 1st International Workshop on Visualizing Software for Understanding and Analysis, pages 23–31. IEEE Computer Society, 2002. [94] K. El Emam, W. Melo, and J. C. Machado. The Prediction of Faulty Classes Using Object-Oriented Design Metrics. Journal of Systems and Software, 56(1):63–75, 2001. [95] U. Erdemir, U. Tekin, and F. Buzluca. E-Quality: A Graph Based Object Oriented Software Quality Visualization Tool. In VISSOFT ’11: Proceedings of the 6th IEEE International Workshop on Visualizing Software for Understanding and Analysis, pages 1–8. IEEE, 2011. [96] C. Erten, P. J. Harding, S. G. Kobourov, K. Wampler, and G. Yee. GraphAEL: Graph Animations with Evolving Layouts Graph Drawing. In Graph Drawing, volume 2912 of Lecture Notes in Computer Science, chapter 9, pages 98–110. Springer Berlin / Heidelberg, 2004.
214
Bibliography
[97] C. Erten, S. Kobourov, V. Le, and A. Navabi. Simultaneous Graph Drawing: Layout Algorithms and Visualization Schemes. In Graph Drawing, volume 2912 of Lecture Notes in Computer Science, chapter 41, pages 437–449. Springer Berlin / Heidelberg, 2004. [98] J.-D. Fekete, D. Wang, N. Dang, A. Aris, and C. Plaisant. Overlaying Graph Links on Treemaps. In INFOVIS ’03: Proceedings of the IEEE Symposium on Information Visualization, pages 82–83. IEEE, 2003. [99] H. Fernau, M. Kaufmann, and M. Poths. Comparing Trees Via Crossing Minimization. In FSTTCS ’05: Proceedings of Foundations of Software Technology and Theoretical Computer Science, volume 3821 of Lecture Notes in Computer Science, pages 457–469. Springer, 2005. [100] M. Fischer, M. Pinzger, and H. Gall. Populating a Release History Database from Version Control and Bug Tracking Systems. In ICSM ’03: Proceedings of the 2003 International Conference on Software Maintenance, pages 23–32. IEEE, 2003. [101] B. Fluri, H. C. Gall, and M. Pinzger. Fine-Grained Analysis of Change Couplings. In SCAM ’05: Proceedings of the 5th IEEE International Workshop on Source Code Analysis and Manipulation, pages 66–74. IEEE, 2005. [102] M. Fowler. Reducing Coupling. IEEE Software, 18(4):102–104, 2001. [103] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts. Refactoring: Improving the Design of Existing Code. Addison-Wesley Professional, 1 edition, 1999. [104] M. Freire, C. Plaisant, B. Shneiderman, and J. Golbeck. ManyNets: An Interface for Multiple Network Analysis and Visualization. In CHI ’10: Proceedings of the 28th International Conference on Human Factors in Computing Systems, pages 213–222. ACM, 2010. [105] Y. Frishman and A. Tal. Dynamic Drawing of Clustered Graphs. In INFOVIS ’04: Proceedings of the 10th IEEE Symposium on Information Visualization, pages 191–198. IEEE, 2004. [106] Y. Frishman and A. Tal. Online Dynamic Graph Drawing. IEEE Transactions on Visualization and Computer Graphics, 14(4):727–740, 2008. [107] D. C. Y. Fung, S. H. Hong, D. Koschutzki, F. Schreiber, and K. Xu. Visual Analysis of Overlapping Biological Networks. In IV ’09: Proceedings of the 2009 13th International Conference Information Visualisation, pages 337–342. IEEE Computer Society, 2009.
Bibliography
215
[108] G. W. Furnas and J. Zacks. Multitrees: Enriching and Reusing Hierarchical Structure. In CHI ’94: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pages 330–336. ACM, 1994. [109] H. Gall, K. Hajek, and M. Jazayeri. Detection of Logical Coupling Based on Product Release History. In ICSM ’98: Proceedings of the International Conference on Software Maintenance, pages 190–198. IEEE Computer Society, 1998. [110] H. Gall, M. Jazayeri, and J. Krajewski. CVS release history data for detecting logical couplings. In IWPSE ’03: Proceedings of the 6th International Workshop on Principles of Software Evolution, pages 13–23. IEEE Computer Society, 2003. [111] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, 1 edition, 1994. [112] E. R. Gansner, Y. Hu, S. North, and C. Scheidegger. Multilevel Agglomerative Edge Bundling for Visualizing Large Graphs. In PacificVis ’11: Proceedings of the IEEE Pacific Visualization Symposium, pages 187–194. IEEE, 2011. [113] J. Garcia, D. Popescu, G. Edwards, and N. Medvidovic. Identifying Architectural Bad Smells. In CSMR ’09: Proceedings of the 2009 European Conference on Software Maintenance and Reengineering, pages 255–258. IEEE, 2009. [114] Y. Ghanam and S. Carpendale. A Survey Paper on Software Architecture Visualization. Technical report, University of Calgary, 2008. [115] M. Ghoniem, J. D. Fekete, and P. Castagliola. A Comparison of the Readability of Graphs Using Node-Link and Matrix-Based Representations. In INFOVIS ’04: Proceedings of the 10th IEEE Symposium on Information Visualization, pages 17–24. IEEE, 2004. [116] M. Gleicher, D. Albers, R. Walker, I. Jusufi, C. D. Hansen, and J. C. Roberts. Visual comparison for information visualization. Information Visualization, 10(4):289–309, 2011. [117] M. Glorie, A. Zaidman, A. van Deursen, and L. Hofland. Splitting a Large Software Repository for Easing Future Software Evolution—An Industrial Experience Report. Journal of Software Maintenance and Evolution: Research and Practice, 21(2):113–141, 2009. [118] M. Gogolla, O. Radfelder, and M. Richters. Towards Three-Dimensional Representation and Animation of UML Diagrams. In UML ’99: Proceedings of the 2nd International Conference on The Unified Modeling Language: Beyond the Standard, pages 489–502. Springer-Verlag, 1999.
216
Bibliography
[119] R. Gove, N. Gramsky, R. Kirby, E. Sefer, A. Sopan, C. Dunne, B. Shneiderman, and M. Taieb-Maimon. NetVisia: Heat Map and Matrix Visualization of Dynamic Social Network Statistics and Content. In SOCIALCOM ’11: Proceedings of the IEEE Conference on Social Computing, pages 19–26. IEEE Press, 2011. [120] M. Graham and J. Kennedy. A survey of multiple tree visualisation. Information Visualization, 9(4):235–252, 2009. [121] M. Greilich, M. Burch, and S. Diehl. Visualizing the Evolution of Compound Digraphs with TimeArcTrees. Computer Graphics Forum, 28(3):975– 982, 2009. [122] J. Guerra G´omez, A. Buck-Coleman, C. Plaisant, and B. Shneiderman. Interactive Visualizations for Comparing Two Trees With Structure and Node Value Changes. Technical report, Human-Computer Interaction Lab, University of Maryland, 2011. [123] V. Gupta and J. Kumar Chhabra. Package Coupling Measurement in ObjectOriented Software. Journal of Computer Science and Technology, 24(2):273– 283, 2009. [124] C. Gutwenger, M. J¨ unger, K. Klein, J. Kupke, S. Leipert, and P. Mutzel. A New Approach for Visualizing UML Class Diagrams. In SOFTVIS ’03: Proceedings of the 2003 ACM Symposium on Software Visualization, pages 179–188. ACM, 2003. [125] M. Hall, N. Walkinshaw, and P. McMinn. Supervised Software Modularisation. In ICSM ’12: Proceedings of the International Conference on Software Maintenance, pages 472–481. IEEE, 2012. [126] R. Hall. Automatic Extraction of Executable Program Subsets by Simultaneous Dynamic Program Slicing. Automated Software Engineering, 2(1):33–53, 1995. [127] M. Harman, S. Swift, and K. Mahdavi. An Empirical Study of the Robustness of two Module Clustering Fitness Functions. In GECCO ’05: Proceedings of the 2005 Conference on Genetic and Evolutionary Computation, pages 1029– 1036. ACM Press, 2005. [128] L. Hattori, G. D. Santos, F. Cardoso, and M. Sampaio. Mining Software Repositories for Software Change Impact Analysis: A Case Study. In SBBD ’08: Proceedings of the 23rd Brazilian Symposium on Databases, pages 210– 223. Sociedade Brasileira de Computacao, 2008.
Bibliography
217
[129] J. Heer, M. Bostock, and V. Ogievetsky. A Tour Through the Visualization Zoo. Communications of the ACM, 53(6):59–67, 2010. [130] J. Henkel and A. Diwan. CatchUp! capturing and replaying refactorings to support API evolution. In ICSE ’05: Proceedings of the 27th International Conference on Software Engineering, pages 274–283. ACM, 2005. [131] N. Henry and J.-D. Fekete. MatrixExplorer: a Dual-Representation System to Explore Social Networks. IEEE Transactions on Visualization and Computer Graphics, 12(5):677–684, 2006. [132] N. Henry and J.-D. Fekete. MatLink: Enhanced Matrix Visualization for Analyzing Social Networks. In Human-Computer Interaction – INTERACT 2007, volume 4663 of Lecture Notes in Computer Science, pages 288–302. Springer, 2007. [133] N. Henry, J. D. Fekete, and M. J. Mcguffin. NodeTrix: a Hybrid Visualization of Social Networks. IEEE Transactions on Visualization and Computer Graphics, 13(6):1302–1309, 2007. [134] S. Henry and D. Kafura. Software Structure Metrics Based on Information Flow. IEEE Transactions on Software Engineering, 7(5):510–518, 1981. [135] J. D. Herbsleb and R. E. Grinter. Architectures, Coordination, and Distance: Conway’s Law and Beyond. IEEE Software, 16(5):63–70, 1999. [136] J. D. Herbsleb and A. Mockus. Formulation and Preliminary Test of an Empirical Theory of Coordination in Software Engineering. In ESEC/FSE ’03: Proceedings of the 9th European Software Engineering Conference held jointly with 11th ACM SIGSOFT International Symposium on Foundations of Software Engineering, pages 138–137. ACM, 2003. [137] I. Herman, G. Melan¸con, and M. S. Marshall. Graph Visualization and Navigation in Information Visualization: A Survey. IEEE Transactions on Visualization and Computer Graphics, 6(1):24–43, 2000. [138] D. Holten. Hierarchical Edge Bundles: Visualization of Adjacency Relations in Hierarchical Data. IEEE Transactions on Visualization and Computer Graphics, 12(5):741–748, 2006. [139] D. Holten and J. J. van Wijk. Visual Comparison of Hierarchically Organized Data. Computer Graphics Forum, 27(3):759–766, 2008. [140] D. Holten and J. J. Van Wijk. Force-Directed Edge Bundling for Graph Visualization. Computer Graphics Forum, 28(3):983–990, 2009.
218
Bibliography
[141] S. Huynh, Y. Cai, Y. Song, and K. Sullivan. Automatic Modularity Conformance Checking. In ICSE ’08: Proceedings of the 30th International Conference on Software Engineering, pages 411–420. ACM, 2008. [142] P. Irani, M. Tingley, and C. Ware. Using Perceptual Syntax to Enhance Semantic Content in Diagrams. IEEE Computer Graphics and Applications, 21(5):76–85, 2001. [143] P. Irani and C. Ware. Diagrams Based on Structural Object Perception. In AVI ’00: Proceedings of the Working Conference on Advanced Visual Interfaces, pages 61–67. ACM, 2000. [144] P. Irani and C. Ware. Diagramming Information Structures Using 3D Perceptual Primitives. ACM Transactions on Computer-Human Interaction, 10(1):1– 19, 2003. [145] C. Jermaine. Computing Program Modularizations Using the k-Cut Method. In WCRE ’99: Proceedings of the 6th Working Conference on Reverse Engineering, pages 224–234. IEEE Computer Society, 1999. [146] E. L. Johnson, A. Mehrotra, and G. L. Nemhauser. Min-cut clustering. Mathematical Programming, 62(1):133–151, 1993. [147] H. Kagdi and J. I. Maletic. Combining Single-Version and Evolutionary Dependencies for Software-Change Prediction. In MSR ’07: Proceedings of the 4th International Workshop on Mining Software Repositories, pages 17–21. IEEE Computer Society, 2007. [148] T. Kato, S. Hayashi, and M. Saeki. Cutting a Method Call Graph for Supporting Feature Location. In IWESEP ’12: Proceedings of the 4th International Workshop on Empirical Software Engineering in Practice, pages 55–57. IEEE Computer Society, 2012. [149] R. Keller, C. M. Eckert, and P. J. Clarkson. Matrices or node-link diagrams: which visual representation is better for visualising connectivity models? Information Visualization, 5(1):62–76, 2006. [150] C. Knight and M. Munro. Comprehension with[in] Virtual Environment Visualisations. In IWPC ’99: Proceedings of the 7th International Workshop on Program Comprehension, pages 4–11. IEEE Computer Society, 1999. [151] R. Koschke. An Incremental Semi-Automatic Method for Component Recovery. In WCRE ’99: Proceedings of the 6th Working Conference on Reverse Engineering, pages 256–267. IEEE, 1999.
Bibliography
219
[152] J. Krinke. Identifying Similar Code with Program Dependence Graphs. In WCRE ’01: Proceedings of the 8th Working Conference on Reverse Engineering, pages 301–309. IEEE, 2001. [153] J. B. Kruskal and J. M. Landwehr. Icicle Plots: Better Displays for Hierarchical Clustering. The American Statistician, 37(2):162–168, 1983. [154] A. Kuhn, S. Ducasse, and T. Girba. Enriching Reverse Engineering with Semantic Clustering. In WCRE ’05: Proceedings of the 12th Working Conference on Reverse Engineering, pages 133–142. IEEE Computer Society, 2005. [155] A. Kuhn, D. Erni, P. Loretan, and O. Nierstrasz. Software Cartography: thematic software visualization with consistent layout. Journal of Software Maintenance and Evolution: Research and Practice, 22(3):191–210, 2010. [156] A. Kuhn, D. Erni, and O. Nierstrasz. Embedding Spatial Software Visualization in the IDE: an Exploratory Study. In SOFTVIS ’10: Proceedings of the 5th International Symposium on Software Visualization, pages 113–122. ACM, 2010. [157] G. Kumar and M. Garland. Visual Exploration of Complex Time-Varying Graphs. IEEE Transactions on Visualization and Computer Graphics, 12(5):805–812, 2006. [158] L. Kuzniarz, M. Staron, and C. Wohlin. An Empirical Study on Using Stereotypes to Improve Understanding of UML Models. In IWPC ’04: Proceedings of the 12th International Workshop on Program Comprehension, pages 14–23. IEEE, 2004. [159] I. Kwan, M. Cataldo, and D. Damian. Conway’s Law Revisited: The Evidence for a Task-Based Perspective. IEEE Software, 29(1):90–93, 2012. [160] M. J. LaMantia, Y. Cai, A. MacCormack, and J. Rusnak. Analyzing the Evolution of Large-Scale Software Systems Using Design Structure Matrices and Design Rule Theory: Two Exploratory Cases. In WICSA ’08: Proceedings of the Seventh Working IEEE/IFIP Conference on Software Architecture, pages 83–92. IEEE Computer Society, 2008. [161] A. Lambert, R. Bourqui, and D. Auber. Winding Roads: Routing edges into bundles. Computer Graphics Forum, 29(3):853–862, 2010. [162] F. Lanubile and G. Visaggio. Extracting Reusable Functions by Flow Graph-Based Program Slicing. IEEE Transactions on Software Engineering, 23(4):246–259, 1997.
220
Bibliography
[163] M. Lanza and S. Ducasse. A Categorization of Classes based on the Visualization of their Internal Structure: the Class Blueprint. In OOPSLA ’01: Proceedings of the 16th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, pages 300–311. ACM, 2001. [164] M. Lanza, S. Ducasse, H. Gall, and M. Pinzger. CodeCrawler – An Information Visualization Tool for Program Comprehesion. In ICSE ’05: Proceedings of the 27th International Conference on Software Engineering, pages 672–673. IEEE, 2005. [165] J. Laval, S. Denier, S. Ducasse, and A. Bergel. Identifying Cycle Causes with Enriched Dependency Structural Matrix. In WCRE ’09: Proceedings of the 2009 16th Working Conference on Reverse Engineering, pages 113–122. IEEE Computer Society, 2009. [166] J. K. Lee, S. J. Jung, S. D. Kim, W. H. Jang, and D. H. Ham. Component Identification Method with Coupling and Cohesion. In APSEC ’01: Proceedings of the 8th Asia-Pacific Software Engineering Conference,, pages 79–86. IEEE, 2001. [167] M. M. Lehman. Laws of Software Evolution Revisited. In Software Process Technology, volume 1149 of Lecture Notes in Computer Science, chapter 12, pages 108–124. Springer Berlin / Heidelberg, 1996. [168] L. Li and A. J. Offutt. Algorithmic Analysis of the Impact of Changes on Object-Oriented Software. In ICSM ’96: Proceedings of the International Conference on Software Maintenance, pages 171–184. IEEE, 1996. [169] W. Li and S. Henry. Object-Oriented Metrics that Predict Maintainability. Journal of Systems and Software, 23(2):111–122, 1993. [170] R. Lintern, J. Michaud, M. A. Storey, and X. Wu. Plugging-in Visualization: Experiences Integrating a Visualization Tool with Eclipse. In SOFTVIS ’03: Proceedings of the 2003 ACM Symposium on Software Visualization, pages 47–56. ACM, 2003. [171] M. Lippert and S. Roock. Refactoring in Large Software Projects: Performing Complex Restructurings Successfully. Wiley, 1st edition, 2006. [172] S. Livieri, Y. Higo, M. Matsushita, and K. Inoue. Analysis of the Linux Kernel Evolution Using Code Clone Coverage. In MSR ’07: Proceedings of the 4th International Workshop on Mining Software Repositories, pages 22–25. IEEE Computer Society, 2007. [173] S. Livieri, Y. Higo, M. Matsushita, and K. Inoue. Very-Large Scale Code Clone Analysis and Visualization of Open Source Programs Using Distributed
Bibliography
221
CCFinder: D-CCFinder. In ICSE ’07: Proceedings of the 29th International Conference on Software Engineering, pages 106–115. IEEE Computer Society, 2007. [174] C. V. Lopes and S. K. Bajracharya. An Analysis of Modularity in Aspect Oriented Design. In AOSD ’05: Proceedings of the 4th International Conference on Aspect-Oriented Software Development, pages 15–26. ACM, 2005. [175] A. MacCormack, J. Rusnak, and C. Y. Baldwin. Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code. Management Science, 52(7):1015–1030, 2006. [176] S. Mancoridis, B. S. Mitchell, Y. Chen, and E. R. Gansner. Bunch: A Clustering Tool for the Recovery and Maintenance of Software System Structures. In ICSM ’99: Proceedings of the IEEE International Conference on Software Maintenance, pages 50–59. IEEE Computer Society, 1999. [177] S. Mancoridis, B. S. Mitchell, C. Rorres, Y. Chen, and E. R. Gansner. Using Automatic Clustering to Produce High-Level System Organizations of Source Code. In IWPC ’98: Proceedings of the 6th International Workshop on Program Comprehension, pages 45–52. IEEE Computer Society, 1998. [178] O. Maqbool and H. A. Babri. Hierarchical Clustering for Software Architecture Recovery. IEEE Transactions on Software Engineering, 33(11):759–780, 2007. [179] A. Marcus and J. I. Maletic. Recovering Documentation-to-Source-Code Traceability Links using Latent Semantic Indexing. In ICSE ’03: Proceedings of the 25th International Conference on Software Engineering, pages 125–135. IEEE, 2003. [180] A. Marcus, A. Sergeyev, V. Rajlich, and J. I. Maletic. An Information Retrieval Approach to Concept Location in Source Code. In WCRE ’04: Proceedings of the 11th Working Conference on Reverse Engineering, pages 214–223. IEEE Computer Society, 2004. [181] M. Marin, A. van Deursen, and L. Moonen. Identifying Aspects Using FanIn Analysis. In WCRE ’04: Proceedings of the 11th Working Conference on Reverse Engineering, pages 132–141. IEEE Computer Society, 2004. [182] R. C. Martin. Agile Software Development, Principles, Patterns, and Practices. Prentice Hall, 1st edition, 2002. [183] A. Marx, F. Beck, and S. Diehl. Computer-Aided Extraction of Software Components. In WCRE ’10: Proceedings of the 17th Working Conference on Reverse Engineering, pages 183–192. IEEE, 2010.
222
Bibliography
[184] T. J. McCabe. A Complexity Measure. IEEE Transactions on Software Engineering, SE-2(4):308–320, 1976. [185] F. McGee and J. Dingliana. An Empirical Study on the Impact of Edge Bundling on User Comprehension of Graphs. In AVI ’12: Proceedings of the International Working Conference on Advanced Visual Interfaces, pages 620– 627. ACM, 2012. [186] C. McMillan, N. Hariri, D. Poshyvanyk, J. C. Huang, and B. Mobasher. Recommending Source Code for Use in Rapid Software Prototypes. In ICSE ’12: Proceedings of the 2012 International Conference on Software Engineering, pages 848–858. IEEE Press, 2012. [187] A. Mehra, J. Grundy, and J. Hosking. A Generic Approach to Supporting Diagram Differencing and Merging for Collaborative Design. In ASE ’05: Proceedings of the 20th IEEE/ACM International Conference on Automated Software Engineering, pages 204–213. ACM, 2005. [188] H. Melton and E. Tempero. The CRSS metric for package design quality. In ACSC ’07: Proceedings of the 30th Australasian Conference on Computer Science, pages 201–210. Australian Computer Society, Inc., 2007. [189] A. Melville, M. Graham, and J. Kennedy. Combined vs. Separate Views in Matrix-based Graph Analysis and Comparison. In IV ’11: Proceedings of the 2011 15th International Conference on Information Visualisation, pages 53–58. IEEE Computer Society, 2011. [190] A. Meneely, L. Williams, W. Snipes, and J. Osborne. Predicting Failures with Developer Networks and Social Network Analysis. In SIGSOFT/FSE ’08: Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering, pages 13–23. ACM, 2008. [191] B. Meyer. Object-Oriented Software Construction. Prentice-Hall, 1st edition, 1988. [192] K. Misue. Layout Adjustment and the Mental Map. Journal of Visual Languages & Computing, 6(2):183–210, 1995. [193] B. S. Mitchell. A Heuristic Approach to Solving the Software Clustering Problem. PhD thesis, Drexel University, 2002. [194] A. Mockus and J. D. Herbsleb. Expertise Browser: A Quantitative Approach to Identifying Expertise. In ICSE ’02: Proceedings of the 24th International Conference on Software Engineering, pages 503–512. ACM, 2002. [195] A. Mockus and D. M. Weiss. Globalization by Chunking: A Quantitative Approach. IEEE Software, 18(2):30–37, 2001.
Bibliography
223
[196] J. Moody, D. McFarland, and S. Bender-deMoll. Dynamic Network Visualisation. American Journal of Sociology, 110(4):1206–1241, 2005. [197] C. Mueller, B. Martin, and A. Lumsdaine. A Comparison of Vertex Ordering Algorithms for Large Graph Visualization. In APVIS ’07: Proceedings of the 6th International Asia-Pacific Symposium on Visualization, pages 141–148. IEEE, 2007. [198] C. Mueller, B. Martin, and A. Lumsdaine. Interpreting Large Visual Similarity Matrices. In APVIS ’07: Proceedings of the 6th International Asia-Pacific Symposium on Visualization, pages 149–152. IEEE, 2007. [199] H. A. M¨ uller, M. A. Orgun, S. R. Tilley, and J. S. Uhl. A Reverse Engineering Approach to Subsystem Structure Identification. Journal of Software Maintenance: Research and Practice, 5(4):181–204, 1993. [200] T. Munzner, F. Guimbreti`ere, S. Tasiran, L. Zhang, and Y. Zhou. TreeJuxtaposer: Scalable Tree Comparison using Focus+Context with Guaranteed Visibility. ACM Transactions on Graphics, 22(3):453–462, 2003. [201] C. R. Myers. Software systems as complex networks: structure, function, and evolvability of software collaboration graphs. Physical Review E, 68(4):046116+, 2003. [202] M. N¨ollenburg, M. V¨olker, A. Wolff, and D. Holten. Drawing Binary Tanglegrams: An Experimental Evaluation. In ALENEX ’09: Proceedings of the Workshop on Algorithm Engineering and Experiments, pages 106–119. SIAM, 2009. [203] M. Ogawa and K. L. Ma. code swarm: A Design Study in Organic Software Visualization. IEEE Transactions on Visualization and Computer Graphics, 15(6):1097–1104, 2009. [204] R. Oliveto, M. Gethers, D. Poshyvanyk, and A. De Lucia. On the Equivalence of Information Retrieval Methods for Automated Traceability Link Recovery. In ICPC ’10: Proceedings of the 18th International Conference on Program Comprehension, pages 68–71. IEEE Computer Society, 2010. [205] T. Panas, T. Epperly, D. Quinlan, A. Saebjornsen, and R. Vuduc. Communicating Software Architecture using a Unified Single-View Visualization. In ICECCS ’07: Proceedings of the 12th IEEE International Conference on Engineering Complex Computer Systems, pages 217–228. IEEE Computer Society, 2007. [206] T. Panas, R. Lincke, and W. L¨owe. Online-Configuration of Software Visualizations with Vizz3D. In SOFTVIS ’05: Proceedings of the 2005 ACM Symposium on Software Visualization, pages 173–182. ACM, 2005.
224
Bibliography
[207] D. L. Parnas. Information Distribution Aspects of Design Methodology. In Proceedings of IFIP Congress 71, volume 1, pages 339–344. North-Holland, 1972. [208] D. L. Parnas. On the Criteria to be Used in Decomposing Systems into Modules. Communications of the ACM, 15(12):1053–1058, 1972. [209] D. L. Parnas. The Secret History of Information Hiding. In Software Pioneers, pages 399–409. Springer-Verlag New York, Inc., 2002. [210] C. Patel, A. H. Lhadj, and J. Rilling. Software Clustering Using Dynamic Analysis and Static Dependencies. In CSMR ’09: Proceedings of the 2009 European Conference on Software Maintenance and Reengineering, pages 27– 36. IEEE Computer Society, 2009. [211] M. Pinzger, H. Gall, M. Fischer, and M. Lanza. Visualizing Multiple Evolution Metrics. In SOFTVIS ’05: Proceedings of the 2005 ACM Symposium on Software Visualization, pages 67–75. ACM, 2005. [212] M. Pinzger, K. Grafenhain, P. Knab, and H. C. Gall. A Tool for Visual Understanding of Source Code Dependencies. In ICPC ’08: Proceedings of the 16th IEEE International Conference on Program Comprehension, pages 254–259. IEEE, 2008. [213] D. Poshyvanyk and A. Marcus. The Conceptual Coupling Metrics for ObjectOriented Systems. In ICSM ’06: Proceedings of the 22nd International Conference on Software Maintenance, pages 469–478. IEEE Computer Society, 2006. [214] D. Poshyvanyk, A. Marcus, R. Ferenc, and T. Gyim´othy. Using information retrieval based coupling measures for impact analysis. Empirical Software Engineering, 14(1):5–32, 2009. [215] A. Potanin, J. Noble, M. Frean, and R. Biddle. Scale-Free Geometry in OO Programs. Communications of the ACM, 48(5):99–103, 2005. [216] A. J. Pretorius and J. J. van Wijk. Visual Inspection of Multivariate Graphs. Computer Graphics Forum, 27(3):967–974, 2008. [217] D. Puppin and F. Silvestri. The social network of Java classes. In SAC ’06: Proceedings of the 2006 ACM Symposium on Applied Computing, pages 1409– 1413. ACM, 2006. [218] H. C. Purchase. Which Aesthetic has the Greatest Effect on Human Understanding? In Graph Drawing, Lecture Notes in Computer Science, pages 248–261. Springer-Verlag, 1997.
Bibliography
225
[219] H. C. Purchase, J. A. Allder, and D. A. Carrington. Graph Layout Aesthetics in UML Diagrams: User Preferences. Journal of Graph Algorithms and Applications, 6(3):255–279, 2002. [220] H. C. Purchase, E. Hoggan, and C. G¨org. How Important Is the “Mental Map”? – An Empirical Investigation of a Dynamic Graph Layout Algorithm Graph Drawing. In Graph Drawing, volume 4372 of Lecture Notes in Computer Science, chapter 19, pages 184–195. Springer Berlin / Heidelberg, 2007. [221] H. C. Purchase, M. McGill, L. Colpoys, and D. Carrington. Graph drawing aesthetics and the comprehension of UML class diagrams: an empirical study. In APVIS ’01: Proceedings of the 2001 Asia-Pacific Symposium on Information Visualisation - Volume 9, pages 129–137. Australian Computer Society, Inc., 2001. [222] G. M. Rama. A Desiderata for Refactoring-Based Software Modularity Improvement. In ISEC ’10: Proceedings of the 3rd India Software Engineering Conference, pages 93–102. ACM, 2010. [223] R. Rao and S. K. Card. The Table Lens: Merging graphical and symbolic representations in an interactive focus+context visualization for tabular information. In CHI ’94: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pages 318–322. ACM, 1994. [224] E. M. Reingold and J. S. Tilford. Tidier Drawings of Trees. IEEE Transactions on Software Engineering, 7(2):223–228, 1981. [225] F. Reitz, M. Pohl, and S. Diehl. Focused Animation of Dynamic Compound Graphs. In IV ’09: Proceedings of the 13th International Conference on Information Visualisation, pages 679–684. IEEE Computer Society, 2009. [226] X. Ren, F. Shah, F. Tip, B. G. Ryder, and O. Chesley. Chianti: A Tool for Change Impact Analysis of Java Programs. ACM SIGPLAN Notices, 39(10):432–448, 2004. [227] F. Ricca, M. Di Penta, M. Torchiano, P. Tonella, and M. Ceccato. The Role of Experience and Ability in Comprehension Tasks Supported by UML Stereotypes. In ICSE ’07: Proceedings of the 29th International Conference on Software Engineering, pages 375–384. IEEE Computer Society, 2007. [228] C. K. Roy and J. R. Cordy. A Survey on Software Clone Detection Research. Technical report, Queen’s University at Kingston, 2007. [229] C. Russo dos Santos, P. Gros, P. Abel, D. Loisel, N. Trichaud, and J. P. Paris. Metaphor-Aware 3D Navigation. In INFOVIS ’00: Proceedings of the IEEE Symposium on Information Visualization, pages 155–165. IEEE, 2000.
226
Bibliography
[230] H. Sahraoui, P. Valtchev, I. Konkobo, and S. Shen. Object Identification in Legacy Code as a Grouping Problem. In COMPSAC ’02: Proceedings of the 26th Annual International Computer Software and Applications Conference, pages 689–696. IEEE, 2002. [231] G. Salton and C. Buckley. Term-weighting approaches in automatic text retrieval. Information Processing & Management, 24(5):513–523, 1988. [232] N. Sangal, E. Jordan, V. Sinha, and D. Jackson. Using Dependency Models to Manage Complex Software Architecture. In OOPSLA ’05: Proceedings of the 20th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, pages 167–176. ACM, 2005. [233] S. Sarkar, A. C. Kak, and G. M. Rama. Metrics for Measuring the Quality of Modularization of Large-Scale Object-Oriented Software. IEEE Transactions on Software Engineering, 34(5):700–720, 2008. [234] S. Sarkar, G. M. Rama, and A. C. Kak. API-Based and Information-Theoretic Metrics for Measuring the Quality of Software Modularization. IEEE Transactions on Software Engineering, 33(1):14–32, 2007. [235] A. Sarma, L. Maccherone, P. Wagstrom, and J. Herbsleb. Tesseract: Interactive Visual Exploration of Socio-Technical Relationships in Software Development. In ICSE ’09: Proceedings of the 31st International Conference on Software Engineering, pages 23–33. IEEE Computer Society, 2009. [236] R. W. Schwanke. An Intelligent Tool for Re-Engineering Software Modularity. In ICSE ’91: Proceedings of the 13th International Conference on Software Engineering, pages 83–92. IEEE Computer Society, 1991. [237] E. Selim, Y. Ghanam, C. Burns, T. Seyed, and F. Maurer. A Test-Driven Approach for Extracting Libraries of Reusable Components from Existing Applications. In Agile Processes in Software Engineering and Extreme Programming, volume 77 of Lecture Notes in Business Information Processing, chapter 17, pages 238–252. Springer Berlin Heidelberg, 2011. [238] B. Sharif and J. I. Maletic. An Empirical Study on the Comprehension of Stereotyped UML Class Diagram Layouts. In ICPC ’09: Proceedings of the 17th IEEE International Conference on Program Comprehension, pages 268– 272. IEEE Computer Society, 2009. [239] B. Sharif and J. I. Maletic. The Effect of Layout on the Comprehension of UML Class Diagrams: A Controlled Experiment. In VISSOFT ’09: Proceedings of the 5th IEEE International Workshop on Visualizing Software for Understanding and Analysis, pages 11–18. IEEE, 2009.
Bibliography
227
[240] B. Shneiderman. The Eyes Have It: A Task by Data Type Taxonomy for Information Visualizations. In VL ’96: Proceedings of the 1996 IEEE Symposium on Visual Languages, pages 336–343. IEEE Computer Society, 1996. [241] R. Sindhgatta and K. Pooloth. Identifying Software Decompositions by Applying Transaction Clustering on Source Code. In COMPSAC ’07: Proceedings of the 31st Annual International Computer Software and Applications Conference - Volume 1, pages 317–326. IEEE, 2007. ´ [242] J. Sliwerski, T. Zimmermann, and A. Zeller. When do changes induce fixes? ACM SIGSOFT Software Engineering Notes, 30(4):1–5, 2005. [243] G. Spanoudakis and A. Zisman. Software Traceability: a Roadmap. In Handbook of Software Engineering and Knowledge Engineering, volume 3, pages 395–428. World Scientific Publishing Co, 2005. [244] M. L. Staples and J. M. Bieman. 3-D Visualization of Software Structure. Advances in Computers, 49:95–141, 1999. [245] K. Stein, R. Wegener, and C. Schlieder. Pixel-Oriented Visualization of Change in Social Networks. In ASONAM ’10: Proceedings of the 2010 International Conference on Advances in Social Networks Analysis and Mining, pages 233–240. IEEE Computer Society, 2010. [246] F. Steinbr¨ uckner and C. Lewerentz. Representing Development History in Software Cities. In SOFTVIS ’05: Proceedings of the 2005 ACM Symposium on Software Visualization, pages 193–202. ACM, 2010. [247] W. P. Stevens, G. J. Myers, and L. L. Constantine. Structured Design. IBM Systems Journal, 13(2):115–139, 1974. [248] D. V. Steward. The Design Structure System: A Method for Managing the Design of Complex Systems. IEEE Transactions on Engineering Management, 28(3):71–74, 1981. [249] Storey, K. Wong, F. D. Fracchia, and H. A. Mueller. On Integrating Visualization Techniques for Effective Software Exploration. In INFOVIS ’97: Proceedings of the 1997 IEEE Symposium on Information Visualization, pages 38–45. IEEE Computer Society, 1997. [250] M. A. Storey, C. Best, and J. Michaud. SHriMP Views: An Interactive Environment for Exploring Java Programs. In IWPC ’01: Proceedings ot the 9th International Conference on Program Comprehension, pages 111–112. IEEE Computer Society, 2001.
228
Bibliography
[251] K. Sugiyama, S. Tagawa, and M. Toda. Methods for Visual Understanding of Hierarchical System Structures. IEEE Transactions on Systems, Man, and Cybernetics, 11(2):109–125, 1981. [252] K. J. Sullivan, W. G. Griswold, Y. Cai, and B. Hallen. The Structure and Value of Modularity in Software Design. ACM SIGSOFT Software Engineering Notes, 26(5):99–108, 2001. [253] C. Szyperski and C. Pfister. Workshop on Component-Oriented Programming, Summary, 1997. [254] P. N. Tan, M. Steinbach, and V. Kumar. Introduction to Data Mining. Addison-Wesley Longman Publishing Co., Inc., 1st edition, 2005. [255] P. Tarr, H. Ossher, W. Harrison, and S. M. Sutton. N Degrees of Separation: Multi-Dimensional Separation of Concerns. In ICSE ’99: Proceedings of the 21st International Conference on Software Engineering, pages 107–119. ACM, 1999. [256] A. Telea and D. Auber. Code Flows: Visualizing Structural Evolution of Source Code. Computer Graphics Forum, 27(3):831–838, 2008. [257] A. Telea, H. Hoogendorp, O. Ersoy, and D. Reniers. Extraction and Visualization of Call Dependencies for Large C/C++ Code Bases: A Comparative Study. In VISSOFT ’09: Proceedings of the 5th IEEE International Workshop on Visualizing Software for Understanding and Analysis, pages 81–88. IEEE, 2009. [258] A. Telea and L. Voinea. An Interactive Reverse Engineering Environment for Large-Scale C++ Code. In SOFTVIS ’08: Proceedings of the 4th International Symposium on Software Visualization, pages 67–76. ACM, 2008. [259] A. Telea and L. Voinea. Case Study: Visual Analytics in Software Product Assessments. In VISSOFT ’09: Proceedings of the 5th IEEE International Workshop on Visualizing Software for Understanding and Analysis, pages 65– 72. IEEE, 2009. [260] A. Telea, L. Voinea, and H. Sassenburg. Visual Tools for Software Architecture Understanding: A Stakeholder Perspective. IEEE Software, 27(6):46–53, 2010. [261] M. Termeer, C. F. J. Lange, A. Telea, and M. R. V. Chaudron. Visual Exploration of Combined Architectural and Metric Information. In VISSOFT ’05: Proceedings of the 3rd International Workshop on Visualizing Software for Understanding and Analysis, pages 1–6. IEEE, 2005.
Bibliography
229
[262] A. R. Teyseyre and M. R. Campo. An Overview of 3D Software Visualization. IEEE Transactions on Visualization and Computer Graphics, 15(1):87–105, 2009. [263] F. Tip, P. F. Sweeney, and C. Laffra. Extracting library-based Java applications. Communications of the ACM, 46(8):35–40, 2003. [264] P. Tonella and M. Ceccato. Aspect Mining through the Formal Concept Analysis of Execution Traces. In WCRE ’04: Proceedings of the 11th Working Conference on Reverse Engineering, pages 112–121. IEEE, 2004. [265] Y. Tu and H. W. Shen. Visualizing Changes of Hierarchical Data using Treemaps. IEEE Transactions on Visualization and Computer Graphics, 13(6):1286–1293, 2007. [266] P. van de Laar. On the Transfer of Evolutionary Couplings to Industry. In MSR ’09: Proceedings of the 6th International Workshop on Mining Software Repositories, pages 187–190. IEEE Computer Society, 2009. [267] F. van Ham. Using Multilevel Call Matrices in Large Software Projects. In INFOVIS ’03: Proceedings of the IEEE Symposium on Information Visualization, pages 227–232. IEEE, 2003. [268] A. Vanya, L. Hofland, S. Klusener, P. van de Laar, and H. van Vliet. Assessing Software Archives with Evolutionary Clusters. In ICPC ’08: Proceedings of the 16th IEEE International Conference on Program Comprehension, pages 192–201. IEEE Computer Society, 2008. [269] L. Voinea and A. Telea. CVSgrab: Mining the history of large software projects. In EuroVis ’06: Proceedings of the Joint Eurographics - IEEE VGTC Symposium on Visualization, pages 187–194. Eurographics Association, 2006. [270] T. von Landesberger, M. G¨orner, R. Rehner, and T. Schreck. A System for Interactive Visual Analysis of Large Graphs Using Motifs in Graph Editing and Aggregation. In M. A. Magnor, B. Rosenhahn, H. Theisel, M. A. Magnor, B. Rosenhahn, and H. Theisel, editors, VMV ’09: Proceedings of Vision Modeling Visualization Workshop, pages 331–340. DNB, 2009. [271] T. von Landesberger, A. Kuijper, T. Schreck, J. Kohlhammer, J. J. van Wijk, J. D. Fekete, and D. W. Fellner. Visual Analysis of Large Graphs: State-of-theArt and Future Research Challenges. Computer Graphics Forum, 30(8):1719– 1749, 2011. [272] C. Ware. Information Visualization, Second Edition: Perception for Design (Interactive Technologies). Morgan Kaufmann, 2 edition, 2004.
230
Bibliography
[273] H. Washizaki and Y. Fukazawa. Automated Extract Component Refactoring. In Extreme Programming and Agile Processes in Software Engineering, volume 2675 of Lecture Notes in Computer Science, chapter 42, page 1016. Springer Berlin / Heidelberg, 2003. [274] H. Washizaki and Y. Fukazawa. Component-Extraction-Based Search System for Object-Oriented Programs. In Software Reuse: Methods, Techniques and Tools, pages 254–263. Springer, 2004. [275] P. Weißgerber. Automatic Refactoring Detection in Version Archives. PhD thesis, Univerisity of Trier, 2009. [276] P. Weißgerber and S. Diehl. Identifying Refactorings from Source-Code Changes. In ASE ’06: Proceedings of the 21st IEEE/ACM International Conference on Automated Software Engineering, pages 231–240. IEEE Computer Society, 2006. [277] P. Weißgerber, L. von Klenze, M. Burch, and S. Diehl. Exploring evolutionary coupling in Eclipse. In ECLIPSE ’05: Proceedings of the 2005 OOPSLA Workshop on Eclipse Technology Exchange, pages 31–34. ACM, 2005. [278] Z. Wen and V. Tzerpos. An effectiveness measure for software clustering algorithms. In IWPC ’04: Proceedings of the 12th International Workshop on Program Comprehension, pages 194–203. IEEE Computer Society, 2004. [279] Z. Wen and V. Tzerpos. Software Clustering based on Omnipresent Object Detection. In IWPC ’05: Proceedings of the 13th International Workshop on Program Comprehension, pages 269–278. IEEE Computer Society, 2005. [280] M. Wermelinger, Y. Yu, A. Lozano, and A. Capiluppi. Assessing architectural evolution: a case study. Empirical Software Engineering, 16(5):1–44, 2011. [281] R. Wettel. Software Systems as Cities. PhD thesis, University of Lugano, Switzerland, 2010. [282] R. Wettel, M. Lanza, and R. Robbes. Software Systems as Cities: A Controlled Experiment. In ICSE ’11: Proceedings of the 32rd ACM/IEEE International Conference on Software Engineering, pages 551–560. ACM, 2011. [283] A. Wierda, E. Dortmans, and L. L. Somers. Using Version Information in Architectural Clustering – A Case Study. In CSMR ’06: Proceedings of the Conference on Software Maintenance and Reengineering, pages 214–228. IEEE Computer Society, 2006.
Bibliography
231
[284] M. Wilhelm and S. Diehl. Dependency Viewer – A Tool for Visualizing Package Design Quality Metrics. In VISSOFT ’05: Proceedings of the 3rd IEEE International Workshop on Visualizing Software for Understanding and Analysis, pages 34–37. IEEE Computer Society, 2005. [285] L. Wilkinson and M. Friendly. The History of the Cluster Heat Map. The American Statistician, 63(2):179–184, 2009. [286] K. Wittenburg and E. Sigman. Visual Focusing and Transition Techniques in a Treeviewer for Web Information Access. In VL ’97: Proceedings of the 1997 IEEE Symposium on Visual Languages, pages 20–27. IEEE Computer Society, 1997. [287] K. Wong and D. Sun. On evaluating the layout of UML diagrams for program comprehension. Software Quality Journal, 14(3):233–259, 2006. [288] S. Wong and Y. Cai. Predicting change impact from logical models. In ICSM ’09: Proceedings of the International Conference on Software Maintenance, pages 467–470. IEEE Computer Society, 2009. [289] J. Wu, A. E. Hassan, and R. C. Holt. Comparison of Clustering Algorithms in the Context of Software Evolution. In ICSM ’05: Proceedings of the 21st IEEE International Conference on Software Maintenance, pages 525–535. IEEE Computer Society, 2005. [290] X. Wu, A. Murray, M. A. Storey, and R. Lintern. A Reverse Engineering Approach to Support Software Maintenance: Version Control Knowledge Extraction. In WCRE ’04: Proceedings of the 11th Working Conference on Reverse Engineering, pages 90–99. IEEE, 2005. [291] C. Xiao and V. Tzerpos. Software Clustering Based on Dynamic Dependencies. In CSMR ’05: Proceedings of the 9th European Conference on Software Maintenance and Reengineering, pages 124–133. IEEE Computer Society, 2005. [292] T. Yamamoto, M. Matsushita, T. Kamiya, and K. Inoue. Measuring Similarity of Large Software Systems Based on Source Code Correspondence. In Product Focused Software Process Improvement, volume 3547 of Lecture Notes in Computer Science, pages 530–544. Springer, 2005. [293] J. S. Yi, N. Elmqvist, and S. Lee. TimeMatrix: Analyzing Temporal Social Networks Using Interactive Matrix-Based Visualizations. International Journal of Human-Computer Interaction, 26(11):1031–1051, 2010. [294] A. T. T. Ying, G. C. Murphy, R. Ng, and M. C. Chu-Carroll. Predicting source code changes by mining change history. IEEE Transactions on Software Engineering, 30(9):574–586, 2004.
232
Bibliography
[295] S. Yusuf, H. Kagdi, and J. I. Maletic. Assessing the Comprehension of UML Class Diagrams via Eye Tracking. In ICPC ’07: Proceedings of the 15th IEEE International Conference on Program Comprehension, pages 113–122. IEEE Computer Society, 2007. [296] W. N. W. Zainon and P. Calder. Visualising Phylogenetic Trees. In AUIC ’06: Proceedings of the 7th Australasian User Interface Conference, pages 145–152. Australian Computer Society, Inc., 2006. [297] L. Zaman, A. Kalra, and W. Stuerzlinger. DARLS: Differencing and Merging Diagrams Using Dual View, Animation, Re-Layout, Layers and a Storyboard. In CHI EA ’11: CHI ’11 Extended Abstracts on Human Factors in Computing Systems, pages 1657–1662. ACM, 2011. [298] M. S. Zanetti and F. Schweitzer. A Network Perspective on Software Modularity. In ARCS Workshops, pages 1–8. IEEE, 2012. [299] D. Zeckzer. Visualizing Software Entities Using a Matrix Layout. In SOFTVIS ’10: Proceedings of the 5th International Symposium on Software Visualization, pages 207–208. ACM, 2010. [300] Y. Zhou, M. W¨ ursch, E. Giger, H. C. Gall, and J. L¨ u. A Bayesian Network Based Approach for Change Coupling Prediction. In WCRE ’08: Proceedings of the 15th Working Conference on Reverse Engineering, pages 27–36. IEEE Computer Society, 2008. [301] T. Zimmermann, S. Diehl, and A. Zeller. How History Justifies System Architecture (or not). In IWPSE ’03: Proceedings of the 6th International Workshop on Principles of Software Evolution, pages 73–83. IEEE Computer Society, 2003. [302] T. Zimmermann and P. Weißgerber. Preprocessing CVS Data For FineGrained Analysis. In MSR ’04: Proceedings of the 1st International Workshop on Mining Software Repositories, pages 2–6. IEEE Computer Society, 2004. [303] T. Zimmermann, A. Zeller, P. Weissgerber, and S. Diehl. Mining Version Histories to Guide Software Changes. IEEE Transactions on Software Engineering, 31(6):429–445, 2005.
Zusammenfassung
Ein Software-System besteht in der Regel aus Hunderten, wenn nicht Tausenden Dateien, die nicht unabh¨angig, sondern im Gegenteil, vielfach miteinander verbunden sind. W¨ahrend strukturelle Abh¨angigkeiten wie Methodenaufrufe oder Datenzugriffe offensichtlich eine Form der Kopplung darstellen, so existieren auch indirektere Arten der Kopplung, die ebenso bei der weiteren Entwicklung der Software ber¨ ucksichtigt werden sollten. Beispielsweise ist es wahrscheinlich, dass Dateien, die in der Vergangenheit gemeinsam ge¨andert wurden, auch in der Zukunft gemeinsam editiert werden sollten – ganz unabh¨angig von einer m¨oglichen strukturellen Kopplung. Auch kopierter Quelltext macht h¨aufig eine gemeinsame, konsistente Weiterentwicklung nicht strukturell abh¨angiger Programmteile n¨otig. Besonderheit dieser Dissertation ist, dass Kopplung nicht als eindimensionales sondern als mehrdimensionales Konstrukt verstanden wird: Kopplung wird auf eine Vielzahl von Kopplungsmetriken abgebildet. Solch mehrdimensionale Kopplung besser zu verstehen ist das u ¨bergeordnete Ziel der Arbeit, welches durch unterschiedliche Ans¨atze verfolgt wird. Visueller Vergleich von Kopplungsmetriken: Als erster Schritt steht die Untersuchung der verschiedenen Kopplungsmetriken eines Software-Systems mit visuellen Mitteln im Vordergrund. W¨ahrend sich zwar große Graphen, wie sie durch gekoppelte Teile eines Software-Systems gebildet werden, mit bisherigen Ans¨atzen darstellen lassen, erfordert der skalierbare visuelle Vergleich von Kopplungsmetriken neue Visualisierungstechniken. In dieser Arbeit werden zwei neuartige Ans¨atze mit unterschiedlicher Zielsetzung vorgestellt: Der erste Ansatz verwendet eine klassische Knoten-Kanten-Darstellung und ordnet eine Reihe von Diagrammen, die jeweils eine andere Kopplungsmetrik visualisieren, nebeneinander an; ein besonderes Layout macht den Ansatz skalierbar und zus¨atzliche Interaktionsm¨oglichkeiten unterst¨ utzen den Benutzer beim Vergleich der Metriken. Der zweite Ansatz basiert dagegen auf einer Adjazenzmatrixdarstellung von Graphen und unterst¨ utzt neben einem Vergleich
233
234
Bibliography
von Kopplungsmetriken auch den Vergleich unterschiedlicher Modularisierungen eines Software-Systems, wie sie beispielsweise durch Clustering erzeugt werden. Die Anwendungsm¨oglichkeiten dieser Visualisierungen werden in Fallund Benutzerstudien untersucht. Kongruenz von Kopplung und Modularisierung: Kopplungsmetriken spielen eine große Rolle f¨ ur die Weiterentwicklung einer Software und sind damit eng verbunden mit deren Design, welches sich in erster Linie in der Modularisierung des Systems ¨außert. In einer empirischen Analyse von 16 OpenSource-Projekten wird der Zusammenhang verschiedener Kopplungsmetriken mit den Modularisierungen der Projekte untersucht. Unterschiede zeigen sich dabei, inwieweit bestehende Kopplungen mit der Unterteilung der Systeme u ¨bereinstimmen, sprich kongruent sind. Da sich zwischen einigen Kopplungsmetriken und existierenden Empfehlungen zur Modularisierung von SoftwareSystemen gewisse Zusammenh¨ange herleiten lassen, erlauben diese Ergebnisse auch R¨ uckschl¨ usse auf die Einhaltung und Umsetzung dieser Empfehlungen: insbesondere die Prinzipien low coupling and high cohesion und information hiding scheinen einen besonderen Einfluss auf das Design der untersuchten Systeme zu haben. Gr¨oßere Unterschiede im Design bestimmter Arten von Modulen zeigen sich u ¨berarschenderweise nicht. Komponentenextraktion: Kopplungsmetriken k¨onnen nicht nur passiv zur Untersuchung, sondern auch aktiv zur Verbesserung der Modularisierung eines Software-Systems eingesetzt werden. W¨ahrend das klassische Clustering eines Systems, wie es im Rahmen einer Machbarkeitsstudie auch in dieser Arbeit verwendet wird, einigen Einschr¨ankungen unterliegt, wird hier ein neues Verfahren vorgeschlagen, dass auf die Extraktion einzelner Komponenten des Systems zur unabh¨angigen Weiterentwicklung abzielt: In einem interaktiven Ansatz werden zun¨achst zentrale Klassen und Interfaces des Systems vom Benutzer als Startpunkte der Extraktion identifiziert. Dann kann, basierend auf existierenden Kopplungen, algorithmisch eine passende Komponente f¨ ur die Extraktion vorgeschlagen werden. Eine durchdachte Benutzerschnittstelle erlaubt es dabei skalierbar, die Kopplungen zwischen den Komponenten zu untersuchen, die Komponentenzuordnung interaktiv zu editieren sowie den Algorithmus iterativ anzuwenden. Eine Simulation des Ansatzes auf Open-Source-Projekten zeigt die unterschiedliche Eignung der verschiedenen Kopplungsmetriken f¨ ur diesen Einsatzzweck sowie die Schwierigkeit durch Kombination von verschiedenen Metriken das Verfahren zu verbessern. Neben konkreten Beobachtungen zum Auftreten von Kopplungsmetriken und deren Zusammenhang zur Modularisierung stellt diese Arbeit also verschiedene Werkzeuge zum Vergleich von Kopplungsmetriken zur Verf¨ ugung – seien es Visualisierungen oder empirische Methoden. In dieser Form, ist sie eine der ersten Arbeiten, die sich der systematischen Untersuchung einer Vielzahl von Kopplungsmetriken ausf¨ uhrlich widmet.
