From an abstract point of view, software systems can be considered as a set of entities connected by dependencies or code couplings such as method calls. We might also consider that entities inherit or aggregate, that they are changed together, that they are covered by the same code clone, etc. Since code couplings can be modeled as a graph consisting of vertices and edges, graph visualization provides the right tools for depicting this kind of information. 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. survey graph visualizations that are particularly applicable to large graphs:
Von Landesberger, Tatiana, et al. “Visual Analysis of Large Graphs: State‐of‐the‐Art and Future Research Challenges.” Computer graphics forum. Vol. 30. No. 6. Blackwell Publishing Ltd, 2011.
Simple Node-Link Diagrams
Most of the approaches that visualize code couplings are based on node-link diagrams where the code entities are represented by node connected through lines (i.e., links). 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 and a set of aesthetic criteria conceptualize the readability of node-link layouts: 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. 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 such as a package or directory structure; in other scenarios or if required, a hierarchy can be created by applying hierarchical graph clustering. When visualizing large graphs, the hierarchy can be used for structuring the nodes or for increasing the level of abstraction: hierarchy nodes aggregate sets of graph nodes and thereby reduce complexity.
The following tools have integrated a simple node-link visualization of code couplings, among many other features.
- NDepend—Visual Studio plugin (commercial)
- SciTools Understand—source code analysis tool (commercial)
- Microsoft Visual Studio—IDE (commercial)
A quite established standard for modeling and depicting object-oriented systems is the Unified Modeling Language (UML). This visual language defines a set 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 above 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.
Wikipedia maintains an extensive list of UML tools.
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/Creole 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, DA4Java 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 edge bundling as used in SolidSX.
It is further possible to visualize software metrics along with the graph structure. E-Quality combines the visualization of different software metrics by shape and color and other attributes with the visualization of different concepts of coupling: it discerns seven concepts of static structural coupling by color, indicates direction with arrow heads, uses thickness as an indicator of frequency, and discerns 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, Class Blueprints divide the fields and methods of each class into five categories, visualized in columns as parts of rectangular class representations. Links connect related fields and methods, within classes as well as between classes.
- SHriMP/Creole—Eclipse plugin for Java (free)
- DA4Java—Eclipse plugin for Java (non-commercial use)
- SolidSX—standalone tool for multiple environments (commercial)
- Structure 101—standalone tool for multiple environments (commercial)
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 below, 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.
Some approaches exploit the map metaphor further and describe the software system as a city. Applying this metaphor, following more or less a real-world model, promises a more efficient code exploration. The map itself, however, just visualizes the structure of the system, for instance, the package structure. Software cities are often used for visualizing (non-relational) software metrics and their evolution such as in Software Cities and Landscapes or CodeCity. Drawing links onto a map, 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. When considering a non-filtered coupling graph, the coupling information often is not sparse anymore. Again, edge bundling 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.
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. In the IDE prototype Code Bubbles and the visual debugging tool Debugger Canvas, the editor views are connected themselves by links indicating method calls. Code Canvas 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.