Applying Algorithm Animation Techniques for Program Tracing, Debugging, and Understanding

Sougata Mukherjea, .John T. Stasko Graphics, Visualization and Usability Center, College of Computing Georgia Institute of Technology Atlanta, GA 30332-0280

Abstract “software visualization” is better because it is more general, encompassing visualizations of data struc- Algorithm antmation, which presents a dynamic vi- tures, algorithms, and specific programs. In fact, soft- sualization of an algorithm or program, primartly has ware visualization research primarily has concentrated been used as a teaching aid. The highly abstract, on two different subtopics: data structure display and application-specific nature of algorithm animation re- algorithm animation. quires human design of the animation views. We spec- Data structure display systems such as Incense[13], ulate that the application-specific nature of algorithm GDBX[3], and VIPS[l 1, 17] illustrate particular data animation views could be a valuable debugging aid for structures within a program, showing both the val- sofiware developers as well. Unfortunately, zf ani- ues and interconnections of particular data elements. mation development requires time -cons urntng des~gn These systems automatically generate a view of a with a graphics package, zt wdl not be used for de- data structure when the user issues a command to bugging, where timeliness is a necessity. We have de- do so. Other systems such as Pecan[16] provide ad- veloped a system called Lens that allows programmers ditional program state views of control flow, the run- to rapxdly (m mtnutes) butld algorithm animation - time stack, and so on. Data structure display systems styie program views wtthout requiring any sophisticated main application has been for debugging and software graphzcs knowledge or codtng. Lens is integrated with development. Commercial systems such as Borland a system debugger to promote iterative design and ex- C for PCS and CodeVision for SGI workstations even ploration. provide rudimentary data structure display capabilities within a software development environment. Algorithm animation, the second main subarea of 1 Introduction software visualization, provides views of the funda- People invariably have a difficult time understandi- mental operations of computer programs, concentrat- ng abstract concepts or processes. One way to im- ing more on abstractions of behavior than on a par- prove understanding is to provide specific examples, ticular program’s implementation[5]. The views pre- possibly using pictures to make an abstract concept sented are much more application-specific than the more concrete. The expression “Seeing is believing” generic views of data structure display systems. The relates that what we can visualize, we can grasp and movie Sorting out ,Sorting~2] motivated many of the understand. subsequent algorithm animation software systems that This notion can be applied to software under- have been developed, including Balsa[6], Animus[7], standing and the use of graphics and visualization Movie[4], and Tango [19]. In all these systems, a de- to depict computer algorithms and programs. Soft- veloper first designs a visual presentation for an al- ware visualization provides concrete representations gorithm, and then implements the visualization using to previously inanimate, abstract entities that have a support graphics platform. To date, the primary always been, and most likely always will be, rela- use of algorithm animations has been for teaching and tively difficult to understand. The use of graphics instruction. for illustrating software was originally called program Because algorithm animation views are complex msua~izatiun[l, 14, but more recently the term sofi- user-conceptualized depictions, they cannot be cre- ware visua/ization[15, 22] has been favored. The term ated automatically from a “black-box” program illus-

456 0270-5257/93 $03.00 @ 1993 IEEE trator. Rather, an animation designer crafts a par- of data structures, such as showing a clock face to rep- ticular view that is specifically tailored for a program. resent integer values hours and minutes. This design, Consequently, designing algorithm animations is time- however, requires writing the low-level graphics code intensive and usually restricted to already working to implement the view. programs. That is, a designer utilizes a fully func- The algorithm animation system Movie[4] focuses tional working program, designs a set of animation on rapid development of relatively straightforward al- routines for its visualization, and maps the program gorithm visualizations. The system provides a few to the corresponding routines. The resulting views simple commands which can be used to quickly de- can then be used as instructional aids for illustrating velop a visualization of a program in order to under- the program’s methodologies and behaviors. [Unfor- stand it better. Programmers still must learn the sys- tunately, the time and effort required to develop an- tem’s commands, however, and the system does not imations is considerable enough to limit their use to support smooth, continuous animation effects. pedagogy and preclude their use in software develop- The Gestural system[8] supports purely graphical ment and debugging. A programmer will not use a animation development on Smalltalk programs, but its tool for debugging whose development time outweighs only images are black rectangles and its only actions that to simply debug a program with traditional text- were movements following mouse-traced paths. based methods. The Dance system[20] allows developers to graph- This fact is unfortunate, however, because algo- ically build algorithm animations, then it generates rithm animations could offer key benefits to program the corresponding Tango[l 9] animation code to carry debugging and testing. The use of pictures to illus- out the specified actions. Unfortunately, programmers trate how programs work has always played an im- still must learn the underlying animation paradigm portant role in software engineering. Programmers, of Tango to develop views of algorithms or pro- in designing code, often implicitly construct a mental grams. Also, animation designs cannot be incremen- model of their program, how it should function, how it tally tested. The code must be generated, compiled, utilizes data, and so on. It is much easier for people to and run, but the design cannot be read back into the think in terms of these higher level abstractions (the system for modifications. big picture) than to try and comprehend how all of the The University of Washington Program individual operations and data work in c.onjunction— Illustrator[IO] truly requires no designer input to gen- particularly so for larger systems. Data structure dis- erate an algorithm animation. It analyzes program play systems, which have already been utilized in de- source code and produces its own abstract depiction. buggers, can only offer views of raw data; the notion The system was only developed to analyze sorting and of an overall picture does not exist there. Algorithm graph algorithms, however, using one particular style animations, conversely, offer views of a program’s ap- of view for each. Building an automatic “black-box” plication domain and semantics. These types of views algorithm animation style viewing tool for arbitrary can be critical for determining why a program is not programs appears to be an impossible task because performing in its desired manner. of the infinite number of different possible algorithms In particular, the use of animation is extremely and depictions. important because programs are fundamentally dy- Our work seeks to bridge the two domains of namic. Illustrating program data and states is use- data structure display and algorithm animation as ful for understanding, but illustrating how the pro- shown in Figure 1. We want a system that can program changes from state to state and evolves over vide application-specific animation views for debug- time is even more helpful. Consider developing a com- ging purposes. Unlike the UWPI system, we still want putational geometry program, a quicksort, a particle programmers to design their own animations. We do chamber simulation, or a graph colorability algorithm. not want to require the programmers to need to learn Would it not be extremely advantageous to have a dy- a graphics toolkit and write code using it, however. namic visualization of the program to watch during WJealso want our tool to work in conjunction with a program testing in order to see how it is working and debugger so that animation can be incrementally de- to help identify erroneous program actions? veloped without going through the edit-compile-run Particular systems have taken steps toward this cycle. merge of data structure display and algorithm anima- This work addresses the tail-end of the software de- tion. The data structure display system Incense[13] velopment pipeline, when a designer has already writ- allows developers to design their own abstract views ten portions of, or perhaps all of, a target program or

457 mastered. Raw data views Application-specilic generated user-defined To develop this kernel, we studied over 40 algorithm automatically y program views animations built with the XTango system[2 1]. The ‘Ihi.s work animations’ topics included sorting, searching, graph, n + * tree, string and graphics algorithms, as well as animations of matrix multiplication, fft, hashing, producer- Data Structure Algorithm display animation c.onsumer problems, etc. These animations were built by over 25 different people, so they were not biased to a particular person’s design methodology. Figure 1: This work bridges the different areas of data The first step in this analysis was to determine structure display and algorithm animation, seeking to which types of graphical objects are commonly used in gain the benefits of both. algorithm animations, and also how the appearance of an object depends on the program it is representing. system. It is best-suited for high-level debugging, pro- Although XTango supports a wide variety of differ- gram testing, and refinement, not low-level debugging ent graphical objects, only lines (15 times), circles (11 typically focusing on correcting inadvertent lexical or times), rectangles (13 times) and text (17 times) com- syntactic misuses. Debugging has been characterized monly appeared. Other objects such as polygons or as the acquisition of clues to help programmers gener- ellipses appeared only O-2 times. ate hypotheses on why a program is not working[9, 12]. When one of these graphical objects is created in an Viewing program execution through dynamic visual- algorithm animation, its appearance usually depends izations is a clear, practical way to generate the clues on the state of the underlying program and the values which might be critical for correcting programs. of variables within the program. For instance, the . We have developed a system called Lens that al- position, size (length, width, height, radius) and label lows programmers to rapidly develop animations of (for text) all may depend upon program values. their programs. Lens supports application-specific se- For lines, we found that the position and size of the mantic program views as seen in many algorithm ani- line are its two attributes that vary. Position was ei- mation systems, but it does not require graphics pro- ther predetermined (no program dependence), depen- gramming. Lens is integrated with a system debug- dent upon the values of variables in the program, or ger to support iterative testing and refinement. In relative to other existing animation objects. Line size the remainder of this article, we describe the concep- was either predetermined or relative to other objects. tual model on which Lens is based, we illustrate how The rectangle attributes of position and size (width program animations are built with Lens, and we de- and/or height) varied across animations. Both were scribe some of the implementation challenges the sys- either predetermined or program variable dependent. tem presents. These specifications were the same for circles with the size attribute being the circle’s radius. Finally, text objects varied along position and text 2 Identifying the Essential Compo- string attributes. Text position was commonly either nents of Program Animations predetermined or dependent upon the location of some other graphical object. (Text is often used to label In building the algorithm animation debugging other objects. ) Text strings were either predetermined environment, we sought to provide a palette of or dependent upon program variables, commonly-used operations to developers for direct in- In addition to individual graphical objects, many vocation, rather than forcing developers to write an- of the algorithm animations manipulated rows or imation description code. We also sought to provide columns of objects. These structures were commonly a graphical editor for defining the appearance of pro- used to represent program arrays. In specifying a row gram variables. Most importantly, we wanted to keep of objects, designers would identify a bounding box in- the lists of operations and graphical editing operations side of which the individual objects were placed. The to a minimum of often-used directives. Rather than number of objects was either predetermined or depen- building a comprehensive environment which could dent upon the value of a variable. Often, one dimen- support any animation but which also included many sion of the objects, such as rectangles’ heights for a rarely used directives, we sought to build a compact row, varied according to the values of the variables in kernel of commands that could easily be learned and the array the row represented. Other attributes that

458 varied were the structure’s orientation (horizontal or To specify how the program animation should look, vertical) and the spacing between individual objects. a programmer chooses commands from the animation Table 1 lists a summary of all these graphical ob- menu above the source code. It has seven options that jects along with their program dependent attributes. correspond to the kernel of algorithm animation con- XTango animations also include the capability to stituents found in our study of algorithm animations: designate particular positions in the display window. 1) Create objects 2) Create location marker 3) Move These positions often serve as the destination points 4) Fill 5) Color 6) Flash 7) Exchange. of object movements. We found that this feature was When either of the first two commands is chosen, very commonly used, so we included it in the con- the programmer is prompted to enter the variable stituent set of capabilities for the new system. name of the object or location being depicted. The The second major step in identifying algorithm an- variable name is subsequently used to identify the ob- imation features was determining common actions or ject for the action commands. This is a key advantage changes that objects underwent after they were cre- of Lens: a programmer works in the context of fa- ated. In all the sample XTango animations examined, miliar program entities, not graphics objects. Lens only five actions occurred more than a few times. The then asks the programmer to use the graphical editor actions are to design the object or location’s appearance and/or position. This design is structured according to the ● Move an object to a particular position or to a position relative to another object. object specifications that were discovered in the ear- lier study. For example, when a line is created, its ● Change the color of an object. position can be specified using the mouse, it can be specified relative to another object (by name or by . Change the fill style (outline or filled) of an ob- picking a graphical object), or it can be specified to ject. relate to the value of a program variable. All these

