Exploiting UML dynamic object modeling

for the visualization of C++ programs

Brian A. Malloy∗ James F. Power†
Computer Science Department Computer Science Department
Clemson University National University of Ireland, Maynooth

Abstract object and method interaction can be tracked using a tradi-

tional statement-level debugger, the scale and complexity of
In this paper we present an approach to modeling and vi- these interactions provides compelling motivation for higher
sualizing the dynamic interactions among objects in a C++ level visualization techniques.
application. We exploit UML diagrams to expressively vi- An increasingly accepted approach to modeling object
sualize both the static and dynamic properties of the appli- oriented applications is the Unified Modeling Language, or
cation. We make use of a class diagram and call graph of UML, which provides a selection of graphs and diagrams for
the application to select the parts of the application to be capturing static and dynamic behaviors of an object oriented
modeled, thereby reducing the number of objects and meth- application [Rumbaugh et al. 1999]. One of the primary driv-
ods under consideration with a concomitant reduction in the ing forces behind the evolution of version 2.0 of the UML
cognitive burden on the user of our system. We use aspects standard has been “an approach to developing software that
to insert probes into the application to enable profiling of the shifts the focus of development from code to models, and to
interactions of objects and methods and we visualize these automatically maintaining the relationship between the two”
interactions by providing sequence and communication dia- [Selic 2004]. Many modern code development environments
grams for the parts of the program under consideration. We already espouse this goal to some degree, offering integra-
complement our static selectors with dynamic selectors that tion between class diagrams and code projects, or use-cases
enable the user to further filter objects and methods from and testing strategies. However, there is relatively little re-
the sequence and communication diagrams, further enhanc- search on the exploitation of UML diagrams for visualizing
ing the cognitive economy of our system. A key feature of the dynamic behavior of objects and methods and even less
our approach is the provision for dynamic interaction with research on linking UML diagrams describing dynamic as-
both the profiler and the application. Interaction with the pects of software, such as sequence diagrams and commu-
profiler enables filtering of methods and objects. Interaction nication diagrams, with the run-time behavior of the code
with the application enables the user to supply input to the they describe.
application to provide direction and enhance comprehension In this paper we present an approach to modeling and vi-
or debugging. sualizing the dynamic interactions among objects in a C++
Keywords: Unified Modeling Language, sequence dia- application. We exploit UML graphs and diagrams, typi-
gram, aspect oriented programming, program comprehen- cally used during the requirements and design phases of the
sion life cycle, to expressively visualize both the static and dy-
namic properties of the application. One of the central issues
in dealing with run-time properties of objects and methods,
1 Introduction and Motivation and one that makes the domain particularly suitable to vi-
sualization, is the quantity of data involved. Even relatively
The current trend in the construction of large scale, multi- small programs can easily generate thousands of objects and
version systems is to exploit object technology to profit from millions of method calls in a relatively short running time. In
its advantages in reuse, extensibility, and ease of mainte- our approach, we make static use of a class diagram and call
nance over the procedural approach to application devel- graph of the application to select the parts of the application
opment. However, the object oriented paradigm comprises to be modeled, thereby reducing the number of objects and
an interesting blend of powerful constructs and unique chal- methods under consideration, with a concomitant reduction
lenges in comprehension, debugging and testing of the appli- in the cognitive burden on the user of our system. We use as-
cation. In the procedural realm, run-time program behavior pects to insert probes into the application to enable profiling
can be traced using a debugger, where code is executed on of the interactions of objects and methods and we visualize
a line-by-line basis. However, much of the complexity in these interactions by providing sequence and communication
object oriented software lies in the interactions among the diagrams for the parts of the program under consideration.
objects and methods, rather than in the statements within We complement our static selectors with dynamic selectors
the methods [Jacobs and Musial 2003; Reiss 2003]. Although that enable the user to further filter objects and methods
∗ e-mail:
from the sequence and communication diagrams, further en-
[email protected] hancing the cognitive economy of our system.
† e-mail: [email protected]
An important contribution of our work is the construction
of a toolset, spidor1 , which facilitates our investigation into
the pragmatics of our approach. A unique feature of our
work is that rather than using trace data generated from
program executions [Jacobs and Musial 2003; Jerding et al.

1 spidor is a mnemonic for Selection and Profiling of the In-

teraction of Dynamic Object Representations.

Accepted for the ACM Symposium on Software Visualization (SoftVis ’05)

St. Louis, Missouri, USA, May 15-16, 2005.
1997; Orso et al. 2003; Reiss 2003], we allow the user of similar to a class diagram with a difference that the nodes
spidor to dynamically interact with both the profiler and are instances rather than classes [Jacobs and Musial 2003].
the application during live execution. Interaction with the Thus, an object diagram is sometimes called an instance
profiler enables filtering of methods and objects. Interaction diagram. An object diagram is usually a special case of a
with the application enables the user to supply input to the class diagram or a communication diagram [Ambler 2004].
application to provide direction and enhance comprehension In our approach to visualization, we use the call graph and
or debugging. Since games and other graphics applications class diagram as static program representations that enable
pose unique challenges to comprehension and debugging, our the user to make fine-grained and coarse-grained selections
case study usage of spidor is an arcade game implemented of the parts of the program to be profiled. We then provide
with the Simple Directmedia Layer, SDL. an interactive animation of the program during execution
In the remainder of this paper we describe the design of using sequence and communication diagrams to illustrate
our approach and the implementation of spidor, highlight- the program behavior. We provide further filtering of the
ing the practicalities involved in event selection and run-time sequence and communication diagrams as part of our dy-
profiling. Section 2 briefly reviews the terminology used in namic filtering to reduce the cognitive effort of the user of
this paper. Section 3 presents an architectural overview of our system.
our work, including some of the issues relating to tracing C++
programs. Sections 4 and 5 present our Selector and Profiler
tools respectively. Section 6 surveys the existing work in the 3 System overview: Tracing C++
field of visualizing object oriented applications, particularly
in relation to UML diagrams and object-level visualization.
Programs
Section 7 concludes the paper and describes future directions
In this section we describe the principle technical details
of our work.
relating to the spidor toolset, including the Selector and
Profiler tools. Although the focus of this paper is the vi-
2 Background sualization of C++ code, almost all of the development was
carried out in Python [Rossum 2003]. Python proved ideal
Graph representations of program structure, control flow for the kind of text-processing required for the static aspects
and data flow, have long been a part of software develop- of the tools, as well as the GUI development using the Tk-
ment. For example, a call graph consists of nodes represent- inter module, which provides an interface to the Tk GUI
ing call sites or functions and edges representing a function toolkit. Python’s rapid prototyping facility and ease of in-
invocation [Murphy et al. 1998]. Call graphs have been used teroperability with other tools were also important factors.
for comprehension and optimization of both procedural and While a significant amount of software development takes
object oriented applications. place in C++, the tools and techniques for analyzing, profil-
Recently, the object oriented approach has become widely ing and visualizing this software are relatively less developed
accepted due to its promotion of reuse, extensibility and than those for other object oriented languages. For exam-
easier maintenance of large systems. To facilitate modeling ple, Java programs are easy to parse, either at source code or
of object oriented applications, the Unified Modeling Lan- bytecode level, and can be profiled either through JVM mod-
guage, UML, has become widely adopted and utilized to ification, inserting probes in the bytecode or, since version
express different aspects of an object oriented system from 1.4 of the SDK, using a built-in profiler API. In contrast, C++
different viewpoints and at different stages of the develop- is notoriously difficult to parse [Knapen et al. 1999; Malloy
ment life cycle [Rumbaugh et al. 1999]. The UML consists et al. 2003], and does not have a rich, robust, standardized
of thirteen diagrams of which the most commonly used dia- run-time environment comparable to the JVM.
gram is the class diagram [Cook and Brodsky 1999], a graph Figure 1 provides an overview of the system architecture
whose nodes are classes and whose edges express relation- of the spidor toolset, with the static features illustrated on
ships or dependencies between the classes. Class diagrams the left and the dynamic features illustrated on the right side
capture information about the static structure of an object of the figure. The input to the system is illustrated in the
oriented system. The UML also provides interaction dia- lower left corner of the figure, an application written in C++.
grams that capture behavior or interactions among the class The output of the system is illustrated on the right side of
instances, or objects, in an object oriented system. The in- the figure where we provide visualization of sequence and
teraction diagrams that are important in our work include communication diagrams on a Tk GUI canvas. We use the
sequence and communication diagrams. gcc abstract syntax tree (AST) as our internal representation
A sequence diagram is an interaction diagram that models of the C++ application; we provide more detail of this phase
time along the vertical length of the diagram and method in- of spidor in Section 3.1.
vocations between objects along the horizontal length of the The rectangle in the center of Figure 1 represents the Se-
diagram. Sequence diagrams are the most commonly used lector component of the spidor system. The Selector is
interaction diagram and are the object oriented counterpart written in Python and takes the gcc AST as input via our
of a call graph. The communication diagram is a second pyGast API, constructing a class diagram and system call
interaction diagram that shows instances of classes, their re- graph for the application.
lationships, and the flow of messages between the instances The user can then select the classes, methods or method
[Ambler 2004]. Communication diagrams are similar to se- invocations to be profiled, and, as explained in Section 3.3,
quence diagrams with a difference that communication dia- the relevant profiling code is then woven through the ap-
grams allow free placement of participants where connecting plication source code using AspectC++ [Mahrenholz et al.
links representing messages can be adorned with nested dec- 2002]. This is compiled to an executable, in our case a Unix
imal numbers to resolve ambiguity with self-calls. Further shared object, that interacts with the Profiler to generate
discussion of this numbering can be found in Section 4.3, and visualize the sequence and communication diagrams for
with an illustration in Figure 7. the selected parts of the application.
An object diagram is a form of interaction diagram that is In the next section we provide more detail about the gcc

