GDR: A VISUALIZATION TOOL FOR GRAPH ALGORITHMS

MATTHIAS STALLMANN , RANGE CLEAVELAND AND

PRASHANT HEBBAR

Abstract. This paper describes GDR, a tool for editing graphs and animating graph algorithms. The design of GDR emphasizes simplicity and the ability to interact with other tools. GDR has been used to implement classroom animations of graph algorithms and finite automata, and as a research tool for prototyping algorithms.

1. Introduction

GDR (for Graph Drawing) is a tool for editing graphs and animating graph algorithms. The motivation for animation tools comes primarily from the classroom; students often have difficulty mastering the formal concepts of graph theory, even though they usually have no trouble in following the associated visual intuitions. An appropriate animation tool can provide an invaluable link between formalism and graphical intuition, since students are given the opportunity to see how a formal presentation of a graph algorithm directly translates into visually intuitive operations on graphs. For this reason, animation tools can also play a useful research role as testbeds for prototyping new algorithms and for testing conjectures about graphs. Thus GDR serves both as an instructional aid and as a research instrument.

The design of GDR was strongly influenced by our desire for the tool to be easy-to-use (even by inexperienced programmers), portable, and flexible. Our approach was to develop GDR as a tool rather than a self- contained system, so that it is easily modified and interfaced with other software. This has led to two approaches to using GDR with other tools. In the first, GDR functions as a graph editor; users create graphs using GDR, save them in files, and feed the files as input into the other tools. This mode of interaction only requires that front-ends be written for the other tools that can parse the simple output generated by GDR. The second mode of interaction is object-oriented ; GDR provides a high-level interface to graph objects that programmers can manipulate (using calls to functions implemented in GDR). Users of GDR can then create graphs

1991 Mathematics Subject Classification. Primary 05C85,68R10. Secondary 68068.

This paper is in final form and no version of it will be submitted for publication elsewhere.

and apply the programmer-supplied routines to these graphs. Moreover, GDR is written in C and uses the library routines supplied by X-windows to implement its graphical capabilities. Thus the tool can be run on many different platforms.

The remainder of this overview is organized as follows. At the end of $1 we discuss features that distinguish GDR from other tools. $2 out- lines the design and capabilities of GDR, and their use in designing al- gorithm animations. $3 describes existing animations, $4 suggests future enhancements to GDR, and $ 5 has some concluding remarks. A detailed description of GDR can be found in our technical report [14]. Other in- formation and source code can be obtained by contacting the first author (mattOeuler . csc .ncsu. edu or Matt-StallmannOncsu. edu).

In what follows the word programmer denotes a person who writes an application program (e.g. an algorithm animation) using GDR as a tool, and user refers to a person who interacts with GDR, either to edit a graph or to run an animation created by a programmer.

The development of GDR was undertaken because we felt that, among the available tools that had come to our attention (in Fall, 1989), only GraphView, developed by Birgisson and Shannon [2], had the desired functionality. However, GraphView was developed on the NeXT machine, and was thus not compatible with our hardware environment.