● Make an object flash choices are made via a dialog box entry or by graphical direct manipulation. Finally, Lens asks the user to ● Make two objects exchange positions (a special click the mouse on the source code line at which ob- combination of movement actions). ject or location creation should occur. Lens indicates the presence of animation commands by showing an After completing this survey, we organized these ‘A’ beside the code line. sets of graphical objects and common animation actions into a kernel of capabilities to be used as the ba- When a programmer chooses one of the five action sis for the graphical debugging system. our intention commands, Lens asks for the name of the variable, was to allow designers to instantiate objects graphi- and consequently graphical object, to which the ac- cally and to select animation actions through a set of tion should apply. The programmer simply types in a menu-based commands. variable name such as x or a [i] and Lens notes the choice. Finally, the programmer must select the source code line on which to place the command. Multiple animation commands can be placed on single lines. 3 Interacting with Lens When the programmer wishes to execute the pro- The Lens system is a prototype implementation gram and see its animation, he or she chooses the that provides access to the kernel of capabilities we “Run” command from the Debug menu. Lens then identified. In this section we describe how program- pops up an animation window and displays the ani- mers interact with the Lens system. To begin a visual mation that corresponds to the programmer’s design debugging session, a programmer issues the command, and this particular execution. Lens uses the routines “lens foo”, where foo is the name of an executable pro- from the XTango system to generate the animations gram. After start-up, the user selects an initial source it presents. file to view, then Lens loads and displays this source If the animation is not sufficient or not what the and awaits the entry of animation commands. (Other programmer wanted, the programmer can go back, source files can be loaded via a menu command.) The add or delete animation commands, and rerun the an- entire Lens display appears as shown in Figure 2. The imation. Lens also supports saving animation com- left area presents program source code, and the right mands bet ween sessions, so that program debugging area is the graphical editor for designing objects’ ap- can be resumed at a later time using the same anima- pearances. tion context.