Accepted for the ACM Symposium on Software Visualization (SoftVis ’05)

St. Louis, Missouri, USA, May 15-16, 2005.
 Dot
STATIC DYNAMIC

pyDot

Selector Profiler

Class Call Python/C++ Sequence

Diagram Graph Advice ’glue’ code diagram
Communication
code
gcc Diagram
AST pyGast Aspect callback
files API Generator interface

C++ Pointcuts
gcc
Code
Instrumented
executable
Aspect C++

Figure 1: System architecture. This figure presents the main components of the spidor toolset. External programs and APIs,
such as gcc are colored blue, generated code, such as the pointcuts, is colored green, and our own code is colored gold. The
C++ code for the program being profiled, shown here in white, is the input to the system.

AST and in Section 3.2 we provide more detail about our these graphs we use the Dot tool, part of the Graphviz graph
use of Dot [Gansner and North 2000]. In Section 3.3 we visualization software suite [Gansner and North 2000]. We
describe our use of aspects and in Section 3.4 we describe found the default Dot layout strategy, based on a hierarchi-
our approach to connecting C++ and Python. cal layout, to be the most suitable for each of the graphs
created. Since the main edges in all three diagrams were
3.1 Interfacing with gcc based in some way on method calls, the use of the hierar-
chical layout helped to clearly present the flow of control
The spidor toolset uses the C++ compiler from the GNU through the system.
Compiler Collection, gcc, as its front end. We had previ- We utilize an existing program, pyDot, to represent Dot
ously used gcc as a basis for C++ program comprehension graphs, and both our Selector and Profiler tools develop this
by instrumenting its parser [Power and Malloy 2002], but to display Dot graphs in a Python canvas. In particular, our
this proved difficult to maintain over various gcc releases. Selector tool provides interpolation between the co-ordinate
Since version 3.0, gcc has begun to develop an internal ab- systems of Python canvas objects and Dot graphs to allow
stract syntax tree (AST) format, known as generic, which interaction with the Dot graph for the purposes of selecting
provides a high-level representation of a C++ program [Mer- nodes and edges.
rill 2003]. This representation is also reasonably accessible, Visualization of sequence diagrams is unencumbered by
since it can be generated as a text file using a compiler switch the layout problem inherent in visualizing call graphs and
(-fdump-translation-unit-all). class diagrams, since sequence diagram sequencing of mes-
However, it should be noted that most of the generic sages is ordered by time. Thus, we use Dot to visualize
documentation is in the form of comments in the gcc source our call graph, class and communication diagrams, and we
code, and some effort is required to disentangle the con- map Tkinter widgets directly onto a canvas to visualize our
structs used. We have written a Python API, pyGast, to sequence diagrams.
facilitate working with the gcc generic output. pyGast pro-
vides methods to parse the gcc output to produce a Python
representation of the AST, as well as providing facilities for 3.3 Interfacing with AspectC++
visitor-based AST navigation. Our pyGast API also builds
a representation of the class hierarchy, the call graph, and In order to create run-time profile data we need to track
provides output in text, XML and Dot formats. object creation and destruction, as well as method calls and
returns at run-time. To achieve this, we insert probes in the
C++ code at appropriate positions, as selected by the user. In
3.2 Interfacing with Dot order to facilitate using spidor with multiple C++ programs
Visualizing C++ programs statically and dynamically using it was important to automate the process of instrumenting
class diagrams, call graphs and communication diagrams re- the code.
quires the construction of non-trivial graphs. To visualize This kind of cross-cutting concern is one of the standard

