Information Visualization 533c

Project Proposal

Team Members:

Ed McCormick

Target Domain:
JQuery is a software engineering tool which was developed at UBC under the leadership of Prof. Kris De Volder with contributions made by Ryan Wannop, Prof. Gregor Kiczales, and students Doug Janzen, Ray Suprio, and Andrew Eisenberg. The project is funded by the (OTI) Eclipse Fellowship program and NSERC - and runs as a plugin for the Eclipse platform. The tool parses a system of code and enters it into a database. The user is then allowed to browse throught this system by running queries against the database. Each query becomes a node in a tree - with the results of the query as its children. The idea here is that a human making queries on a system of code will understand each successive query in terms of the results of the previous one, giving context to his current position in the tree. With each new query, it is the hope of the designers that the user will be able to 'zero in' on the piece or pieces of code he is interested in.

Aspect Oriented Programming deals mainly with the concept that a system of code can be decomposed many different ways, depending on what the programmer is interested in seeing or doing. The term "scattering" is used to represent one of the central ideas behind this methodology - that the code relating to what the programmer is interested in may not be contained within a single method, class or even package. Often, it is impossible to update a functionality whose code is scattered throughout the system and so the burden lays on the programmer to search for and identify each piece.

Personal Expertise:
I have been interested in this topic for some time now. JQuery is a tool that allows the software designer to view a system of code in a manor that is not explicitly linked to its structural organization. This is referred to a a 'crosscutting concern' within the Aspect Oriented Programming methodology. I have been studying AOP for some time and am familiar with the benefits and uses associated with it.  I plan to continue work related to this tool during my summer RAship.

Proposal:
Although JQuery provides a great deal of support in gathering scattered code through the use of the query engine - it appears that a great deal of improvement can be made on visualizing the results. Currently, as stated previously, the query history is displayed as a tree diagram - with each child node signifying a query made in terms of the parent node. There are some useful aspects of viewing the query this way:

However, there are many problems with viewing the query results in this way. Firstly, the only way a node in the tree relates to its parent is that they were successive queries. This can lead to two situations: Firstly, it may give the appearance of connections that do not actually exist. For example, if we run a query 'A', then a query 'B' on the results of 'A', and then a query 'C' made on 'B' - it may appear in the tree that 'C' and 'A' are somehow related. However, all that can be stated as a fact is that the user went through 'A' to get to 'C'.

The opposite effect can also occur: connections that actually do exist may be hidden by the tree. For example, a method returned by a query may actually be contained in a class that was returned in a query three steps back. This information may be pertinent to the task the user is performing - but currently it is up to the user to identify this connection.

It is proposed that to counter-act these effects, multiple perspectives of the current position within the naviagation be illustrated by linked views. The user will have the opportunity to choose perspectives, such as a 'hierarchy browser' and a 'method browser', to stay open while the navigation takes place. Each query result node that is clicked on by the user will reveal and highlight the corresponding position of that code from each chosen perspective (that it exists in). Each linked view will keep track of the last five nodes the user expressed interest in. This will be helpful in allowing the user to understand connections between (for example) the results of the last five queries he has perfomed. It is hypothesised that multiple perspectives is important for a query based process that may easily become complex and tangled if the user becomes confused or lost along the way.

The proposed layout is to allow the multiple trees to take up most of the screen. As the user identifies the code he wishes to update he will be able to either switch to a screen containing only code, OR close/anchor some of the perspectives trees.

A Scenario of Use:
A screenshot was found of a hypothetical navigation using the JQuery tool. It seems as if the scenario will be most useful by explaining how the user would have arrived at this situation - and then highlighting what would be different with the proposed additional perspectives.

In this hypothetical situation, a user is interested in how figures are implemented in the JHotDraw code base. He begins his investigation with a normal Package Borswer. He notices that there is a package called 'figures' and so the tree is expanded. He believes he would learn most about how figures are implemented through an examination of a figure class - and he also believes that since many figures exist in the application there is probably an interface or abstract class called Figure. If so, he would like to view that as well. He first opens the 'ElbowHandle' class - but a quick examination of the class and its supertypes gives him the impression that he is looking in the wrong place. He next examines the "EllipseFigure" class - and through a supertype query, quickly finds that he is in the right place.


It is clear that the user in our scenario was mostly interested in structural artifacts of this codebase. Therefore, it may have been useful to have an 'interface implementation browser' (showing all of the interfaces contained within the system with the class that implements each shown as a child node) and a 'package browser' open as this navigation was performed. The user would have quickly found the 'Figure' interface and would have a choice of viewing any of the classes that implemented it. While he was doing so, it may have been interesting to see where each class was in the class hierarchy.

Illustrations of the interface:

Proposed Implementation Approach:
JQuery is currently written in Java, as a plugin to the Eclipse Platform. I plan to add directly to this codebase - using the Eclipse toolkit for building plugins.

Milestones: