Specifying Algorithm Visualizations in Terms of Data Flow Jarosław Francik Silesian University of Technology, Gliwice, Poland
[email protected] Abstract Interesting events and state mapping are two approaches used to specify software visualization. They are applied in, respectively, event-driven and data-driven visualization systems. Yet another approach, data flow mapping, is presented in the paper. However similar to the state mapping, this new method of specification emphasizes dynamic rather then static aspect of the program execution. A comparison of these two approaches is provided in the paper. The basis for discussion is two algorithm animation systems: a data-driven Leonardo system and a data-flow-driven system called Daphnis.
1. Introduction Software visualization is often defined as presentation of chosen characteristics of the software using adequate graphical representation [13][15][17]. Two problems arise in this context: what graphical representation should be applied and how it should be bound to the underlying algorithmic code. Both problems relate to the specification of software visualization. Methods of specifying graphical representation are usually quite obvious. Much more challenging problem is binding visualization to the actual software objects. The key questions are when and how the visualization events should be triggered. One solution, called event-driven, amounts to hard-coding such trigger points – or the interesting events. The visualization is driven directly by calls to suitable animation functions. Another approach, called data-driven, consists in mapping the software states into the resulting graphics. The trigger points are the moments when software states change – commonly when data content is modified. The event-driven approach gives the user much flexibility; it is very well suited to highly customized visualizations. The data-driven solution is more general and allows automating a part of the user’s tasks; it makes the visualization easier and usually more creative. Both methods will be described in detail in the next section. Then an original data-flow-driven approach will be proposed. Its key feature is that it emphasizes dynamic rather then static aspects of software; it consists in visualizing the changes of software states. Despite many similarities between dataflow-driven and data-driven approaches – one could even
describe the former as a subcategory of the latter – dataflow-driven systems offer many features that automate the visualizer’s task in even higher degree and make his efforts even more creative.
2. Methods of software visualization specification: state of the art The simplest – conceptually, not technically – method of software visualization specification is hand-coding: the user writes a special-purpose program that visualizes a particular algorithm or another program. Such program is by itself a specification of the visualization; however, no typical visualization system is involved so this solution is not interesting from our point of view. A splendid comparison and in-depth analysis of two most common approaches may be found in [4]. For a comprehensive discussion the reader may refer to [11][11][15] as well as [8].
2.1. Event-driven method With an event-driven visualization system the user annotates the source text of the visualized program. Each annotation represents an interesting event: a trigger point that activates the system. They are just calls to the visualization system routines, with complete specification of the graphical representation parameters. For example, an interesting event in a sorting algorithm may be the exchange operations. The connection between a program and the visualization system is typically invasive, i.e. involves modifications to the source text of this program. The specification may be improved by use of scripts: external files that define graphical representation for various types of interesting events. The source text annotations contain only references to that external script. Some systems go further and offer special editors that support text annotating. Still the style of annotations remains imperative: each interesting event (a place in source text) is connected with an a priori determined visualization action. The choice of trigger points for the visualization system is free; so is the choice of the object of presentation. The complete visualization information must be supplied at each interesting event. This makes the user’s task highly intuitive, but a disadvantage is inherently invasive style of program connection and low level of automation.
The event-driven model has been applied in the first successful algorithm animation system Balsa [2], as well as in its successor, Zeus [1]. Later it was also used in Tango/XTango [16] and Polka [18].
2.2. Data-driven method In the data-driven visualization the change of data values is the only trigger point that has to be announced to the visualization system. This significantly reduces the diversity of source text annotations. Some systems annotate the source automatically, using text preprocessors, while the other provide an instrumented execution environment (interpreter or compiler) so that the data structures may be monitored without affecting the source code. The latter technique makes the connection style totally non-invasive (but this feature is not compulsory). In the data-driven visualization systems the specification of visualization is declarative: it specifies how to visualize a given data structure, no matter where (in which line) the instruction that caused the change of data value is. This approach involves interesting data structures instead of interesting events. The user supplies a recipe how to map their contents into a visualization and it is the system’s responsibility to reflect all the occurring data changes. The visualization is consequently built on a higher level of abstraction. The choice of trigger points is fixed and usually supported by the system. The object of presentation is limited to the temporary contents of the data structures (just as in traditional debugging tools). The only information sent to the visualization system is the identity of the data structure that has been changed. This may sometimes reduce customization possibilities. The advantages are clean design and allowance for some ignorance of the code. Datadriven visualization may be applied as an exploration tool: one can declare the graphical representation for some data structures and just observe what happens to them. Also the automation level is inherently higher [14]. Probably the first data-driven system ever done was the Animus [6]. More recent examples are Pavane [10] and Leonardo [3][5].
3. Data-flow-driven software visualization In the data-flow-driven approach the technique of specification is similar as in the case of data-driven systems. The same is also trigger point: the visualization is activated each time the interesting data structures are accessed/modified. What differs the two approaches is the object of the visualization. The focus moves from observing variables (data structures) to observing data transferred between them. The elementary information sent from the observed software to the visualization system involves the source and destination points of such transfers.
The most important postulate for data-flow-driven visualization is the postulate of illustrating data flows: visualization should apply smooth animation to render operations of data flow, which occur during the process of algorithm execution. A good visualization has to illustrate not only the states a program reaches during execution but also how the transformation between the states occurs. A way to obtain this is a visualization in which the graphical representation of data is smoothly animated from the place representing its source location towards the place representing its destination. It passes through a series of in-between positions that have no correspondence to the actual state of neither the program nor its data. Therefore the graphical objects do not represent variables, but rather their persistent content flowing from one location to another. Visualization should suppress information concerning some variables considered to be uninteresting. Suppressed are those elements, which do not support understanding of the algorithm. An object of such visualization is in fact an algorithm different then the actual one, as it contains less number of variables (and data flow operations). Ignoring some variables often leads to ceasing the coherence of the global image of data flow in the program. Often variables supposed to be uninteresting make an intermediate stage of a wider data flow that begins and ends inside the user's area of interests. It implies the need of reconstruction of broken multi-stage data flows. Such data flows should be glued so that, if possible, long-distance, single flows are formed, in which both source and destination variables are interesting for the user. A visualization as described above fulfils another fundamental postulate of data-flow-driven systems: the spatial suppression of information. Forming a long-distance, multi-stage data flow may be disturbed by appearance of another flow, which may occur in the meantime. To show it – keeping the temporal order of operations – the long flow should be broken. But a sequential program is an overspecification of the algorithm. If both data flow operations are independent, the natural solution would be to change their order, or – better – to show them synchronically. This leads to the final postulate: the temporal suppression of information. Some operations that are actually executed sequentially may be rendered as if they were executed in parallel and synchronously. Thus, the rendered realization of an algorithm differs from the one actually applied in the visualized piece of software. The detailed information about time ordering of operations, that are independent and executed in short period, often not only gives no support for algorithm understanding, but – on the contrary – it draws the observer's attention away from other, much more important elements of the projection. The ideas given above will be illustrated using an example of the operation of exchange of two values (fig. 1). A simple, static visualization shows the state before and after the operation, giving no directions on how it was
performed (fig. 1a). An animation that uses first postulate (illustrating data flows) gives information on what happens: what is the source and the destination of data (fig. 1b). An animation made in accordance with all three postulates (fig. 1c) hides uninteresting details (an auxiliary variable, the order of assignments) and shows what is most important: an exchange of two values as it were a synchronous, symmetric process. It is closest to intuitive meaning of what we call exchange. Satisfying all the three paradigms involves some level of abstraction. Most existing visualizations go in this direction; good examples may be numerous animations of sorting algorithms: elementary exchange operations almost always are illustrated as symmetric and synchronous processes of moving graphical objects, without use of any auxiliary variables. In the systems existing so far, obtaining such a visualization involves an a priori, handcrafted design. The data-flow-driven software animation approach has been described in detail, together with underlying algorithms, in [7][8][9]. 6
6
8
4
14
14
4
8
before
after a) static visualization
6
6
6
8
4 8
14
14
4
4
before
aux
14 8
meantime (1st assignment)
after
b) smooth animation – illustrating data flows 6
6
6
8 14
4 4
14
8
4 before
14 8
meantime
after
c) synchronous, symmetric operation
Figure 1. Modes of visualization of exchange of two values
4. Specifying data-flow-driven visualization A graphical element in the data-flow-driven visualization is not any more a representation of a data structure. It is rather a representation of the content of a data structure, which may freely flow between various structures. A system object that keeps track of the visualized data content, and connects it to the appropriate graphical element, is called an actor. The actor’s value is actually the data structure’s value, and also actor’s location is rather the location of that data structure. Actors may change both their values and their locations – and this is one of the key features of the data-flowdriven visualization specification. The graphical representation should have a group of attributes connected with the actor’s value and a group of attributes that visualize the actor’s location. A third group is constituted by the fixed attributes, that are not subject to animation. The value attributes (meant for visualizing the data values) are known from the data-driven systems. The visualization specification should supply the recipe for mapping these values into appropriate graphical parameters. The location attributes (meant for visualizing the data location) are usually, but not necessarily, the co-ordinates (x, y or x, y, z) of a graphical element. For simple variables they are usually declared as fixed. In case of structured variables (items of arrays or members of dynamic structures) there is a possibility to declare a mapping from their relational location in the greater structure to the values of appropriate location attributes. A general data flow involves 0, 1 or more source variables and a single destination variable. Operations with no source variable, or in which the only source variable is at the same time the destination, are considered as just value changes. In detail, following situations may occur: • Change of a value (e.g. a = 10) – connected with such modification of an actor, that its value attributes correspond to the new value. Usually it takes shape of some deformation of the involved graphical element. • Change of location (e.g. x = a) – connected with such modification of an actor, that its location attributes correspond to the new location. The new value of the attributes is obtained by finding the actor which represents data contained in the destination variable: the source actor takes the location attributes of the destination (value attributes remain untouched). The visualization takes shape of smooth motion of an actor’s graphical representation between two fixed positions on screen, that correspond to location of, respectively, the source and the destination (if the location attributes are screen co-ordinates). • Both value and location change (e.g. x = a + b) – it is a simple combination of the two situations mentioned above.
5. Specifying software visualization in the Daphnis system Daphnis is a general purpose algorithm animation system created by the author [7][8][9][19]. It is capable of visualizing action of algorithms of any class. The system works under Windows 9x/ NT4/2000/XP (or newer), and is generally independent of the language, in which visualized algorithm is formulated, however it is best suited to work with C/C++ programs. Daphnis is a data-flow-driven system, with declarative method of specification of visualization. Some annotations of the source text of programs are still necessary, so style of specification is invasive. The visualization is specified using a separate text file. From the point of view of the user, creating a specification file consists in defining a set of actors. The specification file syntax is given in tab. 1. Each actor definition contains the identifier of a variable initially visualized by this actor (necessary for initial connecting it to the algorithm) and a definition of a graphical element that represents it – so called grel. A grel specification includes its class (for example rectangle, roundRectangle, ellipse, textbox etc.) and a list of attributes. The attributes define the mapping of the visualized values to graphical parameters of grels – for example its coordinates, size and color. The attribute’s specification consists of its identifier (e.g. x, width) and an expression. The expressions are used to compute the temporary values of Tab. 1. The syntax of configuration files in Daphnis system
priority
FILE ::= {actor}. actor ::= [spec_ac] id "is" grel. spec_ac::= "noncopy" | "nonsyn" | "nonflow". grel ::= class [params] "{" {attrib} "}". class ::= id. params ::= "(" param {"," param } ")". param ::= int-number | float-number | text. attrib ::= {spec_at} id "=" expr. spec_at ::= "value" | "spatial" | "index" | "node" | "animated" | "discrete" | "clockwise" | "counterclockwise" | "straight" | "flash". expr ::= ingr { op ingr } | "(" expr ")". ingr ::= int-number | float-number | "#"id | "this" | functor. functor ::= id params. op ::= "!" | "*" | "/" | "%" | "+" | "-" | "=" | "==" | "!=" | "&&" | "||" | "?" | ":" | "of".
[…] designates an optional element {…} designates repetition (0, 1 or more times)
graphical parameters. They may contain numbers, identifiers of variables (preceded with “#”) and predefined functors in conjunction with typical arithmetic operators. The reserved word this designates the original value (not processed). The attribute definition may be additionally preceded with an optional specifier. It may declare a category for the attribute: value, spatial (which stands for location), index and node – the latter two relate to attributes that render location of a member variable in bounds of an array or a dynamic structure. There are also other specifiers that give additional hints on the animation mode. For x and y attributes the specifier spatial is taken by default, and all the other are value attributes if not specified otherwise. In the next sections some examples of visualization specification files are given.
6. Data-flow-driven vs. data-driven approach: a comparative analysis The event-driven and data-driven approaches have been in-depth analyzed and compared by Demetrescu et al. in [4]. They based their discussion on several features. In this section data-driven and data-flow-driven solutions are subject to comparison, and the same features will be used. In the cited paper Polka and Leonardo systems have been chosen as the representatives of the both groups. Here the object of analysis will be: Leonardo as a datadriven system and Daphnis as a data-flow-driven solution. The latter was presented in the preceding section, while the former still needs to be introduced.
6.1. Introduction of Leonardo Leonardo system [3][4][5] is one of the most successful solutions in software visualization built in recent years – it is downloaded 25 times a day – an average within 2 years – and has been also distributed on magazine CDROMs. Leonardo is not only an algorithm animation system: it is an integrated environment for developing, executing and visualizing C programs. An interesting feature, although out of scope of the discussion, is that Leonardo supports fully reversible execution. Declarative visualization specifications are attached to the key variables of the program. They are written in a simple, declarative language ALPHA (see next subsections for examples), and – in contrary to Daphnis – provided together with the source text, in the same file, enclosed with separators /** and **/. No other source annotation is necessary. As the ALPHA specifications are seen as C comments during the compilation – the specification style is strictly non-invasive. This important advantage was obtained thanks to the fact, that Leonardo contains a complete run-time environment.
6.2. The example animation The example animation will be algorithm animation classics: a simple-choice sorting. The source text in C is as follows: const int NUM = 20; int arr[NUM], i, j, k; ... // array initialization for (i = 0; i < NUM; i++) { // Seek the minimum k in range i..NUM-1 k = i; for (j = i + 1; j < NUM; j++) if (A[j] < A[k]) k = j; // Put the minimum at A[i] int tmp = A[i]; A[i] = A[k]; A[k] = tmp; }
The height is calculated using the value of the corresponding array item. The y, width, and additionally redBrush attributes are fixed. Moreover, the x attribute is an index attribute, y is by default a location (spatial) attribute, and all the other are value attributes. Both specifications, in Leonardo and in Daphnis as well, are similar as regards their length and complication, and they are rather easy to formulate. The Daphnis approach may be slightly easier for people not familiar with declarative style of programming (but it is a feature of the system, not the whole data-flow-driven approach). In both cases these simple specifications would fit to any sorting algorithm. A screenshot of the visualization in the Daphnis system may be seen in fig. 2a.
The classical visualization metaphor, that fits to almost every sorting algorithm, is showing items of the sorted array as vertical sticks with their height corresponding to values of items. The simplest solution in ALPHA, the Leonardo specification language, looks like this:
a)
/** View(Out, 1) Rectangle(Out ID,Out X,Out Y,Out W,Out H,1) For N:InRange(N, 0, NUM-1) Assign X=10+20*N Y=20 W=10 H=50+A[N] ID=N **/
b) The first line declares a window and has no counterpart in the Daphnis system. In the next lines NUM rectangles are enumerated, with geometrical attributes given in the last line. The X co-ordinate depends on the index of the rectangle, while the H height is calculated using the value of the corresponding array item. The Y co-ordinate and the W width are fixed. Each rectangle has also an identifier. The last parameter (1) defines a window in which all the rectangles are to be shown. The simplest specification for Daphnis is as follows: A is roundRectangle { index x = linear(0, 1, 10, 30); y = 200; width = 10; height = linear(0, 100, 50, 150); redBrush = 128; };
It states that A variable is visualized using rounded rectangles. The x attribute depends on the value of the index: it is a function that linearily maps a range (0..1) into (10..30). This line could be as well: index x = 10 + 20 * this;
Figure 2. Two versions of visualization of the simple choice sorting algorithm (produced with the Daphnis system)
6.3. Granularity The granularity is the level of detail of animation events (in time) [4]. In case of sorting algorithms, a visualization where exchanged items are animated one at a time is characterized by a higher granularity then the one where both assignments are shown synchronously. High granularity is inherent for the data-driven approach. Each variable change triggers the animation process, so exchange of two variables is shown as two events (assuming that the tmp variable is not shown, so the first of the three assignments is not rendered). To lower granularity level in Leonardo it is necessary to temporarily disable screen updates, as follows: /** Not ScreenUpdateOn **/ int tmp = A[i]; A[i] = A[k]; A[k] = tmp; /** ScreenUpdateOn **/
This a priori assigns a group of lines as a granule in a style that is rather imperative than declarative. Data-flow-driven solution has inherently lower granularity – thanks to its temporal information suppression postulate (see section 3) – without doing anything. The specification provided in previous subsection is just enough. Notice, that the granularity will be automatically raised when the tmp variable is recognized as an interesting one. Otherwise, raising the granularity requires additional care: in Daphnis a Flush function call serves to it (imperative solution), or alternatively a seq specifier applied to actor definition (declarative solution). Concluding, although both systems have tools to control the level of granularity, in case of data-flow-driven systems it is not only lower (better?) by default, but moreover automatically adapts to the visualization level of detail (depending on which variables are considered interesting).
6.4. Smooth animation Enabling and disabling smooth animation in both systems is similarly straightforward. Leonardo offers a special predicate defined in the ALPHA language: SmoothAnimationOn. In Daphnis each attribute may be supplemented by an additional specifier: animated or discrete. The Leonardo solution brings to mind an interesting event: changing the predicate is rather in imperative style, not declarative; what’s more it acts globally, affecting all the visualization, until it is cancelled. The solution applied in Daphnis is fully declarative; but it seems it should be counted as an advantage of the Daphnis system, not the data-flow-driven approach for itself.
6.5. Data flow issue Even if the granularity is set to appropriately low level, and the smooth animation is on, the data-flow driven system will still animate the swap operation as shrinking one stick while another grows. However nice, this manner of visualization is rather rarely what the visualizer really would like to get. Of course, there is no such problem with data-flow-driven systems: the animation consisting in swapping the sticks on the screen is the default one. The solution proposed for Leonardo system [4], although relatively simple, is not very intuitive. It assumes looking at swaps from the point of view of elements moving from one position to another; to do so, it is enough to assign ID = A[N] instead of ID = N in the specification shown in subsection 6.2. This forces the system to keep track of the sticks of the same length; rectangles of the same ID may have different positions before and after a swap, but the same size. There are two important limitations to this solution. None two objects may share the same ID; in this case it
means that none two array items may have the same value (!). Even more important is that this solution is unusable if both location and the value of the data are modified by a data-flow operation. Data-flow-driven systems evidently show here their superiority. Additionally, to avoid an opposite problem, the Daphnis system makes it possible to disable data flow visualization by simple specifying nonflow in the actor’s definition.
6.6. Visualizing variables being accessed and invariant properties of algorithms The visualization is triggered when the state of a data structure is modified. But what if an animation effect is required even if an involved variable remains untouched? Such situation will occur if the user wants to enrich the sorting animation so that to distinguish visually the items being candidates for the next exchange operation: A[i] and A[k]: they should be highlighted red. A similar situation occurs when visualizing the algorithm’s invariant properties. An invariant in the simplechoice sorting algorithm is that items with indexes less then i are already in proper order. Let’s assume they should be displayed green. An animation that meets these two requirements is shown in fig. 2b. The solution, both for data-driven and data-flow-driven approach, is surprisingly simple. Both requirements are limited to special items: the highlighted red items are those, for which (index == i || index == k); the sticks displayed green are those, for which (index < i). These conditions remain unchanged unless the variables i, j, k change. And this is modification of i, j or k that triggers animation. The solution for Leonardo is as follows: RectangleColor(ID, Out Red, 1) If (ID==i || ID==k) RectangleColor(ID, Out Green, 1) If ID= pr(*pIn)) *pOut++ = *pStack--; *++pStack = *pIn; } else if (*pIn == '(') *++pStack = *pIn; else if (*pIn == ')' || *pIn == '\0') { while (*pStack != '(') *pOut++ = *pStack--; *pStack--; } else break; // illegal character } while (*pIn++); *pOut = '\0';
The animation (fig. 3) presents the input sequence in the upper part of the screen. The sysmbols being subject to analysis are sent either to the output sequence in the lower part of the screen, or to the stack of operators on the right. Fig. 3 depicts the moment, in which the next analysed input symbol is a closing bracket; operators are moved from the top of the stack to the output sequence.
Figure 3. Algorithm animation of translating an expression from infix to postfix form (produced with the Daphnis system)
The specification file for this animation is not complicated; it contains but three actor definitions: noncopy in is charBitmap("cube3d.bmp") { index x = linear(0, 1, 30, 70); index y = 50; char = value; }; noncopy out is charBitmap("cube3d.bmp") { index x = linear(0, 1, 30, 70); index y = 380; char = value; }; noncopy stack is charBitmap("cube3d.bmp") { index x = 700; index y = linear(0, 1, 340, 300); char = value; };
All three actors have been declared as noncopy. It accents the fact, that symbols neither in the input sequence, nor in the stack are read twice. Once read, their locations become uninteresting. The noncopy specifies that an actor is moved to the destination without leaving its copy in the source location.
8. Conclusion A relatively new method of software visualization specification (data-flow-driven) has been compared with a more traditional approach (data-driven). The criteria for discussion have been borrowed from the article [4], in which another pair of approaches is subject to compare: event-driven and data-driven systems. This should guarantee that the choice of comparison criteria was, even if not necessarilly objective, then at least not visibly biased. The two systems discussed, Leonardo and Daphnis, were also subject to comparison. The Leonardo uses a language of specification that is much more declarative in style; the specification language in Daphnis system is similar to C. The Leonardo’s language is more powerfull, but in the same time more difficult, especially for users who are not familiar with declarative style of programming. Surprisingly, some features are implemented in an imperative manner in Leonardo, while the same facilities in Daphnis may be obtained in a declarative form. These remarks concern comparison of systems, not approaches. The comparative analysis of data-flow-driven and dataflow methods has shown some superiority of the data-flowdriven approach over the data-flow one in such aspects as granularity and, of course, data-flow illustration. In other aspects, including visualizing variables being accessed and invariant properties of algorithms, both approaches offer similar functionality. They are also equally well suited for smooth animation.
References [1] M. H. Brown, “Zeus: A System for Algorithm Animation and Multi-View Editing”. Proceedings of IEEE Workshop on Visual Languages. Kobe, Japon, 1991, pp. 4-9. [2] M. H. Brown, “Exploring Algorithms Using Balsa II”. IEEE Computer, Vol. 21, N°5, 1988, pp. 14-36. [3] P. Crescenzi, C. Demetrescu, I. Finocchi, R. Petreschi, “Reversible Execution and Visualization of Programs with LEONARDO”. Journal of Visual Languages and Computing, 11(2): 125-150, 2000. [4] C. Demetrescu, I. Finocchi, J. T. Stasko, “Specifying Algorithm Visualizations: Interesting Events or State Mapping? ”. In: Software Visualization, State-of-the-Art Survey, Stephan Diehl (ed.), Lecture Notes in Computer Science (LNCS 2269), Springer Verlag, Berlin – Heidelberg – New York 2002 (in press). [5] C. Demetrescu, Leonardo system home page, http://www.dis.uniroma1.it/~demetres/Leonardo. [6] R. A. Duisberg, “Visual programming of program visualisations. A gestural interface for animating algorithms”. IEEE Computer Society Workshop on Visual Languages, Linkoping, Sweden, 1987, pp. 55-66. [7] J. Francik, “Algorithm Animation Using Data Flow Tracing”. In: Software Visualization, State-of-the-Art Survey, Stephan Diehl (ed.), Lecture Notes in Computer Science (LNCS 2269), Springer Verlag, Berlin – Heidelberg – New York 2002 (in press). [8] J. Francik, Surveillance du flux des données dans l’animation des algorithmes. PhD thesis, University of Lille, Villeneuve d’Ascq, France, 1999 (large summary in English available at [9]). [9] J. Francik, “Algorithm Animation Pages”, http://wwwzo.iinf.polsl.gliwice.pl/~jfrancik/aa.
[10] D. Hart, E. Kraemer, G.-C. Roman, Interactive Visual Exploration of Distributed Computations. Washington University, Department of Computer Science, St. Louis, MO, USA, 1997. [11] B. A. Myers, “Taxonomies of Visual Programming and Program Visualisation”. Journal of Visual Languages and Computing, Vol. 1, 1990, pp. 97-123. [12] A. Price, R. M. Baecker, I. S. Small, “A Principled Taxonomy of Software Visualisation”. Journal of Visual Languages and Computing, Vol. 4, 1993, pp. 211-266. [13] G. C. Roman, K. C. Cox, “Program visualization: the art of mapping programs to pictures”. International Conference on Software Engineering, New York, 1992, pp. 412-420. [14] G. C. Roman, K. C. Cox, “Abstraction in algorithm animation”. Proceedings of 1992 IEEE Workshop on Visual Languages, Los Alamitos, CA, USA, 1992, pp. 18-24. [15] J.T. Stasko, J.B. Domingue, M.H. Brown, B.A. Price (editors), Software Visualisation. Programming as a Multimedia Experience. Foreword by Jim Foley. The MIT Press, Massachusetts Institute of Technology, Cambridge, Massachusetts, 1998. ISBN 0-262-19395-7. [16] J. Stasko, “Animating algorithms with XTANGO”. SIGACT News, Vol. 23, Iss. 2, 1992, pp. 67-71. [17] J. T. Stasko, C. Patterson, “Understanding and characterising software visualization systems”. Proceedings of IEEE Workshop on Visual Languages, Seattle, WA, USA, 1992, pp. 3-10. [18] J. T. Stasko, Polka animation designer's package. Technical report, College of Computing, Georgia Institute of Technology, Atlanta, GA 30332-0280, 1992. [19] P. Szmal, J. Francik, “Algorithm animation and debugging with the WinSanal system”. Proc. of IASTED Conference Applied Informatics, Innsbruck, Austria, 1997.