Accepted for the ACM Symposium on Software Visualization (SoftVis ’05)

St. Louis, Missouri, USA, May 15-16, 2005.
examples used to promote Aspect Oriented Programming
(AOP) [Gibbs and Malloy 2003; Kiczales et al. 1997]. The
AOP approach allows for such concerns to be specified sep-
arately in Aspects, and these are then woven into the code
using a special tool. For this project, we used the AspectC++
compiler [Mahrenholz et al. 2002], an implementation of
AOP for C++ that is similar in style to the more widely-used
AspectJ.
The parts of the program at which the new behavior is
to be added are referred to as pointcut, and the behavior
itself is called advice [Lohmann et al. 2004]. In this project
the pointcuts are specific to each profiling instance, and are
created using the Selector tool, described in Section 4. The
advice in each case involves interfacing with our Profiler tool,
and is the same for each program. Thus, the output of the
Selector tool is effectively a piece of AspectC++ code speci-
fying pointcuts, which can then be compiled, along with the
original code, to generate a version of the program that will
interact with the Profiler.

3.4 Interfacing between C++ and Python

Since our Profiler is written in Python, we require a facility
to interface with C++. Interfacing with the C++ code being
profiled is achieved using the Python/C API, which allows
Python code to call C and C++ code, and vice versa. Hence,
the advice woven into the code by the AspectC++ compiler
also contains hooks to this interface, allowing the Python
code to register handlers with the C++ code, which are then
called at each pointcut. Figure 2: The Include File Selector. This figure shows the
We emphasize that this process is automated, and requires include file dialog, one of the windows involved in setting
no user interaction or user modification of the C++ code. extraction options.
Further, any Python code capable of handling a small set of
events can be used in place of the spidor Profiler.
and select the methods and method calls to be profiled at
run-time. The Selector tool uses gcc to parse a C++ project,
3.5 Case Study: An Arcade Game as described in Section 3, and presents a class diagram and
In subsequent sections we discuss the operation of our visual- a call graph for the project. The purpose of the Selector is
ization tools, and show examples of their use. The program to allow the user to select those method calls in the program
being visualized on each case is a simple arcade game, writ- that will be visualized at run-time.
ten in C++ using the Simple DirectMedia Layer multimedia The Selector tool allows the user to create a project for
library. Our approach, and the spidor toolset, is designed each application, setting compiler and other options, and
work with any C++ program, and we use the arcade game adding the relevant source files to the project. In setting
simply as an example. up the project, a user defines the set of C++ files to be pro-
We chose to profile an arcade game since game software cessed. Once these have been selected we use gcc to calculate
in C++ typically exhibits two properties that make visualiza- file dependencies, and a further dialog box, shown in Figure
tion desirable. First, traditional text-based debugging can 2, can then be used to remove individual header files from
be difficult to synchronize with graphical or GUI-based soft- consideration.
ware. Second, many games lack design artifacts, such as It is not necessary that all the files in an application be
class diagrams, and an approach that re-generates these au- added, since the eventual instrumentation code will augment
tomatically from the code can be useful in itself. the code base, rather than replacing any elements of it. Be-
The arcade game is written in just under 1,000 lines of C++ ing able to select only those files that are of interest is an
code, spread over 9 source files, describing 6 classes in total, important aid to comprehensibility, since omitting files will
with a call graph containing 48 methods and 87 method reduce the size of the class diagram and system call graph.
calls. As an example of the scale of the dynamic visualization Being able to selectively add files to a project also aids mod-
problem, running the game for just under 20 seconds leads to ularization, since the source files for an application can be di-
the creation of 36,000 objects and just under 273,000 method vided over several Selector projects. The output from these
calls (not including constructors or destructors). projects can then be used either individually or in any com-
bination to instrument the application.

