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

Transcription

1 Applying Algorihm Animaion Techniques for Program Tracing, Debugging, and Undersanding Sougaa Mukherjea,.John T. Sasko Graphics, Visualizaion and Usabiliy Cener, College of Compuing Georgia nsiue of Technology Alana, GA Absrac Algorihm anmaion, which presens a dynamic visualizaion of an algorihm or program, primarly has been used as a eaching aid. The highly absrac, applicaion-specific naure of algorihm animaion requires human design of he animaion views. We speculae ha he applicaion-specific naure of algorihm animaion views could be a valuable debugging aid for sofiware developers as well. Unforunaely, zf animaion developmen requires ime -cons urnng des~gn wih a graphics package, z wdl no be used for debugging, where imeliness is a necessiy. We have developed a sysem called Lens ha allows programmers o rapxdly (m mnues) buld algorihm animaion - syie program views whou requiring any sophisicaed graphzcs knowledge or codng. Lens is inegraed wih a sysem debugger o promoe ieraive design and exploraion. nroducion People invariably have a difficul ime undersanding absrac conceps or processes. One way o improve undersanding is o provide specific examples, possibly using picures o make an absrac concep more concree. The expression Seeing is believing relaes ha wha we can visualize, we can grasp and undersand. This noion can be applied o sofware undersanding and he use of graphics and visualizaion o depic compuer algorihms and programs. Sofware visualizaion provides concree represenaions o previously inanimae, absrac eniies ha have always been, and mos likely always will be, relaively difficul o undersand. The use of graphics for illusraing sofware was originally called program msua~izaiun[l, 4, bu more recenly he erm sofiware visua/izaion[5, 22] has been favored. The erm sofware visualizaion is beer because i is more general, encompassing visualizaions of daa srucures, algorihms, and specific programs. n fac, sofware visualizaion research primarily has concenraed on wo differen subopics: daa srucure display and algorihm animaion. Daa srucure display sysems such as ncense[3], GDBX[3], and VPS[l, 7] illusrae paricular daa srucures wihin a program, showing boh he values and inerconnecions of paricular daa elemens. These sysems auomaically generae a view of a daa srucure when he user issues a command o do so. Oher sysems such as Pecan[6] provide addiional program sae views of conrol flow, he runime sack, and so on. Daa srucure display sysems main applicaion has been for debugging and sofware developmen. Commercial sysems such as Borland C for PCS and CodeVision for SG worksaions even provide rudimenary daa srucure display capabiliies wihin a sofware developmen environmen. Algorihm animaion, he second main subarea of sofware visualizaion, provides views of he fundamenal operaions of compuer programs, concenraing more on absracions of behavior han on a paricular program s implemenaion[5]. The views presened are much more applicaion-specific han he generic views of daa srucure display sysems. The movie Soring ou,soring~2] moivaed many of he subsequen algorihm animaion sofware sysems ha have been developed, including Balsa[6], Animus[7], Movie[4], and Tango [9]. n all hese sysems, a developer firs designs a visual presenaion for an algorihm, and hen implemens he visualizaion using a suppor graphics plaform. To dae, he primary use of algorihm animaions has been for eaching and insrucion. Because algorihm animaion views are complex user-concepualized depicions, hey canno be creaed auomaically from a black-box program illus / EEE 456