459 Object Attribute Specification(s) . Line Position Predetermined Relative to another object Program variable dependent 5“, lze Predetermined Relative to another object

Rectangle Position Predetermined Program variable dependent Width, height Predetermined Program variable dependent

Circle Position Predetermined Program variable dependent Radius Predetermined Program variable dependent

Text Position Predetermined Relative to another object String Predetermined Program variable dependent

Object array Position Predetermined (bounding box) Number Predetermined Size Predetermined Program variable dependent

Table 1: Summary of graphical objects commonly used in XTango algorithm animations and how their attributes are specified. “Predetermined” means that the designer provided a value which remained constant.

Building a Sample Animation The final annotation corresponds to an Exchange command. The programmer specified that objects LJsing Lens, it is straightforward to build program a[i] and a[i+t] be swapped. Lens will illustrate a animations in minutes. Figure 2 shows the source and smooth interchange motion for this command. placement of three animation commands for building a Figure 3 illustrates the view of this animation spec- bar-chart style bubblesort animation view commonly ification and a frame from the resulting animation. depicted in algorithm animation systems. With a few more simple Color and Fill commands, The first annotation is a Create Object command. the animation can be refined further. The programmer created an appearance for the variable named a. He specified a rectangle array presentation, drew a bounding box for it, selected a horizontal 4 System Implementation orientation, and specified that the number of objects is dependent upon the value of the variable n. Finally, The creation of the Lens system presented a number the programmer provided sample minimum and maxi- of interesting challenges. In this section we highlight mum values for the array elements. Lens requires this a few of the most important ones. information to scale the heights of rectangles. The second animation annotation corresponds to 4.1 Interaction with dbx two animation commands, both of Flash type. The programmer specified that the objects corresponding To acquire information about the program that is to a [i] and a [i+l] be flashed to indicate a compari- being run, Lens establishes a connection with the dbx son in the program. debugger. The interface with dbx is similar to the

