Sep 29, 2000 - Department of Computer Science and Engineering. Helsinki ... Abstract. Recently the focus on development of many algorithm animation.
DesignPatternfor AlgorithmAnimationand Simuiation Ari Korhonen,Lauri Malmi and Riku Saikkonen Departmentof ComputerScienceand Engineering HelsinkiUniversityof Technology Finland hut.fi s} @cs. { archie,lma,rj 2000 29th September,
Abstract Recently the focus on development of many algorithm animation systems has been the minimization of user effort for creating the animation from prograrn code. Thus, automatic code processing and code manipulation have been considered important. In these approaches the resulting animation works in a fairly low level, i.e., it concentrates on the details of the code instead of animating the important concepts, which would often be more fruitful for educational purposes' In this paper, a generalized approach for developing visualizations for arbitrarily complex object structures is described. In the proposed design pattern the intention is to separate the construction of complex object structures from their visualizations. Thus, the same object structure can be illustrated by different kinds of visualizations, i.e', as different concepts, and the same visualization can represent different kinds of object structures. Finally, the design pattern lets applications treat individual objects and object structures uniformly' As a result, these may be composed and illustrated using nested visualizations to arbitrary complexity. The new approach has the advantage that it allows concept animation with easy generation of animations. Moreover, it allows one to build systems w'here the user can manipulate object structures with a graphicai user interface. We call such an approach algori'thrn' simulati.on. It is a particularly useful tool for learning data structures and algorithms.
89
1
Introduction
The development of algorithm animation systems and program visualization systems is generally motivated by their usefulness for demonstration and educational purposes. However, in many casesthe amount of work needed for generating new visualizations and animations has been a bottleneck for using these tools widely. Learning to use the correct methods, for example, probing techniques to create an animation, and applying them may require too much effort for an occasionaluser. For these reasons,recent attention in program visualization has focused on the visualization specification styles and methods. Many techniques have been developed for producing visualizations of data structures while interfering minimally with their design. For example, the work of LaFollette, Korsh, and Sangwan [8] suggests self-animating types that allow programmers to create animations of CIC++ programs effortiessly by providing a set of ready-made data types that automatically create the animation. Rasala [9] describes a method that allows automatic array algorithm animation by providing a C++ template that is entireiy free of any code related to animation. Thus, the method does not require any intervention into the algorithm itself. The problem involved in the minimal user interfering approach is that the visualization or animation easily concentrates on unnecessary details. Thus, the processcould be characterizedas uisual debuggi,ng.For educational purposes, a visualization working on a conceptual level would often be more important and therefore concept animation systems have been developed. See, for example, the work done by Korhonen and Malmi [5, 7], and by Baker, Boilen, and Goodrich [1]. In these papers the authors report that concept animation has the problem that creating new concept animations requires too much work. In addition, user's possibilities a"rerestricted by allowing oniy a fixed selection of concepts. In their papel Baker et al. have presented a solution to the problems. They present a prototype visuaiizer which simply requires that the user's code conforms to a simple application progralnmer interface (API). The prototype is developed and experimented with in Java. In this paper, we present a new approach for generating versatile concept animations with little effort. In our solution the construction of complex data structures and their visualizations are separated from each other. The same data structure can be illustrated by many different kinds of visualizations, and correspondingly, the same visualization can represent many different kinds of data structures. Moreover, becauseindividual data items and data
90
Figure 1: Algorithm animation and algorithm simulation structures are handled uniformly, it is possible to compose and visualize nested structures of arbitrary complexity. Compared with Baker's (et al.) work [1] our approach has the advantage that we can allow the user to manipulate data structures through a graphical user interface without writing any code. Thus the user can simulate algorithms. We call this technique user controlled simulation (UCS). See Figure 1. Our experience is that this technique is a very valuable tool in teaching and learning data structures and algorithms since it enables the implementation of a system giving feedback about the results of simulation (automatic assessment)[4, 5, 71. In order to implement a system that is capable of both animating and simulating algorithms, the core implementation has to be considered very carefully. The core of our solution is characterized as a proposed design pattern [3] We will also describesome portions of the software visualization framework called Object-TRAKLA [6] that is developedby using the pattern. The system is implemented and experimented with in Java programming language. Object-TRAKLA does not only provide an application framework for algorithm animation systems but also allows the user to simulate the algorithms through the prototype application GUI.
1.1
Organization of this Paper
In the next section we discuss the general principles behind the proposed design pattern. In Section 3 we formally define the elements of the visualizations and describe the design pattern in terms of software engineering.
91
We also compare the pattern to existing patterns. Finally, in Section 4 we summarize our results.
2
Principles
The general view of the system is that we have an arbitrarily complex object structure which is manipulated either by at aigorithm or by the user (UCS). In both caseswe have the problem of visualizing the object structure and its behavior. Note that we use the term obiect structure rather than data structure, because our framework could also be used for representing and visualizing other concepts than data structures. In the following, however, we restrict to the context that we are considering only data structures. In the visualization processwe distinguish several levels. On the conceptual leuel we have to make a decision, whether we are manipulating abstract data types, Iike AVL trees, binary search trees, hash tables etc., or only basic concepts, such as arrays, lists, binary trees, general trees or graphs. Our decision is that the visualization is based on the basic concepts, and the animation of abstract data type operations are built on using these concepts, which we call fundamental data types (FDT). In the visualization processthe user can define the concept(s) with which the visualized object structure should be presented. We say that a representati,on for the structure is selected. For example, the user may wish to view a bina,ry heap either as a binary tree or as an array, or even in both forms. This expiicit decision is presented to the system via the GUI from the set of implemented concept interfaces. However, it is possible to consider heuristics which would investigate the object structure and identify appropriate concepts directly from the resulting information. A given concept may be presentedusing different layout algorithms, e.g., there are many different algorithms for drawing trees. However, for any such algorithm it is essential that it receives as input a structure which is a tree. We therefore need the uali,dation leael above the layout leuel. The validator processesthe object structure in order to make it valid for any layout algorithm for the selectedconcept. As an example, consider a graph which is represented as a depth first search tree (or a forest). The validator ieavesout the back, forward and crossedgesfrom the graph, i.e., it transforms it into a tree which can be drawn by a tree layout algorithm.
92
Flamework Design
3
In this section we formaliy define the visualization framework. After this, we present the design pattern that follows from the formal definition. Finally, we compare the new pattern to other design patterns.
3.1
Definition of Concepts
In order to illustrate the behaviour of a concept a set of visual data types is needed. By the term illustrafe we mean both the capability to animate the underlying algorithms and to simulate the behaviour of the visual data types by the user (user controlled simulation). In our approach the visualizing items and the actual object structure to be visualized are completely separated from each other. The visual data types are the implementations of the visualizing items that emulate the behaviour of the underlying object structure. We refer to the set of all compatible visualizing items as Compatible Visual Data Types (CVDT). The word compatible here refers to the following definition that all compatible VDT's should satisfy. Definition 3.L Let T denote the set of Vi,sualData Types. Then the Visual Data TypeT eT fs compatible,if T: (C,N,R), and 1 . t h e V i s u a l C o n t a i n e rC : N U R , 2. the set of Visual Components N E T, and 3. the set of Visual ReferencesR e tr[ x N. In addition, we supposethat there exists a Primitive VDT for each Primitive Data Typ"t. For example, if we have a primitive data type Int, thete exists a Primitive Visual Data Type Intpvor €T. Example 3.L A representati,onfor the graph G : (V, E) can be mapped to the pattern by selecting CG : Ny U R6 to be the Visual Conta'iner representing the graph as a whole. In addi'ti'on,for each uerter u € V there erists a Visual Component n, e Ny e T and iff there eri'sts edgee: (u,a) e E, then there also erists a Visual Referencere : (rru,nr) € RB between the € Nv. Vi,sual ComponentsrLu,TLu rPrirnitiue
refers to any object in which internal structure is not a subject of examin-
ation.
93
We will illustrate our approach further with the following example. Example 3.2 Let us consider the following erample graph G : (V, E) in which V : {a, b.c, d, e} and E : {(a, b),,(o, d), (b,c), (d, e), (e,c), (e,a)} . In order to ui,sualizethi,s, the model sh'ouldproui,dethe followi'ng four mappi'ngs between 1. the concept (graph G) and,the Visual Container (VisualGraph), 2. the aert'i,ces(V) and the Vi,sual Components (VisualGraphNode), 3. the edges(E) and the Visual References(VisualReference), and l. the ualues of keys (a,b,c,d,e) and,the Visual Primitiaes (VisualKey). The framework is capable of creating the mappings in the previous example if and only if the original graph implements the two required graph interface methods. The first method could be used to request the vertices of the $aph and the second method to calculate the weights of the edges of the graph. We refer to this mapping procedure as aali'dation. The va"lidation also creates concrete visual objects that serve as the input for the Iayout algorithm. The layout procedure then places the visual objects on the screen so that the concept makes sense to the user. Figure 2 represents an example graph the layout of which is drawn with one of the layout algorithms (slightly modified to support non equal size nodes) represented in [2]. The original graph, however, could be implemented in several ways (adjacency list, adjacency matrix or some other technique) but the actual implementation remains unknown to the visualizing framework. Of course, the framework could include also separate layouts for graphs in which the graph is visualized as an adjacency list or as an adjacency matrix. In Figure 2 the frame around the graph corresponds to the visual container VisualGraph and its outlook. Similarly, the circles around each key value, the lines between the circles and the key values inside the circles correspond to VisualGraphNodes, VisualReferencesand VisualKeys, respectively.
3.2
The Design Pattern
In Figure 3 we show the object-oriented design based on the Definition 3.1. The key relationships among the visual elements in the definition are illustrated in the design pattern at the top of the figure. We refer to this design pattern as the Visual Object Structure. The idea of the pattern is to define the skeleton of a representation. 94
e
Figure 2: Graph representation of the object structure in example 3.2. In general, Visual Object Structure lets subclassesredefine the visualization details for the representation and the actual object structure to be visualized should conform to an appropriate concept interface' In addition, Visual object structure provid.esa technique for composing single objects to larger units. Individual objects a,ndobject structures are treated uniformly, anJ therefole any single component may reculsively include another complex unit. This nesting technique enablesthe compatibility required in the Definition 3.1. 3.2.L
Applying
the framework
The framework provides a set of representationinterfaces and a set of visual data types for them. The visual data types are lesponsible for illustrating existing object structures that conform to the corresponding representation interface. An object structure may have several representations related to it. Thus, a single object structure may conform to many representation interfaces. The framework provides Visualizati,on Templafes which new representations can subclass. All the common functionality shared alnong the subclassescan be implemented in these tempiates' Thus, the pattern is used to implement the invariant parts of an object structure once and leave it up to the subclassesto implement the behaviour that can vary. For example, the mouse control needed by the graphical user interface (GUI) can be factored and localized in the common superclassVisualType to avoid code duplication. An additional static reposi.toryis provided to test whether the object structure to be iliustrated is already shown in some portion of the display,
95
s) setLabel(Sring selcolo(Colorc)
setDekultcoloo painq] object getElemenq) v) setElernenqobiect
intgetsubTreeCounq) Treel]gets|j)Trees{)
getLeftSubTree0 setLeftSubTree0 getFights ubTree0 setRights ubTre{) ObjectgetElemenq) o) setElemenqObject
Figure 3: The Design Pattern (top) and an example of using it in visualizing binary trees (bottom).
and thus need not be illustrated again. For example, the system may want to be sure it will not end up in an infinite loop when drawing components on the screen. Example 3.3 Fi,gure3 i,Ilustratesthe Tree representation i'n which the object structure Binary TYeeconforms to the interface Tree. The i'nterface TYee declaresthe set of methods that are neededfor representi'ngany object structure as a tree. The actual representation cons'istsof seaeral uisual data type classesthat are V'isualTree, Vi,sualNode,and Vi,sualReference.All of these classesbuilt in the framework are subclassed from the template classes VisualContainer, VisualComponent, and Vi,sualReference,respecti'uely. In this can be reused as such. case, the template Vi,sualReference It should be noted that all the representation interfaces are subclassed from the superclassFDZ (fundamental data type) that is the generic type for all object structures. As a result, any Visual Component that is a part of some complex visualization hierarchy may include an object structure of any subtype. In addition, the object structure may have a representation of its own that is again arbitrariiy complex, thus possibly consisting of many visual components. is neededin order to get F\rrthermore, an additional Vi,suali,zationFactory the proper representation for an FDT. The factory determines the subtype of an element, and returns a proper representation for it. If the element conforms to several representation interfaces,the factory returns the default validated representation. It is up to the GUI to provide the user the capability to change the representation. 3.3
Related
Design Patterns
The Visual Object Structure is an example of the Template Method [3] that "the leads to an inverted control structure. This is sometimes referred to as Hollywood principle", that is, "Don't call us, we'll call you" [10]. This refers to how a representationcalls the methods of the object structure to be visualized and not the other way around. The solution definesthe skeleton of a concept as an interface, deferring the implementation to the object structure to be visualized. In this way object structures can redefinecertain behavior within the scopeof the concept. On the other hand, the Visual Object Structure provides a way for creating famiiies of related or dependent objects without specifying their concrete classes,thus it is an Abstract Factory [3]. We can consider a concept here
97
to be the "family name') of one particular class of object structures. The framework can then treat all of the family members similarly through this common abstraction. For example, the concepl tree is common for many different concrete implementations that may have very different implementation (dynamic, array, etc.). Of course, a single object structure may belong to several families. Thus, a concrete factory implementation and a user interface are needed to determine the concrete representation displayed at the given moment. Finally, the visual object structure behaves also like the Bui,lder [3] par tern. Because the representation is constructed through an abstract class, all the developer has to do to create a new kind of representation is to define new kinds of concrete visual data types. The abstract class a,lsoconstructs the representation step by step, thus giving the developer finer control over the construction process and consequentlythe internal structure of the resulting representation. Moreover, the modularity encapsulatesthe way a complex representation is constructed. The representations can then be nested to build new kinds of representationsthat are compositions of the existing ones. Naturally, the existing visualizations (visual components) may be reused during the development process.
4
Conclusions
The design pattern makes adding new representationsand object structures easy. The pattern helps the developer to design and to implement a new representation. This is due to the fact that it is possibleto build new complex representationsjust by reusing existing ones. For example, the representation for a B-tree in Figure 4 consists of the tree representation that includes nested array replesentations as the keys. Contained in each a.rray are values representing the smallest key found in the corresponding subtrees (nonleaf nodes) or the actual data stored at the leaves. The visualizer can also illustrate an object structure simply by implementing representation interfaces. In contrast, if the control is the other way around, the visualizer must change each method in the object structure that causesthe representation to change. A single object structure may implement several interfaces thus allowing it to be represented in many different ways. For example, some object structure may implement both the graph interface and the tree interface. Of coulse) the tree representation, in general, possibly loses some information that could be visible in the graph representation. However, the tree representationmay still reveal some inter-
98
Figure 4: 2-3-4-treeillustrated by nesting tree and axray representations. esting details by representingthe depth first searchtree of the original object strructure. However, the design pattern does not provide complete support for all possible features needed to create a complete program visualization system. For example, in some systems, the navigation through the visualization includes the possibiiity to reverse the temporal direction of the animation. In algorithm animation this means reversing the direction of time so that the algorithm runs backwards. This can be extremely useful when trying to understand an algorithm. Thus, an additional technique is required to support these kind of features. In the prototype framework we have decided to provide a set of abstract representation interfaces and implementations (Probes) for them. The Probes behave like self-animating components that could be used as reusableelementswhen constructing a new object structure. The Probes additionally include the possibility to record the history of the Probe in such a manner that the algorithm can be executed backwards. Flom the appiication (GUI) point of view the Visual Object Structure pattern together with the Factory classprovides an abstract classVisualType for constructing the representation. Thus, the pattern hides the internal structure of the representation and how the representation gets assembled. It also improves modularity by encapsulatingthe way a complex object structure is constructed and represented. This makes it possible to operate with all the compatibie representations through a uniform interface. Thus, it is possible to add new representationsto the framework without changing the GUI. Moreover, the construction of a complex object is separated from its representationso that the same construction processcan create different 1ay-
99
outs for one single object structure. FinaJIy, user controlled simulation is possibie by expanding the representation interfaces to include the set of necessarymethods needed for the simulation. In our prototype appiication it is possible, for example, to simuIate an ,insertoperation by drag & dropping the VisualContainer of the source object structure into the VisualComponent of the target object, thus causing the insert method of the target object to be invoked with the parameter source. As a result, the framework is capable of handling nested structures and visualizations to arbitrary complexity.
References [1] R.S. Baker, M. Boilen, M.T. Goodrich,et al.: Testersand Visualizersfor Teoching Data Structures. The proceedingsof the thirtieth SIGCSE technical symposium on Computer scienceeducation,New Orleans,LA, USA, pp. 26I-265, ACM, 1999. [2] G. Di Battista, P. Eades, R. Tamassia,I.G. Tollis: Graph Drowing. Prentice Hall, 1999. ISBN 0-13-301615-3, [3] E. Gamma, R. Helm, R. Johnson, aqd J. Vlissides: Design Patterns Elernents of 1995. ISBN 0-201-63361-2' Software.Addison-Wesley, ReusobleObject-Oriented, - A Systernfor TeachingAlgori,thms using [a] J. Hyviinen and L. Malmi: TRAKLA Emai.I anil o Graphi,calEd,itor. Proceedingsof IIYPERMEDIA in Vaasa'93,pp. 141L47, 1993. ia algoritmientietokonea[5] A. Korhonen: World Wid,eWeb (WWW) tietorakente'i,i\en Master's Thesis,Depa,rtmentof Computer Science,Helsinki uusteisessaopetuksessa. University of Technology,L997. [6] A. Korhonen:Algorithm Anirnation and Simulation.Licenciate'sThesis,Department of Computer Science,Helsinki University of Technologr, 2000. [7] A. Korhonen,L. Malmi: Algorithm Simulotionwith Automatic Assessmeni.Proceedings of ITICSE'2000, pp. 160-163,2000. [8] P. LaFollette, J. Korsh, and R. Sangwan:A Visual Interfocefor Effortless Animation of C/C++ Prograrns.Journal of Visual Languagesand Computing' Vol. 11, No. 1, pp. 27-48, AcademicPress,Feb. 2000. [9] R. Rasala:Automatic Anag Algorithrn Anirnat'i,oni,n C++. The proceedingsof the thirtieth SIGCSEtechnicalsymposiumon Computerscienceeducation,New Orleans, LA, USA, pp.257-260,ACM, 1999. SIGPLAN Notices,Voi. 20, No. 7, enu'ironrnent. [10] R.E. Sweet:?he Mesaprogram,rning p p . 2 1 6 - 2 2 9J, u l y 1 9 8 5 .
100
