3D Animation of Java Program Execution for Teaching ... - CiteSeerX

3D Animation of Java Program Execution for Teaching Object Oriented Concepts Tim Storer September 23, 2006 Abstract The successful teaching of the object oriented programming paradigm has been identified as a difficult task. Coupled with the difficulty of conveying abstract concepts in general to students, is the complexity of the object oriented paradigm itself. A common approach to conveying complex abstract notions (such as algorithms or data structures) is the use of visualisations. This paper describes the and the design and implementation of the JOOPA2 tool for animation of the execution of simple object oriented (Java) programs in a 3D environment. The tool was developed for the purpose of supporting the teaching of object oriented concepts in an introductory level programming course.

1

Introduction

A commonly cited difficultly of teaching computer science is the need to successfully convey a plethora of abstract concepts [?, ?]. Such concepts include, for example, the notion of an algorithm and the relationship between an abstract data structure and the multitude of potential implementations. Recently, the Object Oriented (OO) programming paradigm has gained in popularity because of the perceived potential gain for code modularisation, encapsulation and component re-use. The popularity of the OO paradigm in industry has led to the adoption of OO programming languages in university computer science courses. In particular, the Java language is increasingly being taught in university, because of its popularity in industry and the availabilty of support materials [?]. A natural consequence of the switch to teaching OO programming is the need to convey the abstract concepts involved in the paradigm and in the case of Java, to convey these concepts alongside the notion of a procedural imperative programming language. However, the teaching of this paradigm, with multiple abstract concepts to be conveyed, is non-trivial. Students struggle to grasp the notion of an object oriented environment, the necessity of the distinction between a class and an object and the relationship between the paradigm and the textual description (their source code). A common technique when teaching abstract concepts in any subject is to use visualisations that are able to guide novice students through the main features [?, ?]. For the OO paradigm, a commonly employed graphical tool is the Unified Modelling Language (UML) [4]. Students use UML to associate

1

graphical visualisations of program structure with the Java source code implementation of their program. A disadvantage of the UML is that it is intended for a static medium and thus is limited in its ability to visualise dynamic program execution. An alternative approach is to use animation to provide dynamic visualisations of software and/or algorithms in execution. The remainder of this paper is structured as follows. Section 1.1 discusses previous approaches to the use of visualisation for teaching computer science, including visualisation of algorithms and software. Section 2 describes the design considerations for the JOOPA 2 tool with respect to supporting student learning of the Java programming language. Section 3 describes the architecture for the JOOPA 2 tool, which integrates an event driven, JDI debugger with a Java3D visualisation environment1 . Section 4 describes the aspects of the Java programming language currently visualised by the JOOPA 2 tool, whilst Section 5 describes future developments planned for the tool and Section 6 summarises the work presented in the paper.

1.1

Related Work

An early attempt to produce a software animation package was the Brown University Algorithm Simulator and Animator (BALSA) [1]. Written in C, BALSA produced an animation of a program as it ran, coupled with a display of the code (usually written in Pascal) highlighting each line as it was executed. BALSA also incorporated a feature for displaying static data structures using dots and sticks as the animation of the algorithm progressed. BALSA illustrates how careful separation of purpose for animations prevents over cluttering the display with too much detail. No attempt was made to incorporate the data structures into the animation of the program as it was running, but the user could observe both simultaneously through two different views. A number of approaches have been made to the teaching of OO programming and design using visualisation techniques. The UML may be used to develop a comprehensive OO design, complete with class hierarchies, use case diagrams, and sequence diagrams amongst others [4]. The design can then be used to produce an outline implementation either manually or through an animation tool such as Together or BlueJ [?, 2]. UML can be considered as a notation that is highly adapted to the description of the design of complex OO systems, but that it is less suited to the teaching of OO concepts by itself. As the capabilities of domestically available machines have increased, a tendency towards using three-dimensional graphics for a variety of applications has increased. One such tool for algorithm animation is Polka-3D [?], which behaves in a similar manner to its predecessor, Polka for algorithm animation. More recently, work has been undertaken on visualising object oriented software in virtual reality environments, in order to provide users with an interactive, graphical environment for exploring the static aspects of a programs structure [3]. 1 To a certain degree, the tool is a re-implementation of the visualisations presented in its precursor, JOOPA1. However, the new version, provides visualisations of several aspects of the Java language not present in the original tool, and crucially, the automation of animation generation.