460 Ilcu al=”” I Ilm++l C+l-. -.w+b. m +Uu l-u 3 P**v--- m- .+ .+

, ------, # 1 1 1 1 1 I I 1 # 1 I I 1 I 1 I t I 1 I t I I 1 t # I i I I 1 1 i t 1 t I t 1 1 t i 1 1 I 1 8 1 I 1 I I I I 1 ! 1 I 1 I f I t I I t t I 1 1 1 .------

Figure2: Lens display presented to a programmer. The left section shows source and the right section is the graphical editor.

461 El ,,!,.,,,,.,,.,,,.,, ”,,,,,”, A] ,,,,,,!,,,,,,,,,,,.,.,,, !,.,,

7,!$>.. !,,!,,, ,,,-”, ”,,,.

,,,,,,,,,,,, ”,,,,.”,,,,,,,,,..

Figure 3: Frame from the bubblesort animation built using Lens and three animation commands. The buttons to the left provide panning and zooming. The scrollbar to the right controls the animation speed.

462 approach used by the program xdbx. Lens communi- be an integer, double, short, long or float. cates with dbx through a pseudo terminal that is a Lens also must be flexible in its interpretation of pair of master and slave devices: /dev/pty?? and animation actions. If a programmer chooses a Move /dev/tt y??. The pty is opened for both reading and command, he or she can specify the name of another writing. After a child process is created via fork, the program entity which should be the destination of the child process closes the master side of pty, redirects movement action. This entity can be either a location stdin, stdout and stderr of dbx to pty, unbuffers out- or a graphical object. Lens must make this determi- put, data from dbx, and execs dbx. The parent process nation, and if it is an object, use the object’s current closes the slave side of pty, sets the clbx file pointer to position as the destination point. nonblocking mode, opens the file pointer to read/write The Exchange animation requires the user to spec- access to dbx, sets line buffered mode, and then mon- ify the variables for the two objects (they cannot be lo- itors the output from and passes input to dbx. cations) that are to be exchanged. The Flash, Change When the user commands Lens to create an ani- Fill and Change Color animations require the user to mation action, the parent sends a stop at command to specify the variable for the image on which the action dbx. Later, when the program is executing and dbx is to take place. The Change Color animation also stops at that line, the parent executes the animation requires the user to select a color from a palette of action that was specified at the line. The parent also colors that is displayed. All these animation actions may acquire other information from dbx; for example, may be applied to an object or location that is an ar- if the value of a variable is required, a print command ray element. For example, the user may specify that is passed to dbx, and if the type of a variable is re- elements a [i] and a[i+l] should be exchanged. To quired, a what is command is passed to clbx. If dbx handle this situation, Lens must first check whether passes an output, the parent processes it and takes the there is a ‘[’ in the variable name. If so, it checks to appropriate action. For example, if the program that see if the variable specified before the ‘[’ refers to an is being debugged has an error and dbx sends an error array. If not, it will signify an error and reject that message, the parent will display the error message for animation. Otherwise, during the actual animation the user and halt the execution of the program. If dbx execution, it will get the value of the array index (it sends an output which the parent does not recognize, may be a constant, variable or a simple expression) the parent assumes that the output is from the pro- and use that index to acquire the appropriate graphi- gram itself and outputs it for the user to see. Thus, cal object or location. Fundamentally, Lens must co- the overall structure of the Lens system is shown in ordinate and manage the mappings between program Figure 4. entities and graphical objects.

4.2 Specifying the Animation Actions 4.3 Executing the Animations

In order to make the specification of animation ac- After the programmer has built all the animations tions as easy as possible for the programmer, Lens and wants to run the program, Lens must dispatch a requires some subtle internal manipulations. For ex- run command to dbx. Before it does that, however, ample, when a programmer types in the target for a Lens goes through the list of animations (the anima- command such as Color, the programmer simply en- tions are kept in a linked list) and sends a stop at ters a text string such as bl at a dialog prompt. Lens command to dbx for each animation at the appropri- resolves this entry into an internal database of objects ate line. One unique feature of dbx is its assignment of and locations that already has been created. Lens also line numbers to the logical file that are different from must alert the programmer to syntactic errors made the actual line numbers of the source text file. This at this level. is due to blank lines and statements stretching over If an object’s attribute is dependent on a program more than one line. Therefore, if one passes a stop variable, the system asks the user to specify its max- at n command to dbx, the line number that dbx ac- imum and minimum value in order for Lens to scale tually stops at may be different from n. Fortunately, the object appropriately during the actual animation. dbx returns the line number where it will stop given Another point worth mentioning is that when the user a particular stop at request. Lens uses this value and chooses a variable, the system checks the type of that stores it for subsequent specifications. variable and rejects the animation action if the vari- When dbx stops at a particular break point and able is not of the appropriate type. For example if a send a message to Lens, the system scans the list position is dependent on a variable, the variable must of animation commands to find out the command(s)

463 The Lens System

* Child Process Pnrent Ihxess 4 Output from dbx

(Runs the sninmtion sdions, @UIS dbx, controls user interaction) exeeutes the progrnm)

Figure 4: Lens system configuration illustrating how the various processes communicate with each other. which caused the break point. When it finds the com- ● Allow users to examine animation commands that mand(s), it executes the action(s) specified there. For have been registered in the program source. Cur- this, it may need to send other messages to dbx, for rently, we simply indicate the presence of anima- example, print z if the attribute of an object, such as tion commands by the ‘A’ annotation. its width, depends on the variable i. It is possible that the program being debugged re- ● Provide full dbx command capabilities to the user quires some input from the user via stdin. In Lens, so that s/he can interact with the execution more. dbx gets all its input from the parent process which was established. Hence, the parent must set its input ● Add traditional data structure display capabili- to non-blocking mode and constantly poll the exter- ties to the system for further debugging support. nal input buffer. If there is ever any user input, Lens passes it on to dbx. ● Perform empirical tests to examine the usability of Lens’ interface, and most importantly, to better understand how Lens can be utilized in program 5 Future Plans debugging.

All of the capabilities described in this article have Currently, our work with Lens is at the proof of been implemented and are functional. Lens is cur- concept phase. We wanted to address the challenge of building a program animation system that requires rently running on Sun workstations under Xl 1 and no coding nor any knowledge of a graphics paradigm, Motif. Our future plans involve continued development and refinement of Lens and its interface. In par- and that is integrated with a system debugger. We ticular, we hope to believe that Lens meets this challenge. Now, we must examine the system and understand its strengths and Q Improve the somewhat “clunky” user interface weaknesses as a debugging and tracing aid. In partic- for specifying object appearances and binding ular, a number of questions remain: To what level of these representations to program entities. Cur- complexity in a program is Lens sufficient for building rently, much of this interaction occurs through an animation? Are the kernel of primitives enough? dialog boxes. We plan to utilize more of a direct If not, what should be added? Can higher level, inte- manipulation[18] approach. Two possibilities for grated animation templates be added? improvement are choosing program variables by We expect to make Lens available via anonymous selecting them with the mouse from the program ftp soon, and we hope that feedback from its use along text, and specifying graphical “connection links” with future empirical studies helps us to better under- between graphical attributes (height, size, posi- stand the possible role of visualization and animation tion) and program variables. in program development and debugging.

464 Acknowledgments [11] Sadahiro Isoda, Takao Shimomura, and Yuji One. VIPS: A visual debugger. IEEE Software, 4(3):8- This work supported in part by the National Sci- 19, May 1987, ence Foundation under contract CCR-9109399. [12] Irving Katz and John Anderson. Debugging: An analysis of bug location strategies. Human- Computer Interact~on, 3(4):351-399, 1987. References [13] Brad A. Myers. A system for displaying data [1] Ronald M. Baecker. An application overview of structures. Computer Graphics: SIG GRAPH ’83, program visualization. Computer Graphics: SIG- 17(3):115-125, July 1983. GRAPH ’86, 20(4):325, July 1986. [14] Brad A. Myers. Taxonomies of visual program- p2] Ronald M. Baecker and David Sherman. Sorting ming and program visualization. Journal of Out Sorting. 16mm color sound film, 1981. Shown Visual Languages and Computing, 1(1):97-123, at SIGGRAPH ’81, Dallas TX. March 1990.