2 raor. Raher, an animaion designer crafs a paricular view ha is specifically ailored for a program. Consequenly, designing algorihm animaions is imeinensive and usually resriced o already working programs. Tha is, a designer uilizes a fully funcional working program, designs a se of animaion rouines for is visualizaion, and maps he program o he corresponding rouines. The resuling views can hen be used as insrucional aids for illusraing he program s mehodologies and behaviors. [Unforunaely, he ime and effor required o develop animaions is considerable enough o limi heir use o pedagogy and preclude heir use in sofware developmen and debugging. A programmer will no use a ool for debugging whose developmen ime ouweighs ha o simply debug a program wih radiional exbased mehods. This fac is unforunae, however, because algorihm animaions could offer key benefis o program debugging and esing. The use of picures o illusrae how programs work has always played an imporan role in sofware engineering. Programmers, in designing code, ofen implicily consruc a menal model of heir program, how i should funcion, how i uilizes daa, and so on. is much easier for people o hink in erms of hese higher level absracions (he big picure) han o ry and comprehend how all of he individual operaions and daa work in c.onjuncion paricularly so for larger sysems. Daa srucure display sysems, which have already been uilized in debuggers, can only offer views of raw daa; he noion of an overall picure does no exis here. Algorihm animaions, conversely, offer views of a program s applicaion domain and semanics. These ypes of views can be criical for deermining why a program is no performing in is desired manner. n paricular, he use of animaion is exremely imporan because programs are fundamenally dynamic. llusraing program daa and saes is useful for undersanding, bu illusraing how he program changes from sae o sae and evolves over ime is even more helpful. Consider developing a compuaional geomery program, a quicksor, a paricle chamber simulaion, or a graph colorabiliy algorihm. Would i no be exremely advanageous o have a dynamic visualizaion of he program o wach during program esing in order o see how i is working and o help idenify erroneous program acions? Paricular sysems have aken seps oward his merge of daa srucure display and algorihm animaion. The daa srucure display sysem ncense[3] allows developers o design heir own absrac views of daa srucures, such as showing a clock face o represen ineger values hours and minues. This design, however, requires wriing he low-level graphics code o implemen he view. The algorihm animaion sysem Movie[4] focuses on rapid developmen of relaively sraighforward algorihm visualizaions. The sysem provides a few simple commands which can be used o quickly develop a visualizaion of a program in order o undersand i beer. Programmers sill mus learn he sysem s commands, however, and he sysem does no suppor smooh, coninuous animaion effecs. The Gesural sysem[8] suppors purely graphical animaion developmen on Smallalk programs, bu is only images are black recangles and is only acions were movemens following mouse-raced pahs. The Dance sysem[20] allows developers o graphically build algorihm animaions, hen i generaes he corresponding Tango[l 9] animaion code o carry ou he specified acions. Unforunaely, programmers sill mus learn he underlying animaion paradigm of Tango o develop views of algorihms or programs. Also, animaion designs canno be incremenally esed. The code mus be generaed, compiled, and run, bu he design canno be read back ino he sysem for modificaions. The Universiy of Washingon Program llusraor[o] ruly requires no designer inpu o generae an algorihm animaion. analyzes program source code and produces is own absrac depicion. The sysem was only developed o analyze soring and graph algorihms, however, using one paricular syle of view for each. Building an auomaic black-box algorihm animaion syle viewing ool for arbirary programs appears o be an impossible ask because of he infinie number of differen possible algorihms and depicions. Our work seeks o bridge he wo domains of daa srucure display and algorihm animaion as shown in Figure. We wan a sysem ha can provide applicaion-specific animaion views for debugging purposes. Unlike he UWP sysem, we sill wan programmers o design heir own animaions. We do no wan o require he programmers o need o learn a graphics oolki and wrie code using i, however. WJealso wan our ool o work in conjuncion wih a debugger so ha animaion can be incremenally developed wihou going hrough he edi-compile-run cycle. This work addresses he ail-end of he sofware developmen pipeline, when a designer has already wrien porions of, or perhaps all of, a arge program or 457

3 Raw daa views Applicaion-specilic generaed user-defined auomaically y program views hi.s work + n * Daa Srucure Algorihm display animaion Figure : This work bridges he differen areas of daa srucure display and algorihm animaion, seeking o gain he benefis of boh. sysem. is bes-suied for high-level debugging, program esing, and refinemen, no low-level debugging ypically focusing on correcing inadveren lexical or synacic misuses. Debugging has been characerized as he acquisiion of clues o help programmers generae hypoheses on why a program is no working[9, 2]. Viewing program execuion hrough dynamic visualizaions is a clear, pracical way o generae he clues which migh be criical for correcing programs. We have developed a sysem called Lens ha allows programmers o rapidly develop animaions of heir programs. Lens suppors applicaion-specific semanic program views as seen in many algorihm animaion sysems, bu i does no require graphics programming. Lens is inegraed wih a sysem debugger o suppor ieraive esing and refinemen. n he remainder of his aricle, we describe he concepual model on which Lens is based, we illusrae how program animaions are buil wih Lens, and we describe some of he implemenaion challenges he sysem presens. 2 denifying he Essenial Componens of Program Animaions n building he algorihm animaion debugging environmen, we sough o provide a palee of commonly-used operaions o developers for direc invocaion, raher han forcing developers o wrie animaion descripion code. We also sough o provide a graphical edior for defining he appearance of program variables. Mos imporanly, we waned o keep he liss of operaions and graphical ediing operaions o a minimum of ofen-used direcives. Raher han building a comprehensive environmen which could suppor any animaion bu which also included many rarely used direcives, we sough o build a compac kernel of commands ha could easily be learned and masered. To develop his kernel, we sudied over 40 algorihm animaions buil wih he XTango sysem[2 ]. The animaions opics included soring, searching, graph, ree, sring and graphics algorihms, as well as animaions of marix muliplicaion, ff, hashing, producerc.onsumer problems, ec. These animaions were buil by over 25 differen people, so hey were no biased o a paricular person s design mehodology. The firs sep in his analysis was o deermine which ypes of graphical objecs are commonly used in algorihm animaions, and also how he appearance of an objec depends on he program i is represening. Alhough XTango suppors a wide variey of differen graphical objecs, only lines (5 imes), circles ( imes), recangles (3 imes) and ex (7 imes) commonly appeared. Oher objecs such as polygons or ellipses appeared only O-2 imes. When one of hese graphical objecs is creaed in an algorihm animaion, is appearance usually depends on he sae of he underlying program and he values of variables wihin he program. For insance, he. posiion, size (lengh, widh, heigh, radius) and label (for ex) all may depend upon program values. For lines, we found ha he posiion and size of he line are is wo aribues ha vary. Posiion was eiher predeermined (no program dependence), dependen upon he values of variables in he program, or relaive o oher exising animaion objecs. Line size was eiher predeermined or relaive o oher objecs. The recangle aribues of posiion and size (widh and/or heigh) varied across animaions. Boh were eiher predeermined or program variable dependen. These specificaions were he same for circles wih he size aribue being he circle s radius. Finally, ex objecs varied along posiion and ex sring aribues. Tex posiion was commonly eiher predeermined or dependen upon he locaion of some oher graphical objec. (Tex is ofen used o label oher objecs. ) Tex srings were eiher predeermined or dependen upon program variables, n addiion o individual graphical objecs, many of he algorihm animaions manipulaed rows or columns of objecs. These srucures were commonly used o represen program arrays. n specifying a row of objecs, designers would idenify a bounding box inside of which he individual objecs were placed. The number of objecs was eiher predeermined or dependen upon he value of a variable. Ofen, one dimension of he objecs, such as recangles heighs for a row, varied according o he values of he variables in he array he row represened. Oher aribues ha 458

4 varied were he srucure s orienaion (horizonal or verical) and he spacing beween individual objecs. Table liss a summary of all hese graphical objecs along wih heir program dependen aribues. XTango animaions also include he capabiliy o designae paricular posiions in he display window. These posiions ofen serve as he desinaion poins of objec movemens. We found ha his feaure was very commonly used, so we included i in he consiuen se of capabiliies for he new sysem. The second major sep in idenifying algorihm animaion feaures was deermining common acions or changes ha objecs underwen afer hey were creaed. n all he sample XTango animaions examined, only five acions occurred more han a few imes. The acions are Move an objec o a paricular posiion or o a posiion relaive o anoher objec. Change he color of an objec.. Change he fill syle (ouline or filled) of an objec. Make an objec flash Make wo objecs exchange posiions (a special combinaion of movemen acions). Afer compleing his survey, we organized hese ses of graphical objecs and common animaion acions ino a kernel of capabiliies o be used as he basis for he graphical debugging sysem. our inenion was o allow designers o insaniae objecs graphically and o selec animaion acions hrough a se of menu-based commands. 3 neracing wih Lens The Lens sysem is a prooype implemenaion ha provides access o he kernel of capabiliies we idenified. n his secion we describe how programmers inerac wih he Lens sysem. To begin a visual debugging session, a programmer issues he command, lens foo, where foo is he name of an execuable program. Afer sar-up, he user selecs an iniial source file o view, hen Lens loads and displays his source and awais he enry of animaion commands. (Oher source files can be loaded via a menu command.) The enire Lens display appears as shown in Figure 2. The lef area presens program source code, and he righ area is he graphical edior for designing objecs appearances. To specify how he program animaion should look, a programmer chooses commands from he animaion menu above he source code. has seven opions ha correspond o he kernel of algorihm animaion consiuens found in our sudy of algorihm animaions: ) Creae objecs 2) Creae locaion marker 3) Move 4) Fill 5) Color 6) Flash 7) Exchange. When eiher of he firs wo commands is chosen, he programmer is promped o ener he variable name of he objec or locaion being depiced. The variable name is subsequenly used o idenify he objec for he acion commands. This is a key advanage of Lens: a programmer works in he conex of familiar program eniies, no graphics objecs. Lens hen asks he programmer o use he graphical edior o design he objec or locaion s appearance and/or posiion. This design is srucured according o he objec specificaions ha were discovered in he earlier sudy. For example, when a line is creaed, is posiion can be specified using he mouse, i can be specified relaive o anoher objec (by name or by picking a graphical objec), or i can be specified o relae o he value of a program variable. All hese choices are made via a dialog box enry or by graphical direc manipulaion. Finally, Lens asks he user o click he mouse on he source code line a which objec or locaion creaion should occur. Lens indicaes he presence of animaion commands by showing an A beside he code line. When a programmer chooses one of he five acion commands, Lens asks for he name of he variable, and consequenly graphical objec, o which he acion should apply. The programmer simply ypes in a variable name such as x or a [i] and Lens noes he choice. Finally, he programmer mus selec he source code line on which o place he command. Muliple animaion commands can be placed on single lines. When he programmer wishes o execue he program and see is animaion, he or she chooses he Run command from he Debug menu. Lens hen pops up an animaion window and displays he animaion ha corresponds o he programmer s design and his paricular execuion. Lens uses he rouines from he XTango sysem o generae he animaions i presens. f he animaion is no sufficien or no wha he programmer waned, he programmer can go back, add or delee animaion commands, and rerun he animaion. Lens also suppors saving animaion commands be ween sessions, so ha program debugging can be resumed a a laer ime using he same animaion conex. 459

