Mik Kersten (beatmik-at-acm.org)
CS 533C Visualization Project, March 1 2004
The domain of this project is enterprise-scale Java integrated development environments (IDEs). Modern Java IDEs provide facilities for editing, compiling and executing Java programs composed of thousands of files. A key task that the programmer is faced with when working on these programs is the navigation of the structure of the system. For this the IDEs offer various overview+details mechanisms. These views, such as a document outline [Figure 1] are used to navigate across files containing the structure relevant to the developer’s task. The dataset for these views is the files that make up the system, the program structure defined by these files, and the navigation structure defined by the programmer's session.
The convention used for showing what files are opened is tabs that corresponding to each file, placed above the editor pane. This approach has not scaled [user discussion: Evolve the Eclipse user experience]. When too many files are opened either the editor window is obscured [Figure 2], or the names of the files are [Figure 1]. Another problem with the overview+details mechanisms is that they make it easy to lose context. In a typical session a programmer will have dozens of files open. The programmer’s mental map of the system is embedded in the relationships between the elements of the files, and is expressed by his or her navigation of the files. However, current IDEs do not expose these relationships, and instead require recollection and cognitive load from the programmer. The history navigation support in the Eclipse IDE helps by exposing some of the navigation structure (via back/forward navigation arrows similar to those found in a web browser). But this only exposes a list, and fails to show the graph structure of the programmer's navigation.
Figure 1: the Eclipse 3.0 IDE, with unreadable editor tab labels. Note the mouseover-based hyper linking of the "entry" method, used by the programmer to navigate references.
Figure 2: alternate editor tab approach taken by Borland's JBuilder X. After a long session too many tabs appear, and a common convention is to repeatedly select "close all".
While at Xerox PARC (1999-2003) I implemented the AspectJ tools framework and several plugins for Java IDEs. AspectJ is an aspect-oriented programming (AOP) extension to Java. Because aspects crosscut classes, the AOP programmer is forced to do more navigation and context switching than modern IDEs or the current AspectJ extensions do a good job of supporting. The goal of my thesis work is to make AOP structure a fundamental part of the IDE, and to expose it to the programmer with structured editable views. This project will explore how to model the underlying system, the programmer's navigation of it, and how to expose those using infovis techniques.
I propose to present the open files of highest interest in a way that matches the programmer’s mental map. This visualization will replace the editor tabs of the IDE. The dataset from the view will be composed of the following relationships between nodes (source files). Note that files are typed according to their suffix (e.g. “.java” and “.xml”. The following relationships and states will be used to model the programmer’s degree of interest degree of interest (DOI) [Card 2002]. The DOI will be modeled per-task. A task is user-specified, and is composed of a name and link (e.g. to a bug report).
The DOI model will be used to create a graph-based visualization of the user’s current working set of files, and to show the structural relationships between those files. Based on its DOI, a file can be in one of the above states, listed order of interest. The purpose of the DOI model is to provide a context for the programmer’s current editing activity. When a file is active, as many related files as possible will be shown. The higher the DOI the more likely it is for a file to be shown. Files with unsaved edits or with the topmost compiler error will have "guaranteed visibility" [Munzner 1997]. The DOI model will be a product of both program structure and navigation/edit history. For example, when a method in a particular class is being edited the view will make visible a method in another class that this one is overriding, the 5 files edited before this file, and the 2 library classes that had been navigated to from this file. In addition, the Pathfinder will offer a mode where related elements that have not been navigated to are presented. The DOI model will be persistent, and externalized in a file so that it can be checked into a source repository.
The goal of this project is to create a visualization that can be used to validate the DOI function. The driving purpose is to use such a DOI model to lay out a significant portion of the system at varying level of granularity on a large-screen-estate or high resolution display using focus+context techniques. This project will be limited to making a useful view that is constrained by the limited amount of horizontal space that current IDE users a willing to give up on a 1280x1024 monitor. A possible configuration is a 7x4 node grid with enough space for labels, icons, and edges between them (e.g. 900x100 pixels)
Step 1: Programmer starts on a task
The programmer selects a new user-submitted bug report form the Bugzilla database. The report contains a stack trace indicating a NullPointerException thrown in the TableViewer.java file.
Step 2: Pathfinder presents related structure
The programmer opens the TableViewer.java file in the Eclipse IDE, and navigates to the reference causing the problem in the "ISelection.class" library file. The Pathfinder displays the currently active file (highlighted with a thicker border) and places it in its containing package (package layers define the horizontal dimension). Note that structurally-related files are also presented: "SamplePlugin.java" is the file which contains it (via object-oriented association), and "ErrorHandling.aj" is the aspect which affects it (via aspect-oriented advice).
Step 3: task-related context is built up and presented
As the user makes progress in solving the bug, their navigation and edit structure is built up, the DOI model updated, and the visualization re-drawn. Note that nodes with a yellow highlighted border correspond to those with the highest degree of interest. Should the task of fixing the bug be interrupted (e.g. by the end of a work-day, or another task) the DOI model is saved so that the context the programmer built up can be presented again when the task is restarted.
Step 4: task is completed
The programmer commits the changes necessary to fix the bug into the source code repository. Along with these changes he or she commits the DOI model that was produced. When another programmer selects a related bug to fix, Step 1 will now present them with much more context related to this task then would starting from scratch.
The pathfinder will be implemented in Java as an Eclipse plugin. A unit test-driven development approach will be used. The UI will expose a visualization view as well as a preferences page. The DOI model will be externalized to a text file, most likely in XML format. The following APIs will be leveraged:
March 9 (1 week): core plugin infrastructure; rudimental DOI model understands current, edited, and viewed files; simple table layout of open files.
March 23 (3 weeks): object-oriented relationships in DOI model; tree-style layout of nodes.
April 6 (5 weeks): aspect-oriented relationships in DOI model; support for model creation, multiple models, and externalization of model to file; relationships drawn as edges between nodes.
April 20 (7 weeks): tuning of DOI mode and visualization; hardening for real-world use to enable validation by SPL lab members; considerations for extending to higher-resolution displays.