[3] David B. Baskerville. Graphic presentation of [15] Blaine A. Price, Ian S. Small, and Ronald M. data structures in the DBX debugger. Technical Baecker. A taxonomy of software visualization. Report UCB/CSD 86/260, University of Califor- In Proceedings of the 25th Hawaii International nia at Berkeley, Berkeley, CA, October 1985. Conference on System Sciences, volume II, pages 597-606, Kauai, HI, January 1992. [4] Jon L. Bentley and Brian W. Kernighan. A system for algorithm animation. Computing Sys- [16] Steve P. Reiss. Pecan: Program development systems, 4(l), Winter 1991. tems that support multiple views. IEEE Transac- tions on Software Engineering, SE-11(3):276-285, [5] Marc H. Brown. Perspectives on algorithm ani- March 1985. mation. In Proceedings of the ACM SIGCHI ’88 Conference on Human Factors in Computing Sys- [17] Takao Shimomura and Sadahiro Isoda. Linked- tems, pages 33-38% Washington D. C., May 1988. list visualization for debugging. IEEE Software, 8(3):44-51, May 1991. [6] Marc H. Brown and Robert Sedgewick. Tech- Direct manipulation: A niques for algorithm animation. IEEE Software, [18] Ben Shneiderman. Computer, 2(1):28-39, January 1985. step beyond programming languages. 16(8):57-69, 1983. [7] Robert A. Duisberg. Animated graphical inter- [19] John T. Stasko. TANGO: A framework and faces using temporal constraints. In Proceedings system for algorithm animation. Computer, of the ACM SIGCHI ’86 Conference on Human 23(9):27-39, September 1990. Factors in Computing Systems, pages 131–136, Boston, MA, April 1986. [20] John T. Stasko. Using direct manipulation to build algorithm animations by demonstration. In [8] Robert A. Duisberg. Visual programming of program visualizations. A gestural interface for an- Proceedings of the ACM SIGCHI ’91 Conference on Human Factors in Computing Systems, pages imating algorithms. In IEEE Computer Socz- 307-314, New Orleans, LA, May 1991. ety Workshop on Vtsual Languages, pages 55–66} Linkoping, Sweden, August 1987. [21] John T. Stasko. Animating algorithms with XTANGO. SIGACT News, 23(2):67–71, Spring [9] J. D. Gould. Some psychological evidence on how 1992. people debug computer programs. International Journal of Man-Machine Studies, pages 151-182, [22] John T. Stasko and Charles Patterson. Under- 1975. standing and characterizing software visualization systems. In Proceedings of the IEEE 1992 [10] Robert R. Henry, Kenneth M. Whaley, and Bruce Workshop on Visual Languages, pages 3–10, Seat- Forstall. The University of Washington illustrat- tle, WA, September 1992. ing compiler. Sigplan Notices: SIGPLAN ’90, 25(6):223-233, June 1990.

465