Background

Considering that programming languages are specifically designed to express complicated concepts unambiguously and logically, it is surprising how difficult and frustrating it is trying to extract meaning from a large collation of source code. Source code might be quite readable at a small scale, but programmers need to understand the overall structure of a program before they can appreciate the design of an individual function.

Normally, the structure of programs can only be indicated in a very superficial style, by breaking the code into separate files or sections, and by indentation and coordination by alignment, as investigated by Lutze [8]. It is impossible to indicate the full complexity of the inter-relationships between functions using this method. Programmers are therefore left to create their own model of these relationships before they can understand the design of a function well enough to modify it.

The use of a graphical user interface provides a possible alternative to the standard ways of expressing program structure. Graphical user interfaces introduce several factors which could simplify the process of creating a mental model of a large program. The first of these is their ability to arrange objects in two dimensions. The placement of objects in a row, for example, could denote order of execution--two rows could denote two possible sequences. On the other hand, placement of objects in a tree structure can be used to indicate a hierarchical set of function calls. This flexibility is not possible with a text based system. The second factor is their ability to use graphical objects such as lines and boxes to show relationships between objects. Text based systems can only show relationships in a linear way, whereas lines and boxes allow much more sophisticated constructions. The third factor is the ability to ``point and click'' on an object to perform an action on it. If the intention is to gain more information on the object, then a considerable saving is likely over the method of hunting through source code for the additional information. Finally, as investigated by Rohr [18], graphical means of presenting information force users to ``think in images'', which turns out to be a much more efficient way of storing and retrieving information than thinking in text.

The most important area where these factors become significant is when a programmer has to work on a program written by someone else. The programmer will have to spend a considerable amount of time simply flicking back and forth through code. Waddington and Henry [23] suggested that such a programmer needs to recreate the intentions of the original author. This suggests that it would be helpful if the design of the program was presented, as well as simply the final result.

There have been several attempts to create such visual environments for programming, designed for different purposes: education [16,21], visualising data structures [12], and for software engineering [6]. However, these tend not to give the user freedom to impose their own spatial representation on the objects displayed. It is in this area that I hope that my project will extend the usefulness of programming aids.