Author: Prof. Dr. Rainer Koschke, University of Bremen, Axivion GmbH<\/p>\n
While a mechanical engineer can physically examine their work and see, feel, smell, and hear it, software eludes the sensory perception of its developers because it is intangible. Nevertheless, we must understand its often complex internal structure and the interaction of its components. Reading the source code becomes impossible beyond a certain point. We need a more abstract presentation of the information. Software visualization is the science of graphically representing information about software. It is far more than simply generating pixels. Interaction through filtering, searching, and querying the displayed data is an integral part. It is also closely linked to the analysis of software for data extraction. In so-called visual analytics, it helps to complement automated data analysis with the human ability to visually grasp patterns and trends at a glance.<\/strong><\/p>\n This article describes techniques, methods, and tools for software visualization. It examines the current state of the art, presents current research trends, and offers a glimpse into the future. The following aspects are addressed\u2014always considering both the current state of technology and the state of research: What is software visualization? What is visual analytics? What is visualized and for what purpose? What types of visualizations and forms of interaction exist? How should the characteristics of human perception be considered? What role do metaphors play? How can I implement my own software visualization?<\/p>\n For many maintenance problems, it's not possible to formulate a precise question in advance or to specify an algorithm that can provide a precise answer to the question. For many<\/p>\n Maintenance problems, on the other hand, require a more exploratory approach. Even with precise questions and algorithms, the sheer volume of results can still be overwhelming. Visualizations that aid the human observer are particularly useful for exploratory approaches and the analysis of large datasets.<\/p>\n Price, Baecker and Small describe software visualization as follows:<\/p>\n \u201cSoftware Visualization is the use of the crafts of typography, graphic design, animation, and cinematography with modern human-computer interaction and computer graphics technology to facilitate both the human understanding and effective use of computer software.<\/em><\/p>\n Program visualization is the visualization of the actual program code or data structures in either static or dynamic form.\u201d<\/em><\/p>\n The need for software visualization is highlighted by Thomas Ball:<\/p>\n \u201c"Software is intangible, having no physical shape or size. Software visualization tools use graphical techniques to make software visible by displaying programs, program artifacts and program behavior."\u201d<\/em><\/p>\n Software visualization is a specialized area of general information visualization. Information visualization deals with presenting information in a way that makes it more accessible to human viewers. Many insights from this field can be specifically applied to software visualization. Nevertheless, it is necessary to consider the specific characteristics of the object being visualized\u2014in this case, software. Software is intangible, as already mentioned. Therefore, there is no natural form of representation. Software has both structure and behavior, and both should be visualizable. Software is multi-layered, complex, and detailed. Graphical representations must be linked to textual representations because most programming languages are text-based, and ultimately, it is the program code that contains the full details, which visualization aims to abstract. The changes must be made in the source code. Visualization is a means to achieve this efficiently and effectively.<\/p>\n Software visualization presents information about software. This includes both static and dynamic aspects. Static information is information that can be obtained directly by analyzing documents without having to run the program. These documents include not only the source code, but also descriptions of the architecture and test cases, as well as the documentation. Metrics regarding the size and complexity of functions, for example, are classic data obtained through static analysis. Dynamic analyses determine their results by executing the program. Examples include memory consumption, runtimes, or specific values that a program returns for a given input.<\/p>\n The goal of software visualization is to reduce complexity for the user, offer different perspectives, and support human inference. This presents several challenges. First, a visualization must scale, as maintenance typically involves very large programs. What looks good for a small program is not necessarily applicable to very large ones. Second, a suitable form of visualization must be found that captures all aspects relevant to a problem and abstracts away all irrelevant ones. The quality of a software visualization is therefore fundamentally dependent on the specific task the developer is pursuing. Whether detailed information or broad overviews are needed determines which type of software visualization is appropriate. From the many possible visualizations, the most suitable ones for the respective task must then be selected. Having an overview of visualizations is helpful in this regard. This article provides such an overview.<\/p>\n Software visualization is related to so-called software analytics.\u00a0Software Analytics<\/em>\u00a0is the science of discovering and communicating meaningful patterns in software data. It uses methods from statistics, data mining techniques, and machine learning.<\/p>\n Learning and visualization. Software visualization provides support in this regard. However, software analytics goes further by applying methods that acquire data and identify relationships and patterns.\u00a0Visual Analytics<\/em>\u00a0Visual analytics, which focuses on data about software and its development process, can be considered a subfield of software analytics. Like software analytics, the goal of visual analytics is to gain insights from large and complex datasets. However, it doesn't just employ classic statistical methods, data mining techniques, and machine learning. This approach also combines these automated data analysis techniques with the human ability to quickly and visually recognize patterns or trends. Data is visually explored by the human observer to gain insights. Visualization therefore plays a central role and is not merely used to present the final results, as in classic software analytics.<\/p>\n Software visualizations must operate with limited resources. These resources are determined by tools and hardware, such as the resolution and size of the display area. Human cognitive abilities also have their limits, which software visualization cannot overcome. Human perceptual abilities, such as visual acuity and color vision, must be taken into account\u2014just as with any other interaction design in human-machine communication. However, software visualization is potentially even more challenging than visualizing other things because, unlike other domains in software development, there are fewer conventions for visualizations, such as how to interpret colors and symbols. Furthermore, in the software maintenance of existing programs, we are dealing with a particularly extensive and complex information space.<\/p>\n Visual perception is governed by certain cognitive principles that are firmly anchored in our brains. Cognitive psychology deals with these principles in general. Gestalt psychology, for example, has identified organizing principles in the perception of static, two-dimensional images in particular. These include the law of proximity, according to which elements located close to each other are perceived as belonging together, and the law of similarity, according to which similar elements are more likely to be experienced as belonging together than dissimilar ones. Many visual impressions never even reach conscious awareness or are processed beforehand. So-called pre-attentive perception is a preconscious, subliminal perception of sensory stimuli. A stimulus is perceived by a person's nervous system and triggers an effect there, but it does not penetrate into conscious awareness. On the one hand, this accelerates perception because these processes occur in parallel and automatically; however, it can also lead to important information being filtered out, and consciousness not experiencing "the whole truth.".<\/p>\n In the context of changing visual sensory impressions, so-called change blindness poses another risk of incompleteness and visual fallacies. Change blindness describes a phenomenon of visual perception in which changes in a visual scene go unnoticed by the viewer, even though the changes are significant. In a classic experiment where viewers are tasked with counting how many times a group of people throw a ball to each other, a person dressed as a gorilla walks through the scene. Most viewers fail to notice this gorilla, even though it is clearly visible. They are too preoccupied with their task. Their focus on the assigned task simultaneously narrows their sensory perception. A similar phenomenon is inattentional blindness. This is the failure to perceive changes in objects that are not the focus of attention. If marginal and insignificant changes are made to two images of the same scene, the viewer will not notice them due to the limited processing capacity of the human brain.<\/p>\n Anyone using visualizations to exploit the human ability to quickly recognize patterns must be aware that the human brain first needs to select which information is relevant and which is less so. A visualization must succeed in directing human attention to relevant facts so that these can be consciously perceived.<\/p>\n Graphs<\/strong>\u00a0UML diagrams are a widely used form of visualization in maintenance. They are naturally suited for representing dependencies between software components and other binary relationships. Most UML diagram types, such as class diagrams or collaboration diagrams, are ultimately graphs. An example of a class diagram visualization is shown in Figure 1 (see below).\u00a0PDF<\/a>) shown.<\/p>\n The UML diagram itself is located in the upper right corner. Alternative views are displayed around it. Source code is shown below the diagram. The visualization has several important features. For example, it presents different views, both abstract and detailed. In software visualizations, it is generally necessary to establish a link between the visualization and the source code, as is done in this representation. To the left of the UML diagram, you see a representation of the hierarchy. This is also typical because large systems are hierarchically structured. Below the hierarchy, you will find a display of the attributes of a selected element of the UML diagram. Details can be queried here.<\/p>\n This visualization supports the approach proposed by Shneiderman, which every visualization should strive for (the so-called "mantra of information visualization"): First, an overview should be provided. Then, information can be searched and filtered. Finally, details are available upon request.<\/p>\n UML tools can represent object-oriented concepts using UML's graphical means. However, what cannot be expressed through UML concepts cannot be visualized with them. Furthermore, the perspectives from which the software is displayed are predefined and usually cannot be freely defined or extended by the user.<\/p>\n For these reasons, it is desirable to provide more generic representation options, that is, to allow users to define alternative visual languages themselves. Generic graph representations and extension options are offered, for example, by Rigi, a graph editor developed by Hausi M\u00fcller in the 1990s. Rigi was designed for visualizing software using typed graphs and is one of the earliest tools of its kind, significantly influencing many others. While no longer under development, it inspired the development of many subsequent tools.<\/p>\n A representation of a dependency graph with Rigi is shown in Figure 2 (see below).\u00a0PDF<\/a>) shown. It illustrates the relationships between functions and data types. The types of the nodes are distinguished by different icons and colors. The color of the edges expresses their semantics; for example, function calls and the use of data types in the function signature are differentiated by color.<\/p>\n The graphs that Rigi can process are generic. This means that a user of Rigi can define the types of nodes and edges and freely specify attributes. Generic filters and<\/p>\n Navigation options are available to the end user. For extensibility, Rigi offers a scripting interface that can query and manipulate the graph. This allows users to create their own views. The graphical editor is therefore programmable.<\/p>\n The graphs in Rigi are hierarchical. This means that a node can contain other nodes. Nodes can be merged either interactively by the user or programmatically via the scripting interface. In this way, large, complex graphs can be grouped together. The grouping criteria are application-specific and provided by the user. Research on so-called software clustering deals with the automated grouping of software units. Figure 3 (see below).\u00a0PDF<\/a>Figure 1 shows the result of such automated clustering. Here, the functions were grouped into abstract data types based on the data types that appear in their signature.<\/p>\n An alternative to graphs for representing binary relations are\u00a0Adjacency matrices<\/strong>. A call graph can, for example, look like the one in Figure 4 (see Figure 4).\u00a0PDF<\/a>The graph is shown in the diagram. All functions are listed on the two axes. A point is placed on the coordinate when the function on the x-axis calls another function on the y-axis. Recursive calls are thus represented as a point on the diagonal. The point can be colored to display additional information, such as the frequency of a call.<\/p>\n The advantages of this representation are its simplicity and scalability in terms of the computational effort required for its rendering. Automatically laying out large, dense call graphs is very computationally intensive, whereas an adjacency matrix can be rendered quickly. Adjacency matrices also offer greater clarity than densely populated graphs. However, their disadvantage is that paths are not readily apparent. Graphs are clearly superior in this respect. Furthermore, scalability is limited for graphs with a very large number of nodes in terms of efficient use of available space. Graphs are often sparsely populated, resulting in inefficient space utilization. Long X and Y axes necessitate scroll bars or other forms of interaction, meaning that not everything is always visible at a glance.<\/p>\n When it comes to sequences (for example, in the results of dynamic analyses), one can\u00a0Sequence diagrams<\/strong>\u00a0use elements that are also part of UML. JInsight offers an extension of UML sequence diagrams using colors and other features. Each vertical stripe represents an object (see Figure 5, p. 1).\u00a0PDF<\/a>The color of the stripe encodes the class to which the object belongs. Time progresses from top to bottom, as is typical for sequence diagrams. Calls are represented by edges between objects and have the called method as a label. The time periods in which an object is actually active (i.e., not just calling another method but actually performing calculations itself) are shown in a slightly lighter shade within the stripe.<\/p>\n Sequence diagrams, which depict the actual processes obtained through dynamic analysis of a realistic program, are very long. Subsequences often repeat themselves, for example, if they are executed in a loop within the program. If a long-running program were displayed in this way, one would have to scroll through the sequence with a bar for a very long time. JInsight therefore allows recurring call patterns to be automatically detected and displayed. Similar but slightly different patterns can be overlaid to highlight the differences. This again demonstrates the importance of preprocessing steps in the form of automated analysis to make a diagram readable and useful.<\/p>\n When it comes to visualizing metrics, one can draw on a large set of classic visualizations. These include\u00a0Pie charts<\/strong>,\u00a0Function graphs<\/strong>,\u00a0Box plots<\/strong>,\u00a0Bar charts<\/strong>\u00a0and many others. It is important that the visualization allows for easy correlation of the displayed metrics with other visualizations of the software. As we saw with the example of the UML tool shown at the beginning, software is usually represented by different views of varying levels of abstraction. Figure 6 (see below).\u00a0PDF<\/a>The left side of the diagram shows a call graph. On the right side, we see several coordinate systems. Each function in the call graph is represented as a point in each coordinate system. The coordinate systems describe different metrics relating to various aspects of the software. These include, for example, static code metrics such as the number of comments or conditions, dynamic metrics such as test coverage or runtime, and also metrics relating to aspects of the development process, such as the frequency of changes to the functions or the number of different developers who have modified the functions.<\/p>\n The relationship between the coordinate systems and the call graph is established by selecting the points. If a function is selected in the call graph, the corresponding point is highlighted in color in all coordinate systems, and vice versa.<\/p>\n When it comes to representing hierarchies whose sheets are associated with metrics, one can refer to the so-called\u00a0Tree maps<\/strong>\u00a0This tool projects a tree structure onto a plane. The area occupied by a leaf is proportional to its metric value. To simultaneously represent the hierarchy, all successors within a subtree are spatially nested. The hierarchy boundaries are framed.<\/p>\n Figure 7 (see.\u00a0PDF<\/a>This helps to explain the procedure. First, one starts with a square area onto which the tree is to be projected. Then, the metric values are aggregated by summing them from the leaves to the predecessors in the tree. Node X then has the value 99, node Z the value 50, node Y the value 100, and finally the root W the value 199. The areas are now distributed proportionally to the successors in the tree, starting from the root. The two nodes X and Y have almost the same share: 99\/199 and 100\/199, respectively. These values are recursively distributed to the successors. Nodes a, b, and c each receive the same share that was assigned to their common predecessor X, namely one-third of 99\/199. Nodes Z and d each receive half of 100\/199. For the successors of Z, this share is halved again.<\/p>\n To clearly illustrate the tree's nesting structure, the areas are distributed alternately vertically and then horizontally along the tree's depth. This ultimately results in the area shown to the right of the tree in Figure 7 (see below).\u00a0PDF<\/a>) is shown.<\/p>\n A more realistic example is shown in Figure 8 (see below).\u00a0PDF<\/a>The tree map illustrates redundancies in the form of duplicated code within a very large, real-world program developed in an industrial company. Its structure reflects the source code files and their organization within the directory structure. The areas are proportional to the relative size of the files, measured in lines of code.<\/p>\n The degree of redundancy is represented by the red coloring; the more redundant a file is, the darker the red area. The blue area is the file currently selected by the user. All other parts that have redundancies with the selected file are colored green. Edges connect the green parts to the selected blue area. The shade of green, from light to dark, indicates the degree of redundancy\u2014with the blue area or any other area\u2014just as it does with unconnected areas. The number of related code segments copied specifically between the green files and the selected, blue file is shown by the numbers in the green areas. This image clearly shows that there are large files with a very high degree of redundancy and that, in the case of the currently selected file, the redundancy is not local, but rather involves shared code segments across widely separated files.<\/p>\n The advantage of tree maps is that they represent both proportional metrics and the hierarchy simultaneously. This requires that the metrics from the leaves to the inner nodes can be aggregated as a sum. All available space is used efficiently. The space itself can be predefined at the outset, preventing information from wandering out of view. Scaling is limited only by the resolution of the display and the viewer's ability to distinguish individual points. Naturally, this representation also easily supports zooming in and out.<\/p>\n However, one needs to spend some time studying this visualization before fully understanding all its aspects. Distinguishing the hierarchy in deeply nested trees, in particular, quickly becomes difficult. Furthermore, the metrics are limited to the leaves.<\/p>\n We were introduced to tree maps as an initial way to combine the visualization of graphs and metrics. However, they could only represent trees, not general graphs. Binary relationships can only be represented by displaying edges, as shown in the example in Figure 8. There, however, the edges are only displayed for the currently selected file. If all edges were displayed simultaneously, the nodes would be barely visible.<\/p>\n A more general visualization of metrics and relations at the same time is\u00a0polymetric views<\/strong>. Polymetric views represent binary relations in the form of graphs. In mathematics, graphs are simply nodes and edges. However, as soon as they are drawn (compare Figure 9, p. 1), they become...\u00a0PDF<\/a>They are given a representation, that is, an extent, shape, and color, as well as a location where they are drawn. These visual properties can be used to represent further information.<\/p>\n Nodes have height and width, as well as X and Y positions, in the second dimension. They also have a color. Up to five metrics can be represented using these characteristics. Furthermore, shape and texture could be used for nominal information, and color gradients for ordinal information.<\/p>\n An example of a polymetric view is shown in Figure 10 (see below).\u00a0PDF<\/a>) as shown. Here we see classes represented as nodes. Inheritance is expressed by edges running from top to bottom. The width of the nodes represents the number of attributes of a class, and the height represents the number of methods (excluding inherited ones). The color represents the number of lines of code in the class. The darker the class, the more lines of code it has. The black arrows mark particularly interesting classes that stand out simply by virtue of their statistical significance.<\/p>\n The class labeled 1 immediately catches the eye due to its height and dark color. It is clearly a class with a very large number of methods and a number of lines of code, unlike any other class. This class should be examined to see if it can be reduced in size by splitting it into several smaller classes.<\/p>\n The second class, in contrast, is very small in all three size metrics. No other class derives from it. It would be worth investigating whether this class is even needed. The third class is tall and wide and also has a relatively large number of lines of code. No other class derives from it. It might be possible to decompose it into several classes that inherit from each other. Looking at the class hierarchy indicated by the arrow number four, it's noticeable that two classes at the second level derive many more classes, while the other classes at this level are not further specialized. The fifth class is tiny but has two rather large sibling classes and a large number of child classes. This could be an indication that it is an abstract class.<\/p>\n This example demonstrates that the polymetric view allows for the simultaneous representation and visual comparison of numerous different metrics. It leverages the human capacity for visual pattern recognition, a technique employed in visual analytics. By mapping metrics to the five visual attributes of height, width, X and Y coordinates, and color, users can create a customized view best suited to their specific needs.<\/p>\n However, the view is limited to five metrics, and the coordinates cannot always be used for metric values. Once edges are drawn, a layout of the nodes that makes the graph readable is preferred. In that case, the coordinates cannot have any other semantics.<\/p>\n A particular challenge when using graphs is the visualization of relationships. For example, if you want to visualize a call graph, it seems logical to represent it as a graph whose nodes represent the functions and whose edges represent the calls between functions. However, if such a graph has been extracted by an analysis tool, the nodes and edges initially have no natural positions. The science of graph drawing (English: graphing).\u00a0Graph Drawing<\/em>) deals with algorithms that place nodes and edges as efficiently as possible to create a clear graph.<\/p>\n An example of a visualized graph can be seen in Figure 11 (see below).\u00a0PDF<\/a>The algorithm that calculated the coordinates of the nodes treats the nodes as bodies and the edges as attractive forces, then iteratively determines an arrangement that represents a force equilibrium. The problems with this approach are that hierarchies are lost, the arrangement does not necessarily reflect the semantics adequately, and node-edge intersections occur. It is not readily apparent from the representation who is connected to whom.<\/p>\n A new and quite promising idea for preserving the software's hierarchy and improving the clarity of edge representation is the use of bundled edges. Figure 12 shows an example of this (see below).\u00a0PDF<\/a>The hierarchy is represented as nested circular segments in the form of outer rings. The most deeply nested elements, such as classes or files, are located in the center. The center then provides space for the edges. This arrangement ensures that edges cannot cross nodes.<\/p>\n Furthermore, edges emanating from closely spaced nodes and leading to other closely spaced nodes are grouped together. The degree of grouping can be adjusted by the user. In the left part of Figure 12, edges are not grouped. In the right part, they are grouped, resulting in a much cleaner representation and making it easier to see which parts are connected to which other parts. However, even here, it is not always immediately clear which nodes are connected to the edges. This is only possible by selecting nodes or edges and hiding unselected elements.<\/p>\n Metaphors utilize the principle of analogy between two domains, allowing familiar aspects of one domain to be transferred to the other. They are ubiquitous in human-computer interaction. Consider, for example, the recycle bin on a desktop. Both the recycle bin and the desktop are everyday objects that are represented in graphical user interfaces. Metaphors are also frequently used in software visualization. One of the most popular metaphors is that of software cities. Figure 13 (see...).\u00a0PDF<\/a>The image shows an example of such a software city. Here, classes of an object-oriented program are represented as buildings. As with polymetric views, selected metrics (e.g., number of methods, attributes, and lines of code) are displayed, mapped to the width, length, and, in this case, the height added by the third dimension. Ultimately, software cities are nothing more than three-dimensional tree maps. However, they immediately evoke the impression of an American-style city in the human observer and appear far less abstract than two-dimensional tree maps.<\/p>\n Software cities are well-suited for representing aspects of a specific version of software. However, they are less suitable for depicting the evolution of software across different versions. During evolution, additional components can be added, existing components can be removed, or their properties, represented by height, width, and length, can change. Tree maps are designed for compact representation in limited spaces. Ideally, the layout should remain consistent across different visualizations of versions of the same software, as otherwise, the human viewer will become disoriented. Evo-Streets, as shown in Figure 14 (see below), offer a better representation for this purpose.\u00a0PDF<\/a>) are depicted.<\/p>\n The buildings, for example, are again classes within a program. The streets connecting them represent the hierarchy tree. The narrower a street, the deeper the hierarchy level it represents. Here, the constraint of having to work within a predetermined area is lifted. Instead, things can be added at the edges. The Evo-Streets can thus expand. Furthermore, the age of a class is represented by a mountain range. Over the course of evolution, the city grows on a mountain.<\/p>\n There are a number of free and paid programs and frameworks that allow you to create your own visualizations. A simple internet search using the keywords "visualization tools" yields many results. When it comes to visualization combined with analytical methods, one of the most popular is...\u00a0Frameworks R\u00a0<\/a>(https:\/\/www.r-project.org\/). R is an open-source ecosystem of programs for statistical methods and visualization. Those who want to create interactive visualizations that run in a browser will generally find what they need at [website address - not provided in the original text].\u00a0D3.js<\/a>\u00a0You can find what you need (https:\/\/d3js.org\/). The frameworks mentioned are very helpful for visualization. However, you also need to extract the data to be visualized. Furthermore, the visualization must be appropriate for the problem at hand. The visualization tools themselves don't handle the design of the visualization or the data extraction.<\/p>\n Software visualization is indispensable in maintenance when dealing with problems that require a human to interpret very large amounts of data. However, a specific software visualization is only ever suitable for certain purposes and detrimental to others, because every visualization emphasizes certain information and neglects other information. The match-mismatch hypothesis by Gilmore and Green describes when a particular visualization (or notation) is appropriate.<\/p>\n \u201cProblem-solving performance depends on whether the structure of a problem is matched by the structure of a notation.\u201d<\/em><\/p>\n Therefore, one should be familiar with many possible variations of visualizations so that the one appropriate for the problem can be identified. Just as we wouldn't expect a layperson to be able to discern details in an ultrasound image, we shouldn't assume that a maintenance programmer would be able to recognize anything at first glance of a specific type of software visualization. Understanding a visualization takes practice. This is also referred to as the "alphabet of software visualization." We have to learn to understand a graphical language and express ourselves within it. And what looks colorful and beautiful at first glance can, conversely, turn out to be useless upon closer examination.<\/p>\n Finally, it should be noted that we humans are equipped with many other senses, which we hardly use when experiencing software. It's possible that in the future we will even be able to smell, taste, and feel our software. In fact, there are already initial approaches to making software "hear." Furthermore, we expect that virtual reality visualizations will soon emerge. The necessary equipment is already affordable, and several research groups\u2014including ours\u2014are already experimenting with it.<\/p>\n Further reading can be found in Caserta and Zendra (2011), who have written a literature review on the visualization of static aspects of software. Ghanam and Carpendale (2008) describe visualizations specifically of software architecture. Teyseyre and Campo (2009) provide an overview of the use of three-dimensional representations in software visualization. A comprehensive book on the topic of software visualization was published by Diehl (2007).<\/p>\n Pierre Caserta, Olivier Zendra. Visualization of the Static aspects of Software: a survey. In: IEEE Transactions on Visualization and Computer Graphics, Institute of Electrical and Electronics Engineers, 2011, 17 (7), pages 913-933.<\/p>\n Alfredo R. Teyseyre and Marcelo R. Campo. An Overview of 3D Software Visualization. In: IEEE Transactions on Visualization and Computer Graphics, 2009, 15(1), pages 87-105.<\/p>\n Yaser Ghanam and Sheelagh Carpendale. A Survey Paper on Software Architecture Visualization. Technical report, University of Calgary, 2008.<\/p>\n https:\/\/dspace.ucalgary.ca\/bitstream\/1880\/46648\/1\/2008-906-19.pdf.<\/p>\n Stephan Diehl. Software visualization. 2007. Springer Publishing.<\/p>\n Prof. Dr. Rainer Koschke<\/strong>\u00a0is head of the Software Engineering research group at the University of Bremen. His research focuses on the maintenance and evolution of existing software. His research aims to develop practically applicable methods and tools for the further development of existing software. He is a co-founder of Axivion GmbH. Axivion (https:\/\/www.axivion.com) offers solutions for ensuring internal software quality and maintainability. At its core is the Axivion Bauhaus Suite, which combats software erosion efficiently and effectively.<\/p>\n Download the article as a PDF<\/strong><\/a><\/p>\n Do you want to bring yourself up to date with the latest technology?<\/strong><\/p>\n Then find out more\u00a0here<\/strong>\u00a0<\/a>MircoConsult offers training courses\/seminars\/workshops and individual coaching on the topic of Software Engineering Management \/ process, project and product management.<\/p>\n Training & coaching on the other topics in our portfolio can be found here.\u00a0here<\/a>.<\/strong><\/p>\n Valuable expertise in software engineering management \/ process, project and product management is available.\u00a0here<\/strong>\u00a0<\/a>Available for you to download free of charge.<\/p>\nWhat is software visualization and what is it good for?<\/h2>\n
What is visualized and for what purpose?<\/h2>\n
What are software analytics and visual analytics, and how are they related to software visualization?<\/h2>\n
Which characteristics of human perception should be taken into account, and how?<\/h2>\n
What types of visualizations and interaction forms are there?<\/h2>\n
What role do metaphors play?<\/h2>\n
How can I implement my own software visualization?<\/h2>\n
Summary<\/h2>\n
Further reading<\/h2>\n
author<\/h2>\n
\nSoftware Engineering Management \u2013 our training courses & coaching sessions<\/h2>\n
\nSoftware Engineering Management \u2013 Expertise<\/h2>\n