4 Static Visualization:
4.1 The Class Diagram
The Selector
The UML class diagram is a popular way of presenting a
In this section we describe the spidor’s Selector tool, whose high-level overview of an object oriented system, and is in-
purpose is to visualize the classes and methods in a C++ creasingly used in programming environments as an aid to
program, and to allow the user to navigate through these code organization and navigation. The edges in a class dia-

Accepted for the ACM Symposium on Software Visualization (SoftVis ’05)

St. Louis, Missouri, USA, May 15-16, 2005.
Figure 3: The Class Diagram. This figure shows the Selector tool displaying the class diagram for the system. Each class is
assigned a unique color, and the layout is based on class dependencies.

gram represent relationships between classes, most notably lights the fact that all of the actions of the arcade game are
inheritance. However, associations based on field references, directed from AnimationManager.
parameters and local variables can also be represented. A theme of our work is that we seek to exploit the widely
Since we are interested in the interactions between meth- used UML notations as an aid to program visualization.
ods in the system, we restrict the class diagram edges to However, despite the importance of method interactions,
just two kinds: those representing inheritance, and those there is no UML diagram that completely meets the task of
representing dependencies between classes. A class C1 has representing these interactions. Elements of the call graph
a dependency on class C2 whenever a method from C1 can can be derived from UML sequence diagrams, activity dia-
call a method from C2 . Eliding associations and using Dot grams and communication diagrams, yet none of these pre-
to control the layout gives a rather unusual look to the class sents the interactions between methods as clearly as the call
diagram. Typically a class diagram, especially when used as graph.
a design artifact, will use the inheritance relationship as the The system call graph presents all methods in the sys-
main layout ordering edge, and use associations to impose tem, and can be quite complicated, even for relatively small
secondary orderings. However, we find that basing the lay- C++ programs. An added advantage of our use of Dot to
out on dependencies is a significant aid to understanding the layout the graph is the effect of exposing the ranking be-
flow of method calls, the main source of flow in our project tween methods in terms of the ordering of method calls, and
whose focus is dynamic object modeling. Figure 3 illustrates this provides a good overall view of the hierarchy of inter-
a partial class diagram for the arcade game that we use as actions. Fixing a coloring scheme for classes and using this
our case study. At the root of the diagram is class Anima- coloring for the nodes in the call graph was a significant aid
tionManager, which choreographs the actions of the game. to comprehension of the interactions among the methods in
AnimationManager calls methods in classes ExplodingSprite, our model.
Sound and Background, with stereotypes attached to each of The system call graph acts as a selector for method calls.
the edges emanating from AnimationManager to capture this We adopt the convention that selecting a node implies pro-
calling relationship. filing all calls to that method, whereas selecting an edge
implies only profiling calls from the source method to the
destination method. The class diagram acts as a higher level
4.2 The System Call Graph selector, where selecting a class implies the selection of each
The second overall view we present is the system call graph. of its methods in the system call graph.
This graph is not part of the UML standard, nor does it
typically appear during system design, but is a tool com- 4.3 Method and Class Call Graphs
monly used in program analysis and software testing. In a
system call graph the nodes are the methods in the system, One drawback of the high-level view presented by the system
and there is a directed edge between two methods m1 and call graph is that it can be difficult to distinguish edges for
m2 whenever m1 can call m2 . Figure 4 illustrates a partial methods that call, or that are called by, many others. To
call graph for the arcade game that we use in our case study. deal with this we have implemented lower-level selectors in
In the figure, function main is shown on the left side of the both the class diagram and the call graph. Right-clicking on
graph with edges leading to the constructor and destructor a node in the system call graph presents a detail of the graph,
of AnimationManager, also shown in Figure 3. Figure 4 high- showing just the immediate predecessors and successors of

