We describe Gevol, a system that visualizes the evolution of software using a novel graph drawing technique for visualization of large graphs with a temporal component. Gevol extracts information about a Java program stored within a CVS version control system and displays it using a temporal graph visualizer. This information can be used by programmers to understand the evolution of a legacy program: Why is the program structured the way it is? Which programmers were responsible for which parts of the program during which time periods? Which parts of the program appear unstable over long periods of time and may need to be rewritten? This type of information will complement that produced by more static tools such as source code browsers, slicers, and static analyzers. 1

This paper describes the integration of an interactive visualization user interface with a knowledge management tool called Protg. Protg is a general-purpose tool that allows domain experts to build knowledge-based systems by creating and modifying reusable ontologies and problem-solving methods, and by instantiating ontologies to construct knowledge bases. The SHriMP (Simple Hierarchical Multi-Perspective) visualization technique was designed to enhance how people browse, explore and interact with complex information spaces. Although SHriMP is information independent, its primary use to date has been for visualizing and documenting software programs. The paper describes how we have applied software visualization techniques to more general knowledge domains. It is hoped that the integrated environment (called Jambalaya) will result in an easier to use and more powerful environment to support ontology evolution and knowledge acquisition. An example scenario of how Jambalaya can be applied to knowledge acquisition is provided. 1

Abstract not found

This paper describes a multi-perspective software visualization environment, SHriMP, which combines single view and multi-view techniques to support software exploration at both the architectural and source code levels. SHriMP provides three different views: a primary nested view and two subsidiary views. The primary nested view employs fisheye views of nested graphs, provides contextual cues, and supports general exploration activities. In SHriMP, subsidiary views exist as a searching tool and a relation tracer. These views complement each other and allow programmers to examine a software system from multiple perspectives.

Recovering the architecture is the first step towards reengineering a software system. Many reverse engineering tools use top-down exploration as a way of providing a visual and interactive process for architecture recovery. During the exploration process, the user navigates through various views on the system by choosing from several exploration operations. Although some sequences of these operations lead to views which, from the architectural point of view, are mode relevant than others, current tools do not provide a way of predicting which exploration paths are worth taking and which are not. In this article we propose a set of package patterns which are used for augmenting the exploration process with information about the worthiness of the various exploration paths. The patterns are defined based on the internal package structure and on the relationships between the package and the other packages in the system. To validate our approach, we verify the relevance of the proposed patterns for real-world systems by analyzing their frequency of occurrence in six open-source software projects.

Programmers need tools to help explore large software systems when performing software evolution tasks. A variety of tools have been created to improve the effectiveness of such exploration. The usefulness of these tools has been argued largely on the basis of case studies, small narrowly-focussed experiments, or non-human-based experiments. In this paper, we report on a more rigorously controlled study of three specialized software exploration tools in which professional programmers used the tools to plan complex change tasks to a medium-sized code base. We found that the tools had little apparent effect; the effects observed instead appear to be dominated by individual styles and strategies of the programmers and characteristics of the tasks. In addition to presenting the results of the study, this paper introduces the use of two experimental evaluation aids: the NASA Task Load Index (TLX) for assessing task difficulty and distance profiles for assessing the degree to which programmers remain on-track. 1.

Developers need to evaluate reusable components before they decide to adopt them. When a developer evaluates a component they need to understand how that component can be used, and the behaviour that the component will exhibit. Existing evaluation techniques use formal analysis, sophisticated classification/search functionality, or rely on the presence of extensive component documentation or evaluation component versions.

The paper describes a system, Imsovision, for visualizing object-oriented software in a Virtual Reality Environment. A visualization language (COOL) is defined that maps C++ source code to a visual representation. Our aim is to develop a language with few metaphors and constructs, but with the ability to represent a variety of elements with no ambiguity or loss of meaning. In addition, the visualization has to maximally use the potential of the used media. The design of the OO software system and its attributes are represented in the visualization. Class information, relationships between classes, and metric information is displayed. VRML is used for the visualization and it is rendered in the CAVE environment.

Introduction The problems faced by an individual trying to understand a software system are very difficult. As the size of software systems increases so do the complexities in understanding. A reasonable solution to this problem is the construction of software tools that assist us in the comprehension tasks. An obvious way to assist us with this problem is to build visual representation of the software. For example, the Unified Modeling Language (UML) uses a graphical notation to describe software in a visual manner. While these types of notations allow for an abstraction of an existing software system, they do not scale up well with respect to comprehension. That is, it is quite difficult to "see" an entire software system with these notations and tools. They suffer from the same cognitive related problems as source code. There is a critical factor limiting these notations (and other software visualization tools), namely they represent the information in only two visual dimen

This position paper addresses the issue of how software visualisation should develop in the future. A number of useful visualisations have been developed by the software visualisation community but these have usually been through standalone tools. Is it now time to consider if and how these visualisation tools can be integrated into development environments and be used as roundtrip visualisation tools. If this is not addressed then software visualisation research may have come to a useful end. 1