2

1.2

Motivation

The tool described in this paper, JOOPA2, animates the classes and objects of Java programs as they are executed in a virtual machine. The animation occurs in a 3D environment, which allows a user to ‘explore’ the relationships between classes, objects, methods and attributes as a program executes. The argued advantage of this approach is that a visualisation of the object oriented paradigm (as implemented in Java) is presented to a user for a program of their choice. The visualisation is combined with the procedural execution of the program to emphasise the dynamic nature of an object oriented program. The extra dimensionality afforded by a 3D visualisation also allows a user to ‘interact’ and explore a program’s environment, investigating object features and the relationship between objects. Users can also manipulate the layout of a program’s visualisation, pausing execution to cluster entities of interest together as required.

2 2.1

Design Considerations Integration with UML

Given the intended use for the JOOPA tool as a teaching aid within an introductory Java programming course, it is desirable that the visualisations presented are consistent with other graphical notations employed in a course. In particular, the Unified Modelling Language (UML) is a commonly employed tool for teaching program design concepts for object oriented languages. UML includes commonly accepted graphical notations for classes, objects, references, fields, methods, and their respective labelling conventions. In addition, UML incorporates diagrams for static program design (class diagrams), as well as diagrams to illustrate program usage (activity diagrams) and likely method method sequence calls (sequence diagrams). The design of the JOOPA tools reflects these pre-existing conventions in order to enhance consistency across visualisations. In particular, notations for class and object visualisations are retained (in a 3D context) and labelling notations are modelled on UML.

2.2

Detail Level

A problem associated with many visualisations of software is the need to reduce detail ‘clutter’ so that the fundamental abstract concepts underlying the visualisation can be conveyed successfully. Detail clutter is the inclusion of multiple aspects of a program’s features which detract from, rather than enhance, the understandability of a visualisation. A desirable feature of the JOOPA2 tool would be features which permit the user to conveniently configure the amount of detail rendered in a visualisation.

2.3

Relationship to other Representations

Multiple representations of software are used during the teaching of a programming course. These include source code of high level languages, natural langauge descriptions of functionality and graphical notations such as UML. To

3

Figure 1: The architecture of the JOOPA 2 tool. A JDI based debugger generates debugging events from a target application. The events are passed to the animation engine, which renders a 3D representation of the Java application state. The 3D environment may be viewed by one or more user interfaces.

enhance understandability of a new representation, it is desirable that conventions adopted in one representation occur elsewhere. This consistency supports students in making connections between different representations of a software artifact.

2.4

Teaching Support

The JOOPA 2 visualisation tool is intended to support the teaching of object oriented concepts with respect to an introductory programming course. OO concepts are taught via the Java programming language. Teachers employing the tool to convey particular aspects of the OO paradigm through example programs. A desirable feature of the JOOPA2 tool would be the automatic conversion of simple target applications into visualisations for use in a teaching environment. The teacher would then be free to concentrate on writing the application to best illustrate the features they wish to convey.

3

System Architecture and Implementation

Figure 1 illustrates the architecture of the JOOPA 2 tool. The core functionality of the tool is divided into two components, a Java Debug Interface (JDI) based debugger and an event driven visualisation engine. To initiate a visualisation of a program’s execution, the debugger invokes the applications main() method within a Java Virtual Machine (JVM). The debugger is adapted from the com.sun.tools.example.trace application supplied with the Java Debug Platform Architecture package supplied by Sun. The current implementation employs the 1.5.0 6 JVM. The debugger uses the JDI to request desired program events with the JVM. Events requested include: Class loaded to track the loading of new classes. Method entry to track thread stack push events. This event can also be used to identify new object instantations, since at the point of method entry the newly constructed object is assigned to the this field of the uppermost thread stack frame.