Accepted for the ACM Symposium on Software Visualization (SoftVis ’05)

St. Louis, Missouri, USA, May 15-16, 2005.
Figure 4: The System Call Graph. This figure shows the Selector tool displaying the call graph for the whole system. The
nodes in this graph, representing methods, are colored to indicate their owning class.

that node. The reduced information in this method call graph class or method call graphs. It should be noted however
can be laid out to clearly distinguish between the method’s that there is some overhead in maintaining consistency be-
individual callers and callees. The window at the bottom of tween selections in all these diagrams, and performance can
Figure 5 illustrates a method call graph where the user has degrade if many views have to be maintained. In practice,
right clicked on method Sound::playSound() and the figure we do not envisage a need for more than one or two class or
illustrates methods that call Sound::playSound() as well as method call graphs at any one time.
the methods called by Sound::playSound().
Similarly, clicking the middle mouse button on a class in
the class diagram or a method in the call graph produces 5 Dynamic Visualization:
a class call graph. Here, we display the methods in the The Profiler
class, along with the immediate predecessors and successors
of these methods from the call graph. These methods are The output of the Selector tool is an instrumented version
then grouped based on their class, giving a fine grained view of the original C++ program, which is designed to interact
on the dependencies between classes. The same coloring and with a simple Python interface at run-time. The Profiler
selection conventions are used for all call graphs, and all are tool described in this section implements this interface, and
kept synchronized, so that a selection in any one is propa- displays run-time information about a program in terms of
gated to all the others. The rightmost window in Figure 5 UML sequence and communication diagrams.
also shows a class call graph where the user has clicked the The design of the Profiler is based loosely on the tradi-
middle mouse button on a method in class Sound and all of tional command-line debugger. The user launches the pro-
the methods that call methods in Sound are shown as well gram from the Profiler, and can then step through its exe-
as the methods called from within class Sound. cution at a chosen level of granularity. Unlike a traditional
Clicking with the middle or right mouse buttons on a class debugger, however, the user does not step through the actual
or method call graph replaces that call graph with the new source code, but rather the sequence diagram corresponding
one. Thus the user can display the method call graph for to the program’s execution. It is not intended that the Pro-
a method, and then follow the chain of calls one-by-one by filer would be an alternative to a traditional debugger, but
repeatedly right-clicking on one of the successor methods. rather a complimentary tool, since it concentrates on visual-
At any stage the user can click the middle mouse button izing method interactions, rather than the details of method
on a method and zoom out to the class call graph for that execution.
method’s class. The main window of the Profiler is shown in Figure 6.
At present the Selector provides a single class diagram The large red ’step’ button is used to invoke and return con-
and system call graph, and allows for any number of popup trol to the C++ program being profiled, and the slider bar

Accepted for the ACM Symposium on Software Visualization (SoftVis ’05)

