Peter Young
Visualisation Research Group


File-Vis


Select the above image to enter the 3D visualisation
or you can view the full size image shown above.

Image Gallery

Select an image to view full size

About File-Vis

The File Visualisation (FileVis) is a structural visualisation which is aimed at providing high level program information in order to assist the maintainer in familiarising themselves with a new software system. This familiarisation phase is typically the first point at which the maintainer will see the code or system they will be working on. Often this system will be completely alien to them and will require some initial investigation just to get some idea or feel for what they are dealing with. FileVis hopes to aid this process by creating a visual representation of the software system and allowing the maintainer to navigate through the code and investigate areas of interest. One of the main advantages of this approach is that it produces a physical (visual) manifestation of the system - you can actually see it as an object as opposed to a number of files in a directory. Characteristics and features can be made out and areas of interest can be quickly identified and investigated. The key point is that the software system is no longer an abstract mass of information, it has become something tangible, you can see the software.

FileVis, as the name implies, is structured around the various source code files in a software system and the contents of those files. Each file is represented within the virtual environment as a flat, coloured box or pedestal. This visualisation has been designed to visualise code from the C programming language. As such, there are two main types of file, definition files (.C) and declaration files (.H). These two file types are indicated by a glyph in the bottom right corner of each pedestal. A spherical glyph indicates a definition file and a cylindrical glyph indicates a declaration file. Files with the same name (i.e. test.C and test.H) are both coloured identically as the declarations in "test.H" should (though not necessarily) match the definitions in "test.C".

To show the dependencies between the various files a CallStax visualisation, which uses the file glyphs, is constructed in the centre of the visualisation. Selecting any of the glyphs in the CallStax or a glyph on a file pedestal results in the CallStax aligning themselves accordingly. From this it can be seen which files include other files or libraries, and also which files are shared through the system.

In its current state FileVis shows only the function definitions within each of the files. As such, only the definition files (.C) are populated whereas the declaration files do not yet contain any further information. The definition files are populated with all the function definitions defined in each file. These definitions are represented in two levels of detail depending on the viewpoint distance from the representation. The low level representation shows a single block for each function definition. The height of the block corresponds to the total line length of the function definition and the colour of the block corresponds to the relative complexity (using the McCabe cyclomatic complexity metric) of that function with respect to all other functions in the program. This complexity measure is encoded in a graduated colour scale which ranges from bright blue to bright red, corresponding to lowest complexity through to highest complexity respectively.

As the viewpoint moves towards a particular function representation, at a certain threshold the low detail tower will be replaced with a similar sized high detail representation. This high detail representation consists of a number of different information items or attributes related to that function. This includes various metrics such as complexity and a breakdown of the lines of code, comment and blank lines in the function. Additionally a simplified representation of the functions' control structure and textual structure is provided. This representation is presented in a similar manner to the Planes visualisation.

Above each function representation is a coloured and patterned cube which acts as an icon or glyph for that particular function. Each of these glyphs is unique for any function and can be used to discern between different functions and also to correlate with other information on the function. For example, when a function is selected then various information on that function will be shown in the left hand frames. The same glyph will be displayed with this information to enable correlation between it and the 3D visualisation. As the viewpoint moves towards a function representation, the glyph for that function will shrink so as to minimise screen clutter and background occlusion.

As previously mentioned, the high detail function representations contain various information and metrics which are represented in a number of different ways. Firstly, to maintain a relatively smooth transition and high degree of correlation between the low detail and high detail representations, they both share a number of similar properties. Although the high-detail representation is essentially an "open box", it shares the same dimensions as the low-detail function tower. The base size of the tower is a constant size and is consistent for both high and low detail representations. The height of the tower in the low-detail representation represents the total length of the function, measured in lines. This metric is preserved in the high detail representation as a back-plate to the open box. The height of this back-plate is equal to the height of the low-detail tower. An additional breakdown of the function length is provided by segmenting the back-plate into 4 distinctly coloured regions which show the proportions of lines of code, lines of comments, blank lines and code and comment lines. The base of the box is coloured to match that of the low-detail representation and corresponds to the relative complexity of the function.

Additional information on the functions is provided in the high detail representation. A number of variable height bars are stacked to the left showing further McCabe complexity metrics which include cyclomatic, essential, pathological and module design complexity. On certain function representations, a rotating blue and red box is shown to the front of the representation. If present, this box indicates that the function has received a number of revisions. The more revisions which the function has undergone, then the faster the box will spin.

Finally, a visualisation of the function source code structure and control structure is presented to the right of the function representation. This visualisation is similar to the planes visualisation and is constructed from a number of different coloured vertical planes which are stacked horizontally. As with Planes, the colour of each plane denotes a specific type of program scope or control structure. For example, green and red planes represent the condition true and condition false (respectively) sections of an if..then..else structure. Further control structures within any scope are built outwards and positioned so as to denote their relationship to the parent scope.

About the demo

This demo visualisation (as above) which was produced using Zebedee integrates three sources of information using available WWW technology. In order to view this demonstration you will require a frames compatible browser with Superscape's Viscape VR plug-in installed. It would also be an advantage to have a high color display configured.

It should be noted that the FileVis demo is only a concept demonstrator and is not fully completed. The 3D virtual world contains only a couple of files and functions which have been fully documented. These functions can be distinguished by the coloured cubes above their respective towers, undocumented functions have grey cubes.

Navigation through the 3D environment can be facilitated simply by using the directional control icons at the bottom of the frame. Alternatively, a more efficient though trickier control method can be activated by selecting the 3D frame then pressing the space bar. This produces a white box called the dead zone. Moving the mouse out of this box will result in movement through the 3D world. Various methods of movement can be facilitated by using the left and right mouse buttons in conjunction with moving the pointer. The left mouse button allows rotation control over pitch and yaw (i.e. turning on the spot) and the right mouse button allows translation horizontally and vertically (moving left/right, up/down while facing the same direction).


This page is maintained by Peter Young, please send any comments, jokes, insults or general abuse to (peter.young@durham.ac.uk).

Last updated: Thursday 15 May, 1997.