Aim

It was the purpose of my honours project to write a source code navigator that will aid in the task of comprehending a large, unfamiliar project. I hoped to use graphical representations of program structure to convey a more intuitive sense of the structure and purpose of the subsystems of the project, and to show the inter-relationships between them. The particular representations that were used included call dependency graphs, scope trees, class inheritance graphs, as well as displays of the original code itself.

When a programmer attempts to comprehend unfamiliar code, the code itself is actually much less useful than the extra information provided by the original programmer--comments, explanatory text files, naming conventions of the files involved, formatting of the code, and so on. Banner comments are used to separate large sections of the program, while blank lines are used to separate sections within a function. The code is the most important way to express to a computer what a program should do, but a programmer will gain an understanding much quicker if other methods are used. They provide a ``leg up'' to the programmer, so that they can then concentrate on the details of how the goals are achieved, rather than trying to understand what the original goals were.

I believe that the introduction of graphical user interfaces can provide an important additional mechanism for the communication of this kind of explanatory information. Therefore, my program was designed in the following way: the original programmer makes use of my program to create a picture of the program, which may give an indication of their intentions. Then, they save this information in a file, additional to the usual program code. When the code is distributed, subsequent programmers will be able to restore the representation of the code as the original programmer saw it (see Figure 1.1). Hopefully, the new programmer will gain a clearer insight into the original programmer's intentions from the way the program is presented. The navigator will also be able to read in existing programs and present them in as structured a manner as possible through simple mechanisms such as grouping together functions that are in the same file.

Figure 1.1: Communication between programmers via the navigator

I chose to make my program specific to the C++ language. This is because C++ is a language that already asks programmers to impose a more logical structure on their programs. C++ classes are logical constructs that group together functions that operate on the same data structures. This provides a useful starting point for extracting and displaying some of the structure of a program. The inheritance of members between different classes is a useful mechanism for defining the relationships between data structures, but it can be rather confusing when presented as simple code files, so the presentation of a class inheritance graph would be a useful role for the navigator to play.

I chose to write the program for the Unix environment, mainly because this is the environment I am most familiar with, but also because it seems to have been the slowest to convert to graphical user interfaces generally. If my program is to have an impact, I would like it to be in this area that needs it most. The particular system I worked on used the Linux operating system, but the navigator should be relatively easy to port to other platforms.

Since this is a heavily graphical program, it was essential to use a standard graphics interface--the X window system is the most frequently used, and the one I adopted. I used the freely distributable xview system to provide a high level interface to X, because it provides high level features such as file choosers while still allowing close control of the way the graphics are displayed.