We have been working on using software visualization as a tool for improving programming, generally by improving program understanding, since we first started using graphical workstations in the early 80's. Most of these efforts have been part of our work on programming or integrated development environments, where the environments we have developed have all included visualization-based tool. In addition, we have developed separate visualization systems for algorithm animation, 3-D visualizations, and performance analysis. We have also worked some on visualization languages (Garden, Mural, and our Internet of Things interfaces). Visualization has thus become integrated into much of our research.
While I continue to create visualizations and tools that use visualizations, I don't view myself as active in the area. Moreover, I have become somewhat pessimistic about the value and benefits of software visualization for developers as noted in The Paradox Of Software Visualization. I have also come to realize that for much of software visualization getting the right data in a timely fashion is probably more important than how that data is displayed.
Our first workstation environment, PECAN, provided several graphical views. In particular it supported both structured and unstructured flowcharts that were generated automatically from the source code. It also led to the development of our initial user interface library, BWE, that was used in future projects (through FIELD).
BALSA, done by Marc Brown, and TANGO, done by John Stasko, were two early algorithm animation systems that were designed to make it easy for developers to create new algorithm animations. Both were built on top of BWE. BALSA was widely used in introductory and advanced courses at Brown.
The GARDEN environment provided a framework for creating and mixing visual language. It also offered a framework for visualizing the execution of those languages.
The FIELD development environment included a variety of visualizations and tools with visual interfaces. These featured the visual display of data structures, dynamic views of performance and memory, call graphs, and class hierarchy graphs.
Valley was our first venture into 3-D visualization. We approached 3-D with the sense that any visaulization shown in 3D also had to make sense in 2-D and that the third dimension should just provide extra information.
Our next environment, DESERT, included ageneral purpose visualization tool based on the 3-D visualizations of VALLEY. It featured a visual interface for creating new visualizations.
Our efforts in VALLEY and CACTI led to the deveopment of BLOOM. This is a 2-D or 3-D general visualizaton framework that features a visual language (embodied in MURAL) for creating new visualizations. BLOOM was later used as an umbrella project for the dynamic, low-overhead performance visualizations of JIVE and JOVE.
Building on the low-overhead visualizations of JIVE and JOVE in BLOOM, we next create a general purpose performance visualization framework, DYVISE, that let the user specify the overhead while still providing detailed information. Most of the actual performance information was persented in tabular form, although some overview visualizations were present. DYVISE was later extended to provide visualizations of memory usage based on inferred ownership in DYMEM, and locking behavior using a pattern-based analysis in DYLOCK. These systems are still functional.
One of the problems we had with all the above visuzliations was that they produced visualizations in generic terms, talking about standard language constructs such as thread, classes, methods, etc. Programmers, however, want to use visualizations, especially dynamic visualizations to understand their program, to ask questions about their program, to see what is happening in terms of their program. This requires providing a visualization that talks in terms of the program (e.g. knows what threads do what, what routines are important, what an event starting at routine X is doing, etc.) VELD was our first attempt at providing such a visualization system. VELD let the programmer define events and characterize the resultant visualizations in terms of their own program. We don't consider it particular successful, however, since the 3-5 minutes it took to create the visualization was too long and more work than programmers were willing to spend.
Our current Code Bubbles environment includes a variety of software visualizations. These include static visualizations that are a loose generalization of those we had in FIELD, visualization of file histories, and a variety of dynamic visualizations. One of these dynamic visualizations, that of program tasks, attempts to duplicate what VELD did but without requiring any work on the part of the programmer.