4

Figure 2: References from 3D engine entities to target entities in the JVM (via degugger and JDI).

Method exit to track thread stack pop events. Field modification to track changes to instance and static fields. Statement steps to track changes to method variables. A disadvantage of this approach (explained below) is that variable assignment changes in the visualisation may not occur in the right order. The debugger incorporates an event handler for each of the event types of interest. As events are collected from the JDI they are passed to the visualisation engine via the engine’s event interface. The events are used to alter the visualisation engine’s internal representation of the target application’s state, and thus alter the 3D visualisation that is rendered to the viewer. The visualisation engine maintains data structures that map the state of the target application within the JVM. All entities within the JVM are mirrored by entities stored within the visualisation engine. Further, all entities within the visualisation engine maintain references to the corresponding entities within the JVM (via the JDI interface representation). The references are used to obtain information about the targets to support the construction of the 3D visualisation. For example, in the case of a method, the method’s type, name, visibility, arguments and modifiers can be obtained by querying the debugger via the JDI. The relationship is illustrated in Figure 2. 3D mirror entities are thus used to generate visualisations of their respective targets within the JVM. Currently, the JOOPA2 tool maintains a visualisation of a single thread. A stack of method frames representations is maintained within the visualisation engine which mirrors the state of the target application thread (StackFrame3D). Each StackFrame3D stores references to 3D representations of variables. The engine maintains a store of loaded class (Class3D) representations and instantiated objects (Object3D). Both of these entity representations maintain stores of member methods and fields, with Class3D stores maintaining static members, and Object3D maintaining instance fields and methods. In the case of instance methods, a many to one relationship is created between 3D representations and the JVM entity. Arrays represent a special type of object in the visualisation, but are maintained as objects by the engine. To render a 3D visualisation of the target application state, a 3D universe is implemented using the Java 3D package [5]. Java 3D maintains a hierarchical 5

scene graph structure, to which all features of a 3D environment must be added, either for there 3D representation to be present (in the case of shapes), or for a components functionality to be executed (picking or translational behaviour, for example). JOOPA2 exploits this functionality by adding Object3D and Class3D entities to the scene at the scene root. Entity members (fields and methods) are added to the entities as sub-graphs. This allows clusters of shapes to manipulated collectively, by acting on the branches of the graph attached to the scene root, reflecting the structure of the Java OO paradigm itself. Multiple view platforms can be added to the scene graph, separately manipulated and rendered to separate canvases. This allows a user to set up different simultaneous view points on the state of the target application. Although the current visualisation engine only tracks a single application thread, this feature could in future allow the concurent execution of threads to be observed, a possibility that is discussed in Section 5.

4

Visualisations

This section describes the current features of the Java programming language (with respect to OO concepts) currently implemented in the JOOPA2 tool. Changes to the visualisation are caused either by events that are passed from the debugger to the 3D engine, or through a query of the debugger for information regarding an entity, as described in Section 3.

4.1

Entity Types

The type of an entity in a visualisation is represented by its colour. By default, void types (for methods are coloured grey). A user is able to preset colours for expected types. Colours for non-anticipated types are assigned randomly by the visualisation engine. More detail of the use of colour coding is explaining for each aspect of the visualisation presented below.

4.2

Class Load

Figure 3 illustrates a loaded class representation in the 3D environment. The class visualisation is implemented to mimic the representation of classes in a UML class diagram. A ‘flat’ rectangular shape is added to the scene, with the largest face divided into sections by horiztonal lines. The size of the class is scaled by the number of static members present, giving some (crude) indication of the complexity and size of the class. The upper most section of the face contains the local label for the class, in this case ‘HelloWorld’. The section immediately lower to this lists the static methods associated with the class, represented by a small sphere colour coded for the methods return type. In the example, two methods are listed, the main(String[]) method and, the static constructor for the class, (). The method label consists of the identifier of the method, any parameters and the return type. Below the methods, the static fields of the class are listed, represented by a box and a label. Each box is labelled with the field’s identitier and (local) type. Notice that primitive fields are treated differently to reference fields in the visualisation. Primitive fields (int, boolean etc) are represented by hollow

