1
Films as Graphical Comments in the Source Code of Programs Hanspeter Mössenböck Johannes Kepler University Linz A-4040 Linz, Austria
[email protected] Abstract We suggest to use animated pictures (films) as graphical comments in the source code of programs. Such pictures can be played forwards and backwards in steps under the control of the user. They can have multiple branches, which lead to different pictures. Animation effects can be applied to show how a picture changes over time. This can be useful for visualizing the dynamic behavior of programs. We show how to extend an object-oriented graphics editor so that it can be used for creating and viewing films. We also explain how such films can be embedded into the source code of programs using a text framework.
1. Motivation Program editors are rather conservative tools. While general purpose text processing systems exploit fonts, colors or pictures to make documents more readable, most program editors are just able to handle plain ASCII text. Although some more advanced editors use fonts and colors to highlight keywords or comments, it is still quite unusual to have pictures in the source code. This is surprising since many aspects of a program can be much better described with a picture than with a textual comment (e.g., data structures, class hierarchies, message sequences, etc.). In fact, many programmers do draw pictures when they design a program. These drawings are, however, often discarded when the implementation is done because they cannot be integrated into the program text. Of course pictures could be kept in a separate file (the documentation) and referenced from the source code. However, experience shows that such external documentation is less useful because it is not ready at hand and tends to get outdated when the source code is modified. We therefore recommend to store pictures directly in the source code. Such pictures can serve as graphical comments and often speak for a thousand words. In this paper we not only suggest to have (static) pictures embedded in the source code but even go a step further by suggesting animated pictures which can be viewed like films. The problem with programs is that their behavior is dynamic while a picture shows just a static snapshot. For example, when we want to describe how a data structure is changed by a process, we have to draw several snapshots (Fig. 1). It would be much more illustrative to show the effect of the process in a single picture using animation. call P BP
BP
SP SP
save BP
create new frame
BP return adr. SP
return adr. old BP
BP
return adr. old BP
SP
Fig. 1 Snapshots that show the stack manipulation during a procedure call
2 Let us consider another example. Complex pictures such as object interaction diagrams are hard to understand because it is not apparent in which order they are to be read. The diagram in Fig. 2 is taken from [Rum94]. It shows an interaction diagram with objects such as addButton and listKeeper as well as messages such as addItem and contents flowing between them. The author indicates the reading order by attaching sequence numbers to the message flows. Wouldn't it be much nicer to let the boxes, arrows, and messages appear one after the other on the screen in the order in which they are to be read? When a human is drawing such a diagram on a piece of paper, she will automatically draw it in the order in which it is to be read. In the final picture, however, the reading order got lost. Animation could help recording the reading order and conserve it for future readers.
addButton
1. addItem
1.2 add: text
1.1 text := contents
listKeeper
listContents
listPane 1.2.1 updateContents 1.2.1.1 contents := value
textPane
1.3 setValue: text
listSelection
1.3.1 updateSelection 1.3.1.1 selection := value
Fig. 2 A complex graphics that has to be read in a certain order In this paper we describe a tool that allows the user to record the drawing process of a picture and to replay it in a sequence of steps. The sequence can be played forwards and backwards like a film. It is even possible to define several branches of the film leading to different final pictures. The user can decide which branch to follow. We first describe how to use the tool and then sketch its implementation as an extension of an object-oriented graphics editor. Finally we show how such films can be embedded into the source code using a text framework.
2. What is a film? A real film is a sequence of frames that are displayed in a certain order. In our case a frame corresponds to a figure such as a line, a rectangle, or a piece of text. A picture is drawn by displaying its figures one after the other on the screen. In contrast to a real film, the figures don't replace each other but are added to the picture. We allow the user to set cut points between figures. Cut points are places where the drawing process should stop. The figures between two cut points make up a sequence. The basic structure of a film can thus be defined as Film = Sequence {cut Sequence}. Sequence = { figure}. We assume that all figures and cut points are linked together in the order in which they are to be displayed (Fig. 3).
3 figure
figure
cut
sequence 1
figure
figure
cut
sequence 2
figure
sequence 3
Fig. 3 A film consisting of three sequences The user can play a film forwards or backwards using a VCR like dialog (Fig. 4). Pressing the ">" button plays the film forwards showing all figures up to the next cut point (or the end of the film). Pressing the "" button. This will show the figures of sequence 1, i.e., a roofed house without windows. Pressing ">" again will add the figures of sequence 2, i.e., the house will have a door and two windows now. If she decides to go back to the previous snapshot she presses "" and "") and backwards ("