St. Louis, Missouri, USA, May 15-16, 2005.
Figure 5: Class and Method Call Graphs. These popup windows can be launched by selecting a node in the class diagram or
call graph, and show either a class-based or method-based subset of the call graph.

controls the number of events processed between each step. the height of the diagram, the user can choose to ignore any
In this context, an event is an object creation or destruction, of the methods or objects at run-time. The ’Method filter’
or the start or end of a method call. The profiler interacts button displays a pop-up list of the methods being profiled,
synchronously with the program being profiled. The pro- and the user can choose to enable or disable tracking of in-
gram is run for the designated number of steps, and then dividual methods during the program’s run. The ’Object
pauses while control is returned to the Profiler so that the filter’ button works analogously for objects.
user can examine the sequence diagram.
5.2 The Communication Diagram
5.1 The Sequence Diagram
The UML communication diagram is a more traditional
The sequence diagram uses the standard UML notation, graph, where the nodes correspond to individual objects,
where each individual object is represented by a horizon- and an edge denotes one or more method calls between the
tal bar, with the object name and class at the top. Each objects. While the communication diagram could be main-
’thickening’ of the bar represents a method belonging to that tained in parallel with the sequence diagram, in practice this
object being executed. Method calls from one object to the imposes a noticeable overhead on the Profiling. Also, the
next are represented by horizontal arrows between the rel- communication diagram quickly becomes incomprehensible
evant object bars. Thus, the sequence diagram increases in for large volumes of data, since it does not follow the more
width with each object creation, and increases in length with restrictive layout of the sequence diagram, where the most
each method call. A large ’X’ at the end of an object’s line recent events appear at the bottom, and the newest objects
denotes the destruction of that object. appear on the right side of the diagram.
Navigation within the sequence diagram can be achieved The approach taken in our tool is to provide the commu-
using either the slider bars, or the page navigation controls nication diagram on request. Thus, whenever the program is
on the panel. As with the selector tool, color is used to stopped and the user is investigating the sequence diagram,
identify objects from the same class. The color used in the they can also press a button to produce the communication
Profiler is the same as that used in the Selection tool, and diagram for that point in the program. Since communica-
is relayed to the Profiler as part of the instrumentation. tion diagrams can quickly become unmanageable, our dy-
Since the sequence diagram can quickly grow quite large, namic profiler will only present the last 50 events. As is the
two features were implemented to reduce its width and case for the Selector, an interface to the Dot tool is used to
height. Since a destroyed object has no further use for its provide graph layout information. Figure 7 shows a profiling
horizontal area, newly created objects are always positioned session with a communication diagram in the foreground.
in the leftmost free lane in the diagram. In order to reduce We use the standard UML numbering system for com-

Accepted for the ACM Symposium on Software Visualization (SoftVis ’05)

St. Louis, Missouri, USA, May 15-16, 2005.
Figure 6: A Profiling Session. This figure shows the Profiler tool in action. The Profiler main window, displaying the sequence
diagram is shown in the top-left of the figure, and the C++ game being profiled is shown in the bottom-right of the figure.
Also shown are the popup method-filter and object-filter dialogs.

Figure 7: The Communication Diagram. The communication diagram, shown here in the foreground, can be launched at any
point during profiling. It can show the last 50 events; the slider bar allows the user to step through these events one by one.

Accepted for the ACM Symposium on Software Visualization (SoftVis ’05)