5 Objec Aribue Specificaion(s). Line Posiion 5, lze Relaive o anoher objec Program variable dependen Relaive o anoher objec Recangle Circle Tex Posiion Widh, heigh Posiion Radius Posiion Sring Program variable dependen Program variable dependen Program variable dependen Program variable dependen Relaive o anoher objec Program variable dependen Objec array Posiion Number Size (bounding box) Program variable dependen Table : Summary of graphical objecs commonly used in XTango algorihm animaions and how heir aribues are specified. means ha he designer provided a value which remained consan. Building a Sample Animaion LJsing Lens, i is sraighforward o build program animaions in minues. Figure 2 shows he source and placemen of hree animaion commands for building a bar-char syle bubblesor animaion view commonly depiced in algorihm animaion sysems. The firs annoaion is a Creae Objec command. The programmer creaed an appearance for he variable named a. He specified a recangle array presenaion, drew a bounding box for i, seleced a horizonal orienaion, and specified ha he number of objecs is dependen upon he value of he variable n. Finally, he programmer provided sample minimum and maximum values for he array elemens. Lens requires his informaion o scale he heighs of recangles. The second animaion annoaion corresponds o wo animaion commands, boh of Flash ype. The programmer specified ha he objecs corresponding o a [i] and a [i+l] be flashed o indicae a comparison in he program. The final annoaion corresponds o an Exchange command. The programmer specified ha objecs a[i] and a[i+] be swapped. Lens will illusrae a smooh inerchange moion for his command. Figure 3 illusraes he view of his animaion specificaion and a frame from he resuling animaion. Wih a few more simple Color and Fill commands, he animaion can be refined furher. 4 Sysem mplemenaion The creaion of he Lens sysem presened a number of ineresing challenges. n his secion we highligh a few of he mos imporan ones. 4. neracion wih dbx To acquire informaion abou he program ha is being run, Lens esablishes a connecion wih he dbx debugger. The inerface wih dbx is similar o he 460