6

Figure 3: Representation of a loaded class (HelloWorld) in the JOOPA2 tool. The visualisation is modelled on UML class diagram notations, with static methods and fields listed on the face of the class.

boxes, in which the current value of the field is stored. Reference fields are represented by solid boxes from which association lines to relevant object are drawn (see Section 4.5. This differentiation between references and primitives is also maintained for method variables.

4.3

Object Instantiation

Figure 4 illustrates an instantiated object in the visualisation. An object are represented by regular cubes, the size of which are scaled by the number of instance members the object’s class possesses. As for classes, this gives some indication as to the size and complexity of the object’s class. Instance methods for the object are visualised in a similar manner to that of static methods for classes, although the methods are listed down the rear right hand edge of the object. Fields are visualised along the front left hand edge. This layout is intended to differentiate objects from classes in the visualisation. For the purposes of the visualisation, constructors are treated as being associated with class instances, since the constructor operates within the scope of an instantiated object.

4.4

Arrays

Visualisations of arrays in JOOPA are presented as a grouping of variables of the appropriate type. Figure

4.5

References

Figure 6 illustrates a reference from an array’s 0th index and a target object. The assignment of a object to a variable (a field, a local method variable, or an array element) is visualised by the ‘drawing’ of a line from the representation

7

Figure 4: An instantated object in the 3D visualiation. THe object includes visualations for non static members (methods and fields). The object is labelled and colour coded for its type (HelloWorld).

(a) A primitive array of type int and size (b) A reference array of type HelloWorld and 4. All elements of the array are currently size 4. Visualisations of references to Helempty. loWorld objects are visible. Figure 5: Visualisation of arrays in JOOPA 2

of the source variable to the target object. The leading tip of the reference line is represented by an arrow head to indicate the reference’s direction and the line is colour coded by the variable’s type (rather than the target’s type), to emphasise the notion that an object is treated as the type declared for the variable. When a variable is re-assigned to another object, the reference line is removed from the animation. The reference line shape is implemented as a bezier spline. The control points of the spline (other than the origin and end points) are configurable.

4.6

Method Invocation and Execution

Figure 7 illustrates the visualisation of a method execution in the JOOPA 2 tool. As the statements of a method are executed, a method execution edge is extended from the sphere representation of a method in an object or class. Local variables are placed along the edge as it extends and as they are declared. Parameters are treated as method variables and so are placed on the method execution edge when the method is first executed. To cope with multiple invocations of the same method on the same object or class, the angle of the execution edge is varied for each call. An animation is also include to visualise the call of one method by another. In Figure 7, the origin of a method call (to a HelloWorld constructor) is visible 8

Figure 6: Visualisation of a reference from the 0th index of an array to a HelloWorld object. The reference is represented by an arrow reaching from the point of origin ot the upper, rear left hand vertex of the target object.

Figure 7: Execution of the static main method from the HelloWorld class. The method is represented by a line with terminated by a small sphere (the point of execution reached). Arguments are visualised as variables, in this case String []: args. A variable has also been declared - HelloWorld:hh.

leaving the execution point of the main method. The extension of the call edge is similr to that of a reference edge, except that the end of the call edge is a sphere (the point of execution) rather than an arrow. A user can follow the sequence of method calls from the main method to the current point of execution.

4.7

Layout Control

The initial allocation of entities to space within the 3D environment is controlled by a Layout Manager. The Layout Manager is a pluggable component of the visualisation engine, and as such can implement layout policies as desired by a user. Each time a new entity is to be placed into the visualisation, the The default layout manager implements a basic 3D space filling algorithm.

9

4.8

Tool Configuration and Control

The visualisation can be controlled either by manipulating one of the views on the visualisation (view location and orientation); passing program control events to the debugger (halt, step forward etc); or by manipulating the 3D representation (object placement). To control the visualisation’s 3D environment, a simple GUI was implemented, which controlled the positioning of a user’s view platform with respect to the program visualisation. The view control uses the utility classes provided with Java 3D to permit the user to rotate and translate their perspective. In addition, the user is able to drag individual objects or classes within the visualisation. This feature, may be useful, for example, if a tutor wishes to concetrate on one particular object in view, by removing other objects from cluttering the view. Execution of the visualisation is controlled by issuing instructions to the debugger. The debugger’s execution speed can be controlled, as well as the ability to play and pause execution. One current limitation is that it is not possible to ‘step back’ through a program. In addition to controlling flow, the JDI can be used to register class exclusion patterns with the JVM. The JVM suppresses event generation for a class with a fully qualified name that matches one of the exclusion patterns. This feature can be used to reduce the complexity of a visualisation by omitting classes from standard libraries, or non-essential support libraries employed by the application. Finally, functionality is included to permit image and video capture of animations in progress. This feature is useful for producing pre-recorded visualisations, which can be incorporated into a lecture course, rather than risking software failure or a ‘live’ visualisation.

5

Future Work

This paper describes a work in progress. Several features are planned for future incorporation in the JOOPA2 tool, in order to extend the scope of program aspects that can be captured. Immediately planned extensions include: Threading and Multiple Views The JOOPA2 tool currently tracks only a single thread (main) during execution. However, the design of the visualisation engine would readily support the representation of multiple threads, whilst the debugger currently ignores events for other threads. An extension to this would be the provision of multiple views on the program so that concurrently executing threads could be observed in separate GUI windows. Thread of Execution Tracking Currently, the user is required to manually track the thread of execution across a program. A potential extension would be to have the user’s view platform automatically track the thread of execution, adjusting for zoom as necessary, etc. Method return values Currently, method return values are not explicitly visualised in JOOPA2. One approach would be for the method call edge on retraction to pass a reference to the return value to the calling method.

10

A future feature for visualisation under consideration is the potential to illustrate method logic under execution (if and for statements etc), using a more complex method execution visualisation. For, example, a if statement could be represented by a fork in a method execution edge, whilst a for statement could be visualised as a circle. The user would be able to track the precise point in the execution of a program from within the 3D environment. As the list of features of Java visualised by JOOPA becomes more comprehensive, there is potential to investigate the use of program visualisation in 3D for the purposes of debugging. Already, many IDEs incorporate visual aspects to debuggers. A potential avenue of research is the extent to which the 3D visualisation enhances this functionality. In addition, trials of the tool are planned for use in an introductory level programming course. The intent is to assess the usefulness to both students and teachers of providing a visualisation too for programs written in Java to enhance the understanding of the OO paradigm.

6

Summary

This paper describes the motivation, design considerations and implementation of the JOOPA2 tool. The tool provides 3D visualisations of the execution of programs written in the Java object-oriented programming language, including representation of classes, objects, references and method execution. Considerable future work to extend the tool is planned and it is intended to assess the usefulness of the tool for teaching object-oriented programming concepts and to provide a 3D environment for debugging purposes.

References [1] Sunita Asija. Visualization of object-oriented design models. Master’s thesis, Depaul University, Chicago, USA, December 1999. [2] M. Klling. The BlueJ Reference Manual. BlueJ, version 0.1 for bluej version 1.1 edition, July 2000. [3] Jonathan I. Maletic, Andrian Marcus, Greg Dunlap, and Jason Leigh. Visualizing object-oriented software in virtual reality. pages 26–38, 2001. [4] James Rumbaugh, Ivar Jacobson, and Grady Booch. The UML Reference Manual. Addison Wesley, December 1998. [5] Henry Sowizral, Kevin Rushforth, and Michael Deering. The Java 3D API Specification. Addison Wesley, second edition, 2000.

11