St. Louis, Missouri, USA, May 15-16, 2005.
munication diagrams in order to identify the sequence of ther profile information and to iteratively move between the
method calls. However, since this can be difficult to follow profile window and the application until terminating the run.
in larger diagrams, we also provide a facility to mimic the This interaction with both the profiler and the application
construction of the diagram on an event-by-event basis. The is unique to our approach to visualization.
slider bar at the bottom of the diagram allows the user to Jones et al. present two tools, tarantula and gam-
step through the events one-by-one, and they are filled in on matella, that utilize visualization techniques to effectively
the diagram as the slider bar is moved to the right. The most transform program execution data into visual information
recently traversed arc and the object owning the currently that can be explored and easily understood [Jones et al.
executing method are highlighted at each step. 2002; Jones et al. 2004; Orso et al. 2003]. The tools use
coloring to summarize information about the program-ex-
ecution data, using a continuous spectrum of colors ranging
5.3 Object-Level Views
from red (danger), to yellow (caution), to green (safety). To
Even with static and dynamic event filtering, both the se- manage large programs, they provide representations of the
quence and communication diagrams can rapidly become application at three levels of granularity from fine-grained to
quite large. The communication diagram in particular can coarse-grained: statement, file and system. To handle a high
become quite difficult to follow for relatively short sequences number of program-execution data, gammatella provides
of events, especially if these events are concentrated between filtering, which permits the user to select a subset of exe-
a few objects. As is the case with our Selector tool, we deal cutions to be visualized, and summarization, which permits
with this problem using selective views of the diagrams. the user to aggregate the program-execution data for a set
At any stage during profiling the user can select an object of executions. Since gammatella is used for deployed soft-
in the sequence diagram and view either a communication ware, filtering can help the user to focus on a subset of the
diagram or a sequence diagram specific to that object. In deployed executions and summarization can help the user
both cases we visualize all messages sent to and from the identify correlations among deployed executions.
selected object, along with those objects directly involved in The gammatella system is complementary to our spi-
those messages. These views allow the user to zoom in on a dor system. Unlike our system, gammatella does not uti-
particular object’s activity, without the confusion of sorting lize UML diagrams but rather uses visualization to capture
through unrelated events. The window on the right of Figure information about the data rather than to promote compre-
7 shows a communication diagram for object number 27, an hension of the code through animation of the interactions
instance of Sprite. between objects and method invocations. Also, in our ap-
proach the user can dynamically interact with both the pro-
filer and the running application and the user can alter input
6 Related Work to the application as it is running; in the gammatella sys-
tem the user can only interact with trace data rather than
In this section we review the work that is most closely re- the running program.
lated to our approach. Due to space constraints we focus on Jerding et al. present the Polka animation toolkit, which
approaches that visualize UML diagrams or demonstrate a uses techniques for scalable visualizations based on call trace
filtering approach similar to ours. We note that some of the files generated from C++ source code annotated by hand
recent research on garbage collection, for example GCspy [Jerding et al. 1997]. Polka visualizations are called exe-
[Printezis and Jones 2002], parallels our work but from the cution murals, where time is shown on the horizontal axis
perspective of low-level heap visualization rather than UML and each message, visualized as a single pixel wide vertical
diagrams. line from source to destination class, shown on the vertical
Jacobs and Musial describe an approach for debugging axis. There are two views provided by Polka. The first view
Java programs using UML object diagrams [Jacobs and Mu- allows a user to display and browse real-world event traces
sial 2003]. To capture a large diagram on a single page, they of 100, 000+ messages. The second view attempts to visu-
provide more detail for the most recently examined graphical alize interaction patterns by augmenting the first view with
elements and less detail for elements that are remote from automatic message pattern detection methods. The visu-
this recent element. Their approach enables the viewer to alizations of Jerding et al. are not animations of sequence
examine as many as 75 classes on a single page, a three-fold diagrams but rather compactions of interaction diagrams,
improvement over viewing the 24 complete classes that can summarizing hundreds of thousands of messages and the pat-
fit on a page using standard UML presentation such as the terns within the messages. Unlike spidor, Polka does not
presentation provided by ArgoUML. permit interaction with the application during execution.
Jacobs and Musial do not provide static selectors to fil-
ter elements for inspection. In our approach, we provide a
class diagram and a call graph to permit the user to stati- 7 Conclusions and Future Work
cally select the relevant parts of the program to be profiled.
Moreover, we also provide run-time filtering to enable the In this paper we have described our approach to selecting
user to select the number of events to be viewed, and class and visualizing the dynamic interactions among objects in
and method filtering to allow the user to eliminate selected an application. Using the internal abstract syntax tree for-
objects and messages from the profile. Our approach pro- mat of gcc, generic, we build representations of a call graph
vides a fine-grained view of the interaction of objects and and class diagram to permit the user of our system to stati-
method invocations through our animation of sequence di- cally choose the parts of the program to model. We exploit
agrams; we also provide communication diagrams that are aspects, using AspectC++, to insert probes into the applica-
symmetric with the sequence diagram currently under view. tion to enable profiling of invocations to constructors, de-
Finally, our approach allows the user to interact with our structors and methods. We build a profiler that monitors
profiling system as the application is running, allowing the the dynamic behavior of objects and we visualize this be-
user to control the filtering and selection in the profile win- havior by building sequence and communication diagrams.
dow, transfer control back to the application to obtain fur- Since these diagrams can quickly become large, we comple-

Accepted for the ACM Symposium on Software Visualization (SoftVis ’05)

St. Louis, Missouri, USA, May 15-16, 2005.
ment our static selectors with run-time selectors that permit Jones, J. A., Harrold, M. J., and Orso, A. 2002. Visu-
the user to filter objects and methods from the visualization, alization of test information to assist fault localization. In
thereby reducing the cognitive burden on the user. 24th International Conference on Software Engineering,
The contributions of our work are as follows: 467–477.