This volume attests to the variety of graph editorslgraph algorithm animators now available [I, 9, 101. Instead of presenting a detailed com- parison of GDR with these other tools and systems, we list some features, that, though not necessarily unique to GDR, serve to differentiate it from the others.

(i) Graphs edited by GDR are stored as ASCII files in a simple format that can easily be manipulated by other programs.

(ii) GDR supports the use of text labels for both vertices and edges (these are implemented as subwindows). The content of each label and whether or not it is displayed can be controlled by the user or the animation program. Labels play a prominent role in all animations implemented with GDR. String labels are used in automata simulations, for example, and numerical labels (strings interpreted as numbers) are used to represent vertex and/or edge weights.

(iii) Animation programs (and GDR itself) are written in C. GDR provides macros for standard graph traversal operations; for ex- ample

for-adjacent (v, e , w) { <body> } executes the body for every edge e incident to vertex v (vertex w

GDR outputfile

fileGDR input

programother

otherprogram

X Y means X calls Y

animation

written by(other program

display

user

animat()

GDR)linked withcompiled andprogrammer,ADT functions

graphGDR

GDR

or some other program, is read and subjected to a sequence of interactive editing operations; then a modified file is written so that it may be used by other programs. Typical editing operations include adding and delet- ing vertices and edges and moving vertices (with the incident edges being dragged along).

GDR is extendible in the sense that any editing command can also be invoked by a program compiled and linked with GDR, as illustrated by the interactions to the right of the dotted line in Figure 1. The typical use of such a feature in a text editor is to expand the repertoire of editing operations. With GDR there is also the possibility of using a program to animate the actions of an algorithm. Henceforth the program, activated from the editor as a menu option via a C function animat 0 , is referred to as the animation.

At the heart of the animation interface is a mechanism for accessing the graph itself as an abstract data type. From GDR7s point of view, a graph is a composite object whose components are vertices and edges. Each vertex and edge has several attributes that can be manipulated by the user or by the animation. For clarity we classify the attributes into three categories: logical attributes, independent of any display of the graph, are the adjacency list of a vertex, the endpoints of an edge, and labels of vertices and edges; geometric attributes are the positions of vertices, labels, and knots (defined below); display attributes govern other aspects of the display, such as whether or not a vertex is highlighted. Both internal and external representations of graphs record all attributes with each vertex and edge so both the logical and physical representation of a graph can easily be reconstructed. (Note: The internal representation is what GDR stores while executing, external is what GDR writes to a file at the request of the user.)

Vertices and edges have labels that may contain arbitrary character strings. Labels are logical attributes since they are used for such things as the distance or cost of an edge. But the label of an edge also has geometric and display attributes: its position relative to the two endpoints of the edge and whether the label is exposed or hidden.

GDR allows graphs to have multiple edges between the same end- points. Since multiple edges cannot all be represented by straight lines, each edge is displayed as 3 line segments (which are coUinear when the edge is a straight line). The two intermediate points, called knots, are

The availability of only one function is not really limiting since animat can create its own popup windows to interact with the user, and could even supply a menu of different programs to execute.

included among the geometric attributes of an edge. Knots can be moved any time under user or program control.

A user interacts directly with GDR via an interface that allows cre- ation and editing of graphs, either directed or undirected. The current interface was designed for simplicity and ease of use. On the left side of the GDR window is the panel, where the user, by pointing to one of the entries and clicking left, can select the current editing mode. The mode determines GDR7s response to mouse clicks or keystrokes in the display, the part of the window where the graph is drawn. For example, when in CREATE VERTEX mode, GDR puts a new vertex in the display at the position of each left click (if there already is a vertex at that position, the user is prompted to try again). A typical sequence used in the creation of new graphs is to create all vertices first, enter CREATE EDGE mode to create edges, then enter EDIT LABEL mode to put text in the labels of vertices and edges. MOVE and DELETE modes allow for the repositioning or deletion of objects already in the display.

The user can invoke other commands via a pop-up menu, activated by depressing the right mouse button. These include saving the graph in a file, reading a file containing a graph, and executing the animation. The more frequently used commands have keystroke synonyms to allow "canned" animations for classroom demonstrations to be executed with- out use of a mouse.

Access to graphs created by GDR may be either external or internal. External access is provided via the file created when a graph is saved. The format of this file can easily be read by another program implement- ing a graph algorithm (it provides an adjacency list for each vertex and additional information about labels, geometric attributes, and display at- tributes). There is also a procedure that prints only the logical attributes of the graph in an easy-to-use format (graphical information is omitted).

Internal access to the graph occurs when the animation (the program compiled and linked with GDR) is executed via the RUN FILE menu com- mand. The paradigm for accessing the graph is edge oriented [6], meaning that each vertex has access to a list of its incident edges (and multiple edges and loops are allowed). GDR supplies definitions of ver tex and edge types as well as procedures and macros for accessing various at- tributes.

Routines that modify display attributes are the key to successful an- imations. The current implementation classifies edges and vertices as be- ing highlighted or unhighlighted (vertices have white background if high- lighted, black if unhighlighted; segments for edges are thick if highlighted, thin otherwise). Labels on vertices and edges can either be exposed (ap-

pearing in the display) or hidden (not in view). Actions of the algorithm can also be displayed by changing edge and vertex labels.

Other routines were added to enhance the ability to design anima- tions for classroom and individual student use. For example, there are routines that cause a vertex or edge to blink. There is also a facility for stopping the animation and returning control to the editor (to allow the user to rearrange the display or even to modify parts of the graph that have not yet been accessed). The points at which the animation is suspended are determined by the program, via a call to the procedure suspend-animation. The user returns control to the animation by exit- ing the editor.

3. Algorithm animation

Because of GDR7s simple design, uncomplicated graphics, and natural programming interface, we have been able to implement a wide variety of animations. Except for the DFA minimization discussed below, each of these has taken only an hour or two of programming effort. The extra effort in case of DFA minimization was required to understand the algo- rithm, particularly the implement ation tricks needed to achieve the time bound, not in designing or implementing the animation.

Among the animations implemented are Prim's minimum spanning tree algorithm (with edge labels interpreted as costs), depth-first search for both directed and undirected graphs, a biconnected components algo- rithm, simulators for deterministic and nondeterministic finite automata, a DFA minimization algorithm, and some tools to test heuristics for em- bedding trees into hypercubes.

3.1. Directed depth-first search. Our animation of depth-first search is based directly on the description of Cormen et al. [4] Unvisited vertices are white, vertices on the stack are "gray" (white with exposed label), and vertices whose visit is completed are black. Vertex labels show two numbers, the time stamps of the beginning and end of the visit (corresponding to preorder and postorder numbering). Tree edges are highlighted and other types of edges are labeled C for cross, F for forward, and B for back.

Textbook illustrations often unwittingly give the impression that a DFS tree of a graph is unique. One advantage of the animation is that students can experiment with different starting vertices for the search and with different sequences of edges in the adjacency lists to obtain different DFS trees for the same graph. The outer loop of the algorithm prompts

FIG. 2. Directed depth-first search animation.

the user for a starting vertex each time the top level of the recursive search routine returns, as is shown in Figure 2. Vertices 4 and 5 are unreachable from the search that began at vertex 0. The order of unvisited edges on an adjacency list can be changed any time the animation pauses by simply deleting and reinserting edges in the desired order.

3.2. DFA minimization. As an example of a more complicated animation (complicated only because the algorithm is non-trivial), the first author implemented a variant of the O(n log n) DFA minimization algorithm [7]. Implementation took about 12 hours total time and was greatly speeded up by the use of GDR as a debugging tool.

The DFA minimization animation first prompts the user to either draw a DFA or read one from a file (pausing until the user signals com- pletion). Edge labels indicate transitions. Then the DFA is checked for consistency: does every state have outgoing transitions on the same set of symbols, exactly one transition per symbol? Errors are identified graph- ically and the user is given the opportunity to correct them before the animation proceeds. In the next phase the user is prompted to identify final states by highlighting them (or states that are already highlighted can be unhighlighted). Finally, the actual minimization algorithm takes over.

The algorithm works by successively refining the partition of states into equivalence classes (based on the Myhill-Nerode theorem). Initially, the final states are in one class and the nonfinal states in another. At each iteration, the algorithm identifies two equivalence classes, Cl and Cz, and

a symbol a such that some states in Cl have transitions to a state of C2 on a and some do not. Then Cl is split into two classes: states that go to C2 on a and those that do not. The O(n1ogn) time bound requires that only the incoming arcs to C2 are processed and that when Cl is split, only the smaller of the two new partitions is considered as a candidate for C2 later. Throughout the animation, vertex labels show the equivalence class to which each state belongs. At the end, the algorithm chooses a representative state from each class and redraws the automaton with only the representative states shown.

Figures 3 and 4 show the animation for an example taken from the Martin text [12, p. 1271. In Figure 3, class 0 is about to be split into two classes. The states that will become part of the new class 2 are marked with *'s (before the pause, the edges processed by the algorithm, in this case those going into class 1 on symbol a, are blinked). No further refinement occurs and the final automaton is shown in Figure 4.

4. Future work

This section discusses existing and anticipated extensions to GDR. Some of these were part of the original design, but their implementation was deferred in the interest of rapid development of a working prototype. Others were conceived as the development of animations using GDR led us to envision new possibilities.

4.1. Vtview. One spinoff tool based on GDR is VTVIEW [15], a graphical editor that supports the modular design and analysis of concur- rent systems such as communications protocols. The tool allows users to define hierarchically organized networks of finite-state machines. In con- trast with other graphical design tools [ll, 131, VTVIEW provides a true abstraction and modularization mechanism while permitting bottom-up as well as top-down system design.

As VTVIEW is intended to be be interfaced with other tools (such as the Concurrency Workbench [3]) for analyzing and verifying concurrent systems, its design follows the same object-oriented design strategy as GDR. This ensures that programmers desiring to build systems that in- terface with VTVIEW need not know the specifics of the data structures used to represent networks. VTVIEW is also highly portable. The system is implemented in C and uses the Motif widget set in conjunction with X-windows to provide the graphic features available to the user.

4.2. Aesthetics. The need to improve the aesthetics of GDR arises both from a desire to create more sophisticated animations and from the

FIG. 3. DFA minimization i n progress.

FIG. 4. DFA minimization completed.

use of GDR as a graph editor to create pictures of graphs for articles and reports. Possible enhancements fall into three categories (in ease- of-implementation order starting with easiest): new editing capabilities, new graph attributes, and automated drawing features.

Examples of new editing features are the ability to align vertices, options on size of vertices and thickness of edges (with defaults taken from a configuration file), use of splines for edges that are not straight lines, and the ability to copy and move user-specified subgraphs. New attributes include the use of multiple colors (or shadings) for vertices, edges, and labels and the use of more than two knots. Automated draw- ing features include such issues as better heuristics for the placement of labels and knots (the current implementation occasionally places labels on top of each other or creates a line segment for a new edge on top of an existing one), and automatic placement of new vertices. Tools that create aesthetically pleasing drawings from logical descriptions of graphs (see Di Battista et al. [5] for a survey) could interact with GDR via the GDR file mechanism described in the next subsection.

4.3. GDR files. GDR communicates with other programs via a simple ASCII file format that records all attributes of a graph. Pro- cedures that access or modify GDR files can be written using the same object-oriented approach that is used for the internal representation of graphs (GDR itself, without its interactive part, could be used to write filter programs to modify GDR files).

Further development of the GDR file format and tools that manipu- late GDR files is motivated by three considerations. First, GDR files can be used to capture a sequence of stills from the execution of an anima- tion. The stills can either be viewed later or printed (although a GDR-to- Postscript translator has not yet been developed). Second, GDR can be used as an editor of graph drawings for documents. This would probably require the recording of additional information in GDR files as well as the development of "style files" to allow customization of such attributes as thickness of edges. Finally GDR files can serve as a convenient mechanism for compact storage of graphs and their drawings. This could spur the development of tools to modify the logical or physical structure of graphs stored in such files (analogous to the variety of Unix tools for text files).

4.4. Object-oriented approach. While tools written in languages other than C can interact with GDR via GDR files, direct interaction with the internal representation of a graph in GDR is limited to C programs compiled and linked with GDR. This choice was prompted by a need to develop a working prototype quickly. The original vision, GDR as an

independent process that interacts with other programs via messages, re- quires further study. The advantages of such a "pure" object-oriented approach are clear: animations could be coded in any language as long as the appropriate message protocol was used, GDR could interact with sev- eral programs simultaneously, or one program could interact with several GDR displays (for example, to animate actions on a graph and an auxil- iary data structure at the same time). The primary disadvantage is the difficulty of implementing a communication scheme among independent processes (while still retaining the portability of GDR).

4.5. Portability. The current implementation of GDR, because of its use of ordinary C and plain X-Windows, can easily be ported to most Unix-based workstations (so far we have only tested this for DEC and Sun workstations). A feature of GDR that suggests portability to graphical user interfaces other than X-Windows is the simplicity of the routines that access and modify the display of the graph. It is likely that these access routines could be rewritten for adaptation to, for example, a Macintosh environment. Some rearrangement of the current code would be desirable to isolate the parts that interact directly with X-Windows. This would entail defining a higher-level portable user interface for simple graphical interactions.

5. Conclusion

We have presented an object-oriented graph editing and animation tool and illustrated both its present capabilities and future possibilities. A variety of algorithm animations have been implemented for classroom use, and GDR has been used as a research tool. GDR7s interfaces with the user, the programmer, and with other tools have proven to be flexible and easy to use.

Throughout this overview we have emphasized GDR7s properties as a tool rather than a system. The overall vision we wish to articulate is analogous to that of the software tools for text processing developed by Kernighan and Plauger [8]. As a general-purpose text editor is central to any collection of text-processing tools, so the graph editing capabilities of GDR allow it to play an important role in the development of graph- processing tools. In graph processing, there is the additional need to visualize operations, and GDR7s animation capabilities serve as a testing, debugging, and interactive viewing facility for other tools.

REFERENCES

[l] J. Abello, S. Sudarsky, J. Waller, and T. Veatch. AGE: An animated graph environment. In Proc. DIMACS Workshop on Computational Support for Discrete Mathematics. American Mathematical Society, 1993.

21 B. Birgisson and G. E. Shannon. GraphView: An extensible interactive platform for manipulating and displaying graphs. Technical Report 295, Computer Science Department, Indiana University, December 1989.

[3] R. Cleaveland, J. Parrow, and B. Steffen. The Concurrency Workbench: A semantics-based tool for the verification of finite-state systems. ACM Trans- actions on Programming Languages and Systems, 15(1):36-72, January 1993.

[4] T. H. Cormen, C. E. Leiserson, and R. L. Rivest. Introduction to Algorithms. MIT Press, 1990.

51 G. Di Battista, P. Eades, and R. Tamassia. Algorithms for drawing graphs: An an- notated bibliography. Available by anonymous ftp from wilma. cs .brown. edu: files /pub/gdbiblio . tex. Z and /pub/gdbiblio .ps . Z, March 1993.

61 J. Ebert. A versatile data structure for edge-oriented graph algorithms. Commu- nications of the ACM, 30(6):513 - 519, 1987.

71 J. E. Hopcroft. An n log n algorithm for minimizing the states in a finite automa- ton. In Z. Kohavi, editor, The Theory of Machines and Computations, pages 189-196. Academic Press, 1971.

[8] B. W. Kernighan and P. J. Plauger. Software Tools. Addison-Wesley, 1976. [9] M. S. Krishnamoorthy, A. Suess, M. Onghena, F. Oxaal, and T. Spencer. Im-

provements to Graphpack: A system to manipulate graphs and digraphs. In Proc. DIMACS Workshop on Computational Support for Discrete Mathemat- ics. American Mathematical Society, 1993.

[lo] V. J. Leung, M. B. Dillencourt, and A. L. Bliss. GraphTool: A tool for interactive design and manipulation of graphs and graph algorithms. In Proc. DIMACS Workshop on Computational Support for Discrete Mathematics. American Mathematical Society, 1993.

[ l l ] J. Malhotra, S.A. Smolka, A. Giacalone, and R. Shapiro. Winston: A tool for hierarchical design and simulation of concurrent systems. In Proceedings of the Workshop on Specification and Verification of Concurrent Systems, Stirling, Scotland, 1988.

[12] J. C. Martin. Introduction to Languages and the Theory of Computation. McGraw-Hill, Inc., 1991.

[13] V. Roy and R. de Simone. AUTO/Autograph. In Computer-Aided Verification '90, pages 477-491, 1990.

[14] M. Stallmann, R. Cleaveland, and P. Hebbar. GDR: A visualization tool for graph algorithms. Technical Report 91-27, Department of Computer Science, North Carolina State University, Raleigh NC 27695-8206, October 1991.

[15] Vikas Trehan. VTVIEW: A graphical editor for hierarchical networks of finite- state processes. Master's thesis, Dept. of Computer Science, North Carolina State University, 1992.

E-mail address: matt@euler . csc .ncsu. edu or Matt_Stallmann@ncsu. edu