Abstracts - 2007
Relo: Helping Users Manage Context During Interactive Exploratory Visualization of Large Codebases
Vineet Sinha, David Karger & Rob Miller
As software systems grow in size and use more third-party libraries and frameworks, the need for developers to understand unfamiliar large codebases is rapidly increasing. We are building a tool, Relo that supports users’ understanding by allowing interactive exploration of code. As the developer explores relationships found in the code, Relo builds and automatically manages a visualization mirroring the developer’s mental model, allowing them to group viewed artifacts or use the viewed items to ask the system for further exploration suggestions.
Working with the complexity of large software projects is a pervasive and growing problem. Developers face increasing difficulties in comprehending and maintaining a mental model of the code in large codebases. While techniques like object-oriented programming and design patterns have helped control complexity by allowing developers to create and use appropriate abstractions and encapsulate inessential details, these techniques require a developer reading the code to follow many kinds of relationships at once. For example, following a function call, once a simple task, now also requires keeping track of inheritance and polymorphism.
We present a program comprehension tool called Relo, which helps developers to understand the roles of the multiple types of relationships in a software system. Relo visualizations start with a single code artifact (such as a package, class, or method), from which a user can browse the different types of relationships to incrementally add more code artifacts. Relo helps maintain context while users manage the visualization by choosing to remove or group artifacts together. Such visualizations, like concern graphs  , represent only a small manageable part of the code and do not include irrelevant details allowing a user to focus on the important relationships.
Relo visualizations try to be intuitive to end-users, showing code artifacts in diagrams similar to UML class diagrams, while at the same time allowing developers to zoom in to view and edit code using text editors embedded in the graph. Developers can therefore abstract to a high level, or zoom-in to see code. Relo further helps maintain users’ focus by providing explicit support for exploration while managing the amount and presentation of information to the user based on his/her interaction with code elements  .
Most previous approaches have supported large projects by using multiple distinct views, each supporting only a single predetermined relationship (like inheritance or method-call hierarchy) — with the views implemented graphically  or in most IDE’s as tree widgets. To overcome the loss of context in connecting these views Relo brings the different relationships together in a single view and uses diagrammatic constraints, such as containment or left-to-right ordering, to aid in representing the relationships between elements. While Relo uses visualizations it focuses on users expanding the diagram across any relationship, instead of just expanding by visual containment as in , and tries to minimize the apparent loss of relationships between elements that are not direct descendents as found in other approaches when following more than one type of relationship  .
Figure 3. Clicking on the
Figure 4. Expanding the class
We illustrate how Relo would be used by a developer for typical comprehension
task. For this example, we use a task similar to that used by JQuery 
. The task involves a developer working with the
A developer following the above steps using a traditional IDE will typically make rapid progress in the first three steps, finding a starting class (using simple heuristics and search queries), examining it, and selecting an appropriate base class. However, at step 4, when the developer selects a method that is called for manipulating figures and tries to examine the callers, he will have difficulty in keeping track of the various examined code artifacts. The difficulty will occur because of the desire to maintain a context when examining the roles of nodes connected by multiple relationships — in this case: the inheritance, containment, and method calls relationships.
This scenario would be simple with Relo. As the developer looks at the
code, he will find that
Figure 1 shows that the class has 15 members, and the developer clicks
on the menu to see a list. Considering the method
Once the developer has an idea of the inheritance tree of figures, he
chooses to expand the
The developer is presented with Figure 4, which shows the implementation
of the method. After finding the implementation relevant, the developer
will want to find a relevant caller of
Once presented with figure 5, the developer can easily select relevant classes that manipulate figures, and does not have two worry about connecting inheritance, containment, and method call relation-ships. As the developer continues with his task, he can build a larger visualization and choose to refine the generated diagram, so that the visualization helps in his understanding of the code base.
Figure 5. Asking for callers of
Relo tries to reduce cognitive overhead by using topological constraints to assist in providing a default layout of code elements, so that elements are found at expected locations. For example, wherever possible, inheritance edges are drawn vertically, method calls horizontally, and containment is shown by visual nesting.
Relo shows children of items in one of three ways. At the most constrained, children of classes are shown using a vertical layout; a more relaxed graph layout engine is used by default on children of packages; while in cases when the containment hierarchy is not important children are laid out independently of the parent. Relo allows users to select an element and get it to breakfrom its current layout, into one of the three options.
Instead of requiring users to navigate property dialogs to configure
relationships to be shown or filtered, Relo uses ‘navigation aids’
to allow navigating and extending the visualization with simple clicks.
For example, as shown in Figure 1, when the
Relo further helps users explore through the code by implementing an Autobrowse feature, which effectively does a breadth first search finding other hidden artifacts that are relevant to the selected items. Since some relationships, like inheritance are considered more important than others, they are searched first, with the system terminating after an item is added to the view. Users can either select a few items to have autobrowse run on a smaller set of items, or can use autobrowse repeatedly to keep adding items. Relo further helps users by automatically adding relationships between shown items. To reduce clutter, Relo uses browsing agents that automatically add relationships to items that have not been ‘broken’, i.e. code artifacts that are not laid out vertically next to each other, such as the default for methods in a class.
Level of Detail
In order to minimize cognitive overhead on users, every element presented in a Relo visualization, defaults to showing as little information as possible. Users can semantically zoom-in by double clicking on an element or selecting the expand navigation aid (‘+’) to show more details. For classes, this means starting with only the class name, and at the first expansion level showing the children members having public access. For methods, expansion would mean showing the method implementation in an editor view. Users further have finer grain control of shown items by using the more items menu to get a list of children and add only the relevant items. Similar to expanding, users can also collapse code artifacts by clicking on the ‘-’ navigation aid, or selectively eliminate artifacts by clicking on the ‘x’ navigation aid.
When hiding a shown code artifact that have relationships to other artifacts,
the simplest approach is to hide all relationships originating or terminating
at the element being hidden. However, Relo implements the more sensible
choice of allowing relationships to be transitively visualized. In Figure
1, when removing the
Progress and Future Work
Relo is built as an integrated plug-in into the Eclipse development environment, and is freely available from: http://relo.csail.mit.edu. We are conducting evaluations of it, and are finding that developers are examining the code using an ‘opportunistic strategy’, i.e., not examining the code in a systematic manner. Thus, while one developer might find Relo to be very useful for a task another developer doing the same task could find Relo to not be useful. We are targeting to characterize these situations and find means for Relo to help developers be more ‘opportunistically successful’. Furthermore, Relo builds visualizations similar to UML class diagrams. There are a number of situations, such as those when developers try to understand a small set of methods when exploration of more detailed diagrams similar to UML’s interaction diagrams will be helpful. We are currently working on providing multiple types of views of the code for exploration by developers.
We would like to thank David Huynh, Derek Rayside, Mike Ernst, and Daniel Jackson, for comments and help with this research. This work has been supported by the MIT Oxygen Project.
 Sinha, V., Miller, R., Karger, D. R. “Incremental Exploratory Visualization of Relationships in Large Codebases for Program Comprehension”, Poster, Demo & ETX workshop, OOPSLA 2005.
 Storey, M.-A., Muller, M., and Wong, K. “Manipulating and documenting software structures using SHriMP views”, ICSM 1995.
 Janzen, D., and Volder, K. D. “Navigating and Querying Code Without Getting Lost”, AOSD 2003
 Teevan, J., Alvarado, C., Ackerman, M. S., and Karger, D. R. “The perfect search engine is not enough: a study of orienteering behavior in directed search”. CHI 2004.
 Martin P. Robillard , Gail C. Murphy, “Concern graphs: finding and describing concerns using structural program dependencies”, ICSE 2002.
 Reiss, S. “Visualization for Software Engineering — Programming Environments”, Chapter 18, pages 259-276, in “Software Visualization”, ed. Stasko et al.
 JHotDraw. http://www.jhotdraw.org