1. The design of a system for dynamic selection and visu- Jones, J. A., Orso, A., and Harrold, M. J. 2004. Gam-
alization of objects. matella: Visualizing program-execution data for deployed
software. Information Visualization 3, 3, 173–188.
2. An examination of the pragmatics of our system
through the construction of a toolset, spidor, which Kiczales, G., Lamping, J., Mendhedar, A., Maeda,
reduces the cognitive burden on the user by providing C., Lopes, C., Loingtier, J., and Irwin, J. 1997.
static selection of classes and methods and dynamic se- Aspect-oriented programming. In European Conference
lection of objects and messages. on Object-Oriented Programming, 220–242.
3. The visualization of sequence and communication dia- Knapen, G., Lague, B., Dagenais, M., and Merlo, E.
grams illustrating objects and messages of interest to 1999. Parsing C++ despite missing declarations. In 7th
the user. International Workshop on Program Comprehension.
4. Dynamic interaction with both the application and the
profiler. Interaction with the application enables the Lohmann, D., Blaschke, G., and Spinczyk, O. 2004.
user to supply input to the application to provide di- Generic advice: On the combination of AOP with gener-
rection and enhance comprehension or debugging. In- ative programming in AspectC++. In 3rd International
teraction with the profiler enables filtering of methods Conference on Generative Programming and Component
and objects for increased cognitive economy. Engineering.
Mahrenholz, D., Spinczyk, O., and Schrder-
Our visualization project is ongoing and our future work
Preikschat, W. 2002. Program instrumentation for de-
will take the following directions. We plan to conduct a com-
bugging and monitoring with Aspect C. In International
parison of the efficacy of sequence diagrams as compared to
Symposium on Object-oriented Real-time distributed Com-
communication diagrams in reasoning about large C++ ap-
puting, 249–256.
plications. To apply our approach to large applications we
will investigate techniques to reduce the size of sequence di- Malloy, B. A., Gibbs, T. H., and Power, J. F. 2003.
agrams by collapsing repeating sequences of messages into Decorating tokens to facilitate recognition of ambiguous
a single sequence [Jerding et al. 1997]. We will also investi- language constructs. Software: Practice and Experience
gate reducing the size of the communication diagrams using 33, 1, 19–39.
techniques such as those described in [Jacobs and Musial
2003]. We also plan to incorporate more debugging facilities Merrill, J. 2003. GENERIC and GIMPLE: A new tree
into spidor, permitting the user to set breakpoints during representation for entire functions. In First Annual GCC
execution of the application. Finally, we plan to investigate Developers Summit, 171–180.
usage of spidor generated design artifacts to validate design
artifacts constructed earlier in the life cycle. Murphy, G. C., Notkin, D., Griswold, W. G., and
Lan, E. S. 1998. An empirical study of static call graph
extractors. ACM Transactions on Software Engineering
and Methodology 7, 2, 158–191.
References
Orso, A., Jones, J., and Harrold, M. J. 2003. Visual-
Ambler, S. W. 2004. The Object Primer, third ed. Cam- ization of program-execution data for deployed software.
bridge University Press. In ACM Symposium on Software Visualization, 67–76.

Cook, S., and Brodsky, S. 1999. OMG analysis and de- Power, J. F., and Malloy, B. A. 2002. Program an-
sign PTF, UML 2.0. In Request for Information, Response notation in XML: a parser-based approach. In Working
from IBM Corporation. Conference on Reverse Engineering, 190–198.
Printezis, T., and Jones, R. 2002. GCspy: an adaptable
Gansner, E. R., and North, S. C. 2000. An open heap visualisation framework. In Conference on Object-
graph visualization system and its applications to soft- Oriented Programming Systems, Languages and Applica-
ware engineering. Software: Practice and Experience 30, tions, 343–358.
11 (September), 1203–1233.
Reiss, S. P. 2003. Visualizing Java in action. In ACM
Gibbs, T. H., and Malloy, B. A. 2003. Weaving aspects Symposium on Software Visualization, 57–65.
into C++ applications for validation of temporal invari-
ants. In 7th European Conference on Software Mainte- Rossum, G. V. 2003. An Introduction to Python, first ed.
nance and Reengineering, 249–258. Network Theory Ltd.
Rumbaugh, J., Jacobson, I., and Booch, G. 1999. The
Jacobs, T., and Musial, B. 2003. Interactive visual de- Unified Modeling Language Reference Manual. Object
bugging with UML. In ACM Symposium on Software Vi- Technology Series. Addison-Wesley.
sualization, 115–122.
Selic, B. 2004. UML 2.0: Exploiting abstration and au-
Jerding, D. F., Stasko, J. T., and Ball, T. 1997. Visual- tomation. Software Development Times Issue 98 (March
izing interactions in program executions. In International 15).
Conference on Software Engineering, 360–370.

Accepted for the ACM Symposium on Software Visualization (SoftVis ’05)

St. Louis, Missouri, USA, May 15-16, 2005.