Using Pseudo-3D and Micro-metaphors to Visualize Software
December 15, 2012
Abstract — By expanding the “software as a city” metaphor to take advantage of micro-metaphors while limiting the viewport’s range of movement, a breadth of disparate information can be conveyed in a compact, intuitive manner. This novel combination of focus and context could enable less technical staff and computer science students to more readily grasp complicated software engineering topics; it could also improve experienced staffs’ ability to visualize ever more complicated software applications.
I. INTRODUCTION
The idea of visualizing software as a city is not a new idea, in 2003 Marcus, Feng, and Maletic described a three dimensional visualization system named sv3D which produced results that looked a lot like a city skyline [2]. The motivation behind their concept was to expand the amount of information that could be conveyed by visualization tools. SeeSoft, a popular visualization tool at the time, was two dimensional, and they believed that the most logical way to increase information bandwidth was to take advantage of the third dimension [7]. In 2007 Wettel and Lanza explicitly described a visualization that would take advantage of the software as a city metaphor [1]. They felt that the existing 3D software visualization applications did not provide viewers with sufficient waypoints by which they could navigate. Wettel and Lanza described the software as a city metaphor as a way of providing viewers with locality, or simultaneous focus and context.
This paper seeks to expand upon the software as a city metaphor in two seemingly incompatible ways. Firstly the amount of information conveyed to the viewer will be increased by adding a fourth dimension, time. Secondly the visualization will be simplified by limiting how the viewer can interact with the model. Ohio, USA
II. BACKGROUND AND RELATED WORK
Drive through any city in America’s Midwestern rust belt and it should become clear how a city can visually convey the passage of time. These towns have new buildings under construction, old buildings being renovated, boarded and abandoned structures, and empty lots where buildings once sat. The life phase of these buildings is obvious. Browsing through a source code repository can reveal the life phase of a piece of software or one of its components, but in a much less obvious way. If these two perspectives were merged then it would be possible to create a software visualization that presents software components in the latter software life stages as the more decrepit buildings in the midwestern United States analogy. Panas, Berigan, and Grundy described a visualization concept similar to this, though they fell back on using simple color highlighting to draw attention to certain attributes [3].
Rather than simply creating a matrix of color-coded rectangular prisms or realistic visualizations which have been caricatured, the software visualization tool described in this paper would literally display the software components as its analogous structure using micro-metaphors. The structures which represent parts of the code should look new if the code is new, they should appear more decrepit if the code it represents is in a latter life stage. Portions of the code under heavy development should have scaffolding over them.
These micro-metaphors could also be layered; a decrepit portion of code going through active reengineering should be both decrepit and scaffolded. Jerding and Stasko described a technique for creating information murals where the intensity of a colored area caries meaning [7]. With the approach explained in this paper, it should be possible to record the intensity of multiple attributes through the above described micro-metaphors. This adds expressiveness to the visualization; these types of visual cues we can add the dimension of time to our visualization in a way that is intuitive for the viewer. Figure 1. Examples of the micro-metaphors.
|
Figure 1. Examples of the micro-metaphors. |
When Marcus, Feng, and Maletic chose to use 3D for their visualizations they ran into the problem of occlusion; if a shorter graphical element was behind a taller one then it would be obscured [2]. To compensate for this problem they added transparency, the ability to filter out undesirable elements, and and exploded view. In practice, transparency is of limited value when numerous transparent items overlap. Filtering is a great feature and is one of Scheiderman’s seven high-level tasks for information visualizations [20]. However, it does not completely solve the problem of occlusion, especially when the tall elements in the foreground are of the same classification as the short elements you wish to see in the background. The exploded view can be useful, but is essentially just displaying different filters and separating them vertically creating a disjointed visualization.
The approach taken by Marcus, Feng, and Maletic is would intuitively seem to be better than the approach of floating elements in 3D space and forcing the viewer to navigate, untethered in space where user quickly loose context [2, 4, 5]. In their paper, Marcus, Feng, and Maletic contend that, based upon existing research, the 3D representations in general are superior to 2D representations. However, in the research cited by Ware and Franck, the study evaluated the performance of stereoscopic 3D versus 2D projections of 3D data [18]. Marcus, Feng, and Maletic mentioned stereoscopic 3D as a point of future work; their actual work seemed to most closely match the control case in the research by Ware and Franck.
As Wettel and Lanza pointed out, too much freedom can be disorienting [1]. This paper suggests simplifying the viewers navigation choices by taking the approach of using a fixed axonometric projection. This approach also produces a “quiet contemplative atmosphere.” [9] A dimetric projection would be the ideal candidate since it balances all three axes while producing crisp images. A fixed axonometric projection would still suffer from the same failings as a pure 3D representation, but the fixed nature of this view will allow for those shortcomings to be mitigated in a ways which maintain the views sense of focus and context.
Using a fixed projection would mean that the program would really only need a 2.5D environment; the viewport could only be zoomed and rotated about the z-axis at ninety degree increments. Research by Modjeska and Chignell has shown that this type of navigation is easier for users [17]. And, as an added bonus, this arrangement would work well with the navigation paradigms found on modern tablet computers.
On a desktop computer the viewport cursor would cast a shadow upon the virtual city’s ground, which matches the shape of the structure it is hovering over. Tablet users would have to touch an element to get more details. A heads up display or modal dashboard would give more details on the currently highlighted structure. It may even be desirable to add a slight bit of transparency to deselected elements, if this could be done in a helpful, non-distracting way. A user of the software would learn the precise meaning of the micro-metaphors simply by exploring the scene with the cursor, or their finger, and noticing the description provided in the dashboard. Maletic, Mosora, Newman, Collard, Sutton, and Robinson have already described the value of multiple coordinated views [12]. The user interface should invite the user to explore and learn; coordinated views help foster this approach.
A 2.5D rendering would bring much of the information carrying capabilities of a full 3D environment while simplifying the viewers controls and giving them an immersive yet grounded perspective. Gaming inspired visuals would inform the viewer of software structures’ evolutionary state. Not only would the “softwasre as a 2.5D city in the rust belt” metaphor work well to help nontechnical people visualize software, it could also be a great tool for teaching software engineering methodologies. Furthermore, as the average size of applications grow,  the need for more intuitive visualizations becomes more acute, even for experienced developers.
III. IMPLEMENTATION
A. Data Generation
Good software visualizations are dependent upon good data. However, data collation and visualization are two distinct tasks which should be separated to maximize overall flexibility [12]. An existing tool which has been optimized for extracting information from code should be used to prepare data for the type of visualization software described in this paper. It should also be assumed that the visualization software will run on a tablet computer; separating data gathering and visualization makes it possible to use existing data manipulation tools to extract information from a variety of platforms while still allowing for consumption of the results on a mobile device.
Heuristics would be used to determine the health of a given class. The results of the heuristic algorithm would set the life stage visualization, or how decrepit the class’s icon appears. This algorithm would have to be tuned in such a way that evolving software appears to be under construction, with scaffolding in the visualization, while software in the servicing phase appears dilapidated in the visualization.
B. Visualization Layout
The actual layout of the visualization is inspired by MosaiCode, SeeSoft, and the work of Wettel and Lanza. Since the application being visualized is the city, the packages would be boroughs or neighborhoods and the classes buildings. The algorithm which places the buildings would cluster them in such a way that the associations should be fairly obvious, but there would also be switch on the main screen that would allow for the buildings to quickly be hidden and the city districts to be revealed. The oldest classes would be placed in the center of the visualization; as they are replaced their land would not get reused and the visualization would show a type of urban sprawl.
The height of a building in the visualization would correspond to the number of methods, while the footprint of the building would represent to the number of attributes. The visualization will use hand-crafted graphics, so the heights and footprints of buildings would have to be converted from continuous to discrete values using a clustering algorithm. This also makes it easier for the viewer to Figure 2. Example of the visualization GUI. grasp the data which is being presented [1, 21]. However, clustering the data would make it difficult to compare two separate visualizations. To make this drawback clear to the viewer, a scale would be presented which is similar to those used in cartography. Classes where the ratio of methods to attributes is excessively high would be represented as antenna towers, and classes with a high ratio of attributes to methods would be represented as parking lots [1].
The visualization keeps track of multiple software version, so it would keep track of the maximum number of methods and attributes for any given class. These high-water marks would be seen in the visualization. A class which once had many more methods than in its latest state would display as a building which has the lights turned out on a representative number of upper floors. Similarly, if a class no longer has as many attributes as it once did, then its footprint would be larger than the building’s footprint; the building would be surrounded on its lot by open space.
 |