6 lcu al= lm++l C+l-. -.w+b. m +Uu l-u 3 P**v--- m-.+.+., , # # # i i i 8! f Figure2: Lens display presened o a programmer. The lef secion shows source and he righ secion is he graphical edior. 46

7 i El,,!,.,,,,.,,.,,,.,,,,,,,, A]!,,,,,,,,,,,.,.,,,!,.,, 7,!$>..!,,!,,,,,,-,,,,.,,,,,,,,,,,,,,,,.,,,,,,,,,.. Figure 3: Frame from he bubblesor animaion buil using Lens and hree animaion commands. The buons o he lef provide panning and zooming. The scrollbar o he righ conrols he animaion speed. 462

8 approach used by he program xdbx. Lens communicaes wih dbx hrough a pseudo erminal ha is a pair of maser and slave devices: /dev/py?? and /dev/ y??. The py is opened for boh reading and wriing. Afer a child process is creaed via fork, he child process closes he maser side of py, redirecs sdin, sdou and sderr of dbx o py, unbuffers oupu, daa from dbx, and execs dbx. The paren process closes he slave side of py, ses he clbx file poiner o nonblocking mode, opens he file poiner o read/wrie access o dbx, ses line buffered mode, and hen moniors he oupu from and passes inpu o dbx. When he user commands Lens o creae an animaion acion, he paren sends a sop a command o dbx. Laer, when he program is execuing and dbx sops a ha line, he paren execues he animaion acion ha was specified a he line. The paren also may acquire oher informaion from dbx; for example, if he value of a variable is required, a prin command is passed o dbx, and if he ype of a variable is required, a wha is command is passed o clbx. f dbx passes an oupu, he paren processes i and akes he appropriae acion. For example, if he program ha is being debugged has an error and dbx sends an error message, he paren will display he error message for he user and hal he execuion of he program. f dbx sends an oupu which he paren does no recognize, he paren assumes ha he oupu is from he program iself and oupus i for he user o see. Thus, he overall srucure of he Lens sysem is shown in Figure Specifying he Animaion Acions n order o make he specificaion of animaion acions as easy as possible for he programmer, Lens requires some suble inernal manipulaions. For example, when a programmer ypes in he arge for a command such as Color, he programmer simply eners a ex sring such as bl a a dialog promp. Lens resolves his enry ino an inernal daabase of objecs and locaions ha already has been creaed. Lens also mus aler he programmer o synacic errors made a his level. f an objec s aribue is dependen on a program variable, he sysem asks he user o specify is maximum and minimum value in order for Lens o scale he objec appropriaely during he acual animaion. Anoher poin worh menioning is ha when he user chooses a variable, he sysem checks he ype of ha variable and rejecs he animaion acion if he variable is no of he appropriae ype. For example if a posiion is dependen on a variable, he variable mus be an ineger, double, shor, long or floa. Lens also mus be flexible in is inerpreaion of animaion acions. f a programmer chooses a Move command, he or she can specify he name of anoher program eniy which should be he desinaion of he movemen acion. This eniy can be eiher a locaion or a graphical objec. Lens mus make his deerminaion, and if i is an objec, use he objec s curren posiion as he desinaion poin. The Exchange animaion requires he user o specify he variables for he wo objecs (hey canno be locaions) ha are o be exchanged. The Flash, Change Fill and Change Color animaions require he user o specify he variable for he image on which he acion is o ake place. The Change Color animaion also requires he user o selec a color from a palee of colors ha is displayed. All hese animaion acions may be applied o an objec or locaion ha is an array elemen. For example, he user may specify ha elemens a [i] and a[i+l] should be exchanged. To handle his siuaion, Lens mus firs check wheher here is a [ in he variable name. f so, i checks o see if he variable specified before he [ refers o an array. f no, i will signify an error and rejec ha animaion. Oherwise, during he acual animaion execuion, i will ge he value of he array index (i may be a consan, variable or a simple expression) and use ha index o acquire he appropriae graphical objec or locaion. Fundamenally, Lens mus coordinae and manage he mappings beween program eniies and graphical objecs. 4.3 Execuing he Animaions Afer he programmer has buil all he animaions and wans o run he program, Lens mus dispach a run command o dbx. Before i does ha, however, Lens goes hrough he lis of animaions (he animaions are kep in a linked lis) and sends a sop a command o dbx for each animaion a he appropriae line. One unique feaure of dbx is is assignmen of line numbers o he logical file ha are differen from he acual line numbers of he source ex file. This is due o blank lines and saemens sreching over more han one line. Therefore, if one passes a sop a n command o dbx, he line number ha dbx acually sops a may be differen from n. Forunaely, dbx reurns he line number where i will sop given a paricular sop a reques. Lens uses his value and sores i for subsequen specificaions. When dbx sops a a paricular break poin and send a message o Lens, he sysem scans he lis of animaion commands o find ou he command(s) 463

9 The Lens Sysem * Pnren hxess 4 Oupu from dbx Child Process (Runs he sninmion dbx, conrols user ineracion) exeeues he progrnm) Figure 4: Lens sysem configuraion illusraing how he various processes communicae wih each oher. which caused he break poin. When i finds he command(s), i execues he acion(s) specified here. For his, i may need o send oher messages o dbx, for example, prin z if he aribue of an objec, such as is widh, depends on he variable i. is possible ha he program being debugged requires some inpu from he user via sdin. n Lens, dbx ges all is inpu from he paren process which was esablished. Hence, he paren mus se is inpu o non-blocking mode and consanly poll he exernal inpu buffer. f here is ever any user inpu, Lens passes i on o dbx. 5 Fuure Plans All of he capabiliies described in his aricle have been implemened and are funcional. Lens is currenly running on Sun worksaions under Xl and Moif. Our fuure plans involve coninued developmen and refinemen of Lens and is inerface. n paricular, we hope o Q mprove he somewha clunky user inerface for specifying objec appearances and binding hese represenaions o program eniies. Currenly, much of his ineracion occurs hrough dialog boxes. We plan o uilize more of a direc manipulaion[8] approach. Two possibiliies for improvemen are choosing program variables by selecing hem wih he mouse from he program ex, and specifying graphical connecion links beween graphical aribues (heigh, size, posiion) and program variables. Allow users o examine animaion commands ha have been regisered in he program source. Currenly, we simply indicae he presence of animaion commands by he A annoaion. Provide full dbx command capabiliies o he user so ha s/he can inerac wih he execuion more. Add radiional daa srucure display capabiliies o he sysem for furher debugging suppor. Perform empirical ess o examine he usabiliy of Lens inerface, and mos imporanly, o beer undersand how Lens can be uilized in program debugging. Currenly, our work wih Lens is a he proof of concep phase. We waned o address he challenge of building a program animaion sysem ha requires no coding nor any knowledge of a graphics paradigm, and ha is inegraed wih a sysem debugger. We believe ha Lens mees his challenge. Now, we mus examine he sysem and undersand is srenghs and weaknesses as a debugging and racing aid. n paricular, a number of quesions remain: To wha level of complexiy in a program is Lens sufficien for building an animaion? Are he kernel of primiives enough? f no, wha should be added? Can higher level, inegraed animaion emplaes be added? We expec o make Lens available via anonymous fp soon, and we hope ha feedback from is use along wih fuure empirical sudies helps us o beer undersand he possible role of visualizaion and animaion in program developmen and debugging. 464

10 Acknowledgmens This work suppored in par by he Naional Science Foundaion under conrac CCR References [] p2] Ronald M. Baecker and David Sherman. Soring Ou Soring. 6mm color sound film, 98. Shown a SGGRAPH 8, Dallas TX. [3] [4] [5] [6] [7] [8] [9] [0] Ronald M. Baecker. An applicaion overview of program visualizaion. Compuer Graphics: SG- GRAPH 86, 20(4):325, July 986. David B. Baskerville. Graphic presenaion of daa srucures in he DBX debugger. Technical Repor UCB/CSD 86/260, Universiy of California a Berkeley, Berkeley, CA, Ocober 985. Jon L. Benley and Brian W. Kernighan. A sysem for algorihm animaion. Compuing Sysems, 4(l), Winer 99. Marc H. Brown. Perspecives on algorihm animaion. n Proceedings of he ACM SGCH 88 Conference on Human Facors in Compuing Sysems, pages 33-38% Washingon D. C., May 988. Marc H. Brown and Rober Sedgewick. Techniques for algorihm animaion. EEE Sofware, 2():28-39, January 985. Rober A. Duisberg. Animaed graphical inerfaces using emporal consrains. n Proceedings of he ACM SGCH 86 Conference on Human Facors in Compuing Sysems, pages 3 36, Boson, MA, April 986. Rober A. Duisberg. Visual programming of program visualizaions. A gesural inerface for animaing algorihms. n EEE Compuer Soczey Workshop on Vsual Languages, pages 55 66} Linkoping, Sweden, Augus 987. J. D. Gould. Some psychological evidence on how people debug compuer programs. nernaional Journal of Man-Machine Sudies, pages 5-82, 975. Rober R. Henry, Kenneh M. Whaley, and Bruce Forsall. The Universiy of Washingon illusraing compiler. Sigplan Noices: SGPLAN 90, 25(6): , June 990. [] Sadahiro soda, Takao Shimomura, and Yuji One. VPS: A visual debugger. EEE Sofware, 4(3):8-9, May 987, [2] [3] [4] [5] [6] [7] [8] [9] [20] [2] [22] rving Kaz and John Anderson. Debugging: An analysis of bug locaion sraegies. Human- Compuer nerac~on, 3(4):35-399, 987. Brad A. Myers. A sysem for displaying daa srucures. Compuer Graphics: SG GRAPH 83, 7(3):5-25, July 983. Brad A. Myers. Taxonomies of visual programming and program visualizaion. Journal of Visual Languages and Compuing, ():97-23, March 990. Blaine A. Price, an S. Small, and Ronald M. Baecker. A axonomy of sofware visualizaion. n Proceedings of he 25h Hawaii nernaional Conference on Sysem Sciences, volume, pages , Kauai, H, January 992. Seve P. Reiss. Pecan: Program developmen sysems ha suppor muliple views. EEE Transacions on Sofware Engineering, SE-(3): , March 985. Takao Shimomura and Sadahiro soda. Linkedlis visualizaion for debugging. EEE Sofware, 8(3):44-5, May 99. Ben Shneiderman. Direc manipulaion: A sep beyond programming languages. Compuer, 6(8):57-69, 983. John T. Sasko. TANGO: A framework and sysem for algorihm animaion. Compuer, 23(9):27-39, Sepember 990. John T. Sasko. Using direc manipulaion o build algorihm animaions by demonsraion. n Proceedings of he ACM SGCH 9 Conference on Human Facors in Compuing Sysems, pages , New Orleans, LA, May 99. John T. Sasko. Animaing algorihms wih XTANGO. SGACT News, 23(2):67 7, Spring 992. John T. Sasko and Charles Paerson. Undersanding and characerizing sofware visualizaion sysems. n Proceedings of he EEE 992 Workshop on Visual Languages, pages 3 0, Seale, WA, Sepember