A Program Visualization Meta-Language Proposal

There is much support in the literature for the idea that novice programmers can benefit from visual representations of the execution of their code. Many systems exist which make such illustration available but the majority of such systems are monolithic they apply a particular visual metaphor to programs written in a particular programming language. Computer science educators are eager to evaluate a variety of approaches to visualisation but there may be no available system that combines a particular programming language with the desired visual metaphors. This paper proposes a language through which an executing novice-written program could communicate with an arbitrary "visualisation engine" thus separating the two ends of a program visualisation into individually configurable components. The effect would be to expose program visualisation to a wealth of evaluation from educators and hence draw some conclusions as to the efficacy of a variety of approaches. 2. Introduction "Program Visualisation" (PV) sets out to give a computer programmer some visual representation of the execution of their program in order that they might better understand the precise behaviour of the program. This may be especially helpful for a novice programmer who might not have an adequate set of mental concepts with which to understand the execution of a computer program. Much research has been done into PV and a plethora of PV systems have been developed. Every PV system has the following two fundamental components: A way for the programmer to write and then execute a program in a specific programming language. This program, when it is executing, can be termed the "visualisation target" A means to display visual artefacts that represent the state of the target program whilst it is executing. This component can be termed the "visualisation engine" In general a PV system consists of an implementation of each of these components together with a means for the target to control the engine. PV systems are large and complex pieces of work and may have taken the designers and researchers involved person years of effort to generate. A review of the literature surrounding PV reveals one astonishing result. Despite the enormous amount of effort that has gone into the creation of PV systems there has been comparatively little investigation of the actual efficacy of the PV approach in assisting novice programmers. The usefulness of PV to Novice Programmers has not been convincingly, empirically, demonstrated by objective ( rather than experiential ) studies. Perhaps this is understandable given the effort required to implement a PV system once the system has been developed there may not be resources available to thoroughly evaluate its usefulness nor may there be a motivation to call into question a system that is the result of so much effort. Consequently there are not as yet any reliable means to assess the relative effectiveness of PV solutions. Each PV system stands alone, accompanied by the efficacy claims of its authors, much anecdotal evidence from students who have used it and a generalised feeling that something good is happening. What appears to be happening here is that there are two distinct areas of expertise overlapping the technical computer skills that enable a PV system to be implemented and the empirical research skills that enable experiments to be designed that evaluate the effectiveness of an educational tool. Though these roles may overlap to a certain extent where certain researchers are concerned, an arbitrary educational researcher is obliged to work with one or more fixed PV systems and is not in a position to suggest arbitrary, incremental changes in the way that programs are visualised. The basis of this inflexibility lies in the monolithic nature of most PV systems. Although the "target" and the "engine" are usually clearly delineated the means by which they communicate are particular to the PV system under consideration. It is not, in general, possible to have the "engine" from one PV system driven by the "target" of another. Consider a pair of sample scenarios: An educational researcher wants to compare the efficacy of two different visual representations of novice C programs. The question being put might be "How do boxes and arrows compare with 3-D visual worlds as a means to assist novice C programmers?" Comparing these requires a target C program to be connected to either of two visualisation engines. A second educational researcher want to investigate the comparative benefits of a certain representation model for different programming paradigms. The question might be "Does the visual metaphor of a stock market help Java programmers more than Prolog programmers?" This evaluation requires two different target programs to be coupled to the same visualisation engine. The PVML concept is aimed at this target/engine boundary. PVML would be a standardised protocol for PV Target/Engine communication and its realisation will enable arbitrary combinations of PV target and PV engine to interoperate. The target/engine boundary may in fact bridge multiple, remote computers. PVML can be the language through which components of a distributed visualisation communicate with each other. 3. Existing Work The motivation for a PVML proposal has arisen in the context of earlier work on the part of the author [21] in which he argued that a Programming Environment that especially targeted novice programmers should include, amongst other features, PV capabilities. It was also argued that it would be desirable to deliver this environment through a Web browser interface and that this would necessarily involve a client/server architecture. It is not the author's intention to restate that case in this paper but rather to move on to a closer examination of the actual implementation of PV that would be required. It is sufficient to note though that the investigation of PV systems in which the Target and Engine are substantially decoupled has arisen in the historical context of an architecture for a Programming Environment that actually sets out to run the Target on a server and the Engine in a Web browser. A central aspect to the treatment offered here is a clear statement of the human roles involved in visualisation. As the analysis of PV techniques unfolds the location, in a given system, of these roles will be become a key component of the architecture being proposed. These points of view represent the roles of the various human agents that are required to design, build and then use a Program Visualisation system The explanation offered is that of Blaine Price [16] but there is little disagreement on this matter in any of the literature reviewed. The roles considered will be those of: 1) Programmer the person who wrote the program that is being visualised ( referred to here as the "Visualisation Target" ). As Price observes the programmer might not have been aware that their program was to be visualised and they also may not ever witness the visualisation of their program. 2) SV Software Developer also, as Price notes, a programmer but in this case the program that they wrote is the one that enables other programs to be visualised. 3) Visualiser the person who used the SV system to design and build the particular visualisation that is being considered. Often this role and that of the SV Developer may overlap but an important distinction that is made by this separation is the relative involvement with cognitive rather than technical programming issues. 4) User the person for whose benefit the visualisation is presented. The effectiveness of a SV System would be gauged by its effect on the User's understanding of what is being visualised. It should be made clear that these roles are not necessarily held by distinct human players. In some cases a single person may wear all four "hats" but the roles do embody important, and distinct, areas of concern in approaching any SV system. An examination of the recognised taxonomies [12] [3] [19] [16] [18] of Program Visualisation reveals that a major axis along which PV systems may be categorised is the distinction between Program and Algorithm Visualisation. The important feature here is the extent to which the PV system involves abstract representations of program activity that are not closely mapped to the actual implementation of the program. Whilst some efforts [7] have been made to use AI techniques to generate these abstract interpretations most attempts to provide such non-literal visualisations of program execution have relied on other approaches. In "A Taxonomy of Program Visualisation Systems" [18] Roman associates the automation of visualisation generation with his category of "Specification Method" which "encompasses the means whereby the animator specifies which aspect of a program are to be extracted and how they are to be displayed". He decomposes the Specification Method into a series of broad types of technique and these relate closely to the PVML proposal: Predefinition This is a fixed mapping between program state or events and the display as implemented by a variety of "debugger" style environments. The user is not given the opportunity to modify the semantics of the display and there is no input from the "Visualiser" role. Annotation Annotation of the programs being visualised is the predominant technique for imposing the visualisers will on the display where a higher level of abstraction from program code and data is required. Sometimes referred to as the technique of "Interesting Events", the annotation, inserted into the program by the Visualiser designing a visualisation or by the programmer seeking to expose program behaviour, has the effect of updating the display in some manner