Steven P. Reiss

RESEARCH

Software Visualization


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.    


1. PECAN


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).    

Resources

2. BALSA and TANGO


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.       

Resources

3. Garden


The GARDEN environment provided a framework for creating and mixing visual language.  It also offered a framework for visualizing the execution of those languages.   

Resources

4. FIELD


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.           

Resources

5. VALLEY


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.      

Resources

6. CACTI


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.  

Resources

7. BLOOM


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.       

Resources

8. DYVISE


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.     

Resources

9. VELD


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.

Resources

10. Code Bubbles


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.     

Resources
Last updated: April 8, 2021