Figure 2. Example of the visualization GUI. |
C. Visualization Navigation
This visualization will primarily be navigated using gestures which are standard for modern tablet computers. On a deskotp computer that does not support these types of gestures additional on screen controls would have to be added to compensate for the lack of multi touch. It will be possible to pan the image by using two fingers and to zoom by pinching the viewport. Touching an item will bring up details about the structure, if the modal detail window is open. The detail window will give more information about the class and provide options for hiding the class. Other features, such as viewing the district floorpan, will be immediately available by touching the appropriate button.
IV. POSSIBLE FURTHER USES
D. Life Stages
The visualization described in this paper is designed to use micro-metaphors to represent the passage of time, so it lends itself to being used for demonstrating software life stages. An application in the evolution life phase would be filled with classes that appear to be under development while an application in a latter life stage would appear brown and decrepit, thus immediately signaling that its unhealthy condition. These micro-metaphors should immediately signal to management the amount of effort, and more importantly money, required to maintain the code base.
E. Government
If the reach of software revision control systems is expanded, for example to keep track of legal codes, then this software could be expanded with additional micro-metaphors which would help comprehension in the new domain. In the case of law codes, the buildings could be literally billboarded with the logos of sponsors or lobbyists of certain portions of he code.
V. CONCLUSIONS AND FURTHER WORK
F. Conclusions
It has been demonstrated that the approach of using 2.5D visualization can convey more information than a 2D visualization while providing more context and focus than a 3D visualization. The use of micro-metaphors allows for further data to displayed in a way that should be intuitively understood by a diverse audience.
G. Further Work
In order for this visualization to convey life stage information properly, heuristics must be developed which can determine a given components life stage. Without appropriate heuristics the micro-metaphors which represent the life stage could never be activated. Also, users of this visualization must be aware that multiple versions of the code base should be provided, otherwise the visualization will not be able to convey the appropriate life phase visualization. It may desirable to give the user visual feedback when the data provided is incomplete. Perhaps unversioned components could have a blinking exclamation mark above them and the details of the alert would be displayed in the detail window.
