Software Visualization Research


Our reserach in software visualization goes back to work on the PECAN programming environment in the early 80's where we attempted to provide multiple (graphical) views of a program as it was being developed and run.

The FIELD environment that followed included a variety of tools for visualizations of both the static structure and the dynamic behavior of real programs in a UNIX environment.

We moved to 3D visualizations using first VALLEY and then CACTI system which was part of the Desert programming environment (which by the way was based on editing programs using FrameMaker).

More recent work highlighted here includes the BLOOM environment and the JIVE system. BLOOM is a framework for rapidly creating and viewing high-quality 3D visualizations of software systems. JIVE is a tool for visualizing Java programs in action with minimal overhead and maximal information. JOVE is another tool that provides slightly more detailed information about where execution is occurring, again with relatively small overhead. VELD is a new approach that builds on our experiences with JIVE and JOVE while attempting to let the programmer define application-specific dynamic visualizations.

Our most recent completed efforts have concentrated on using visualization to understand the dynamic behavior of software systems. We started here with a system, DYPER, that does controlled performance analysis of long-running Java systems. The controlled aspect means that the programmer can specify what overhead the performance analysis tool can use. The system provides a variety of performance metrics including CPU usage, IO, sockets, heap utilization, memory allocations, phase analysis, and reaction (event) analysis. An extension to DYPER, DYMEM, provides a compact visualization of object ownership from the memory of a running process.

Our newest, still to be completed, work involves providing high-quality visualizations of the dynamic behavior of an application that are application specific but that require only a minimum amount of specification on the part of the programmer. For example, the programmer can get a view of transacations, threads, thread states, and tasks over time by merely indicating the classes representing transactions and tasks.