Visuo-spatial Programming: Visualising software structure to aid the integration of egocentric software navigation into an allocentric spatial cognitive map that supports software navigation and composition

Abstract

Despite extensive research into the cognitive processes used by programmers to form a functional mental model of software during program comprehension, there has been little research into how the structure of software is represented within long-term spatial memory. It is conjectured that this lack of emphasis on the spatial aspects of code has inadvertently resulted in mainstream software development environments not adequately supporting relative navigation of the software call graph, which results in programmer disorientation. While software understanding tools for visualising object-oriented software have been developed that leverage spatial memory, opening a class to reveal its source code usually obscures the spatial representation and also places the source code in a single common location that has no spatial relationship to the code just navigated from. This is likely to interfere with the integration of spatial information related to individual source code files into a common cognitive map within spatial memory. A key challenge that tool designers face is that, for any non-trivial program, it is impossible to represent all of the source code of a program on the screen at once. Recent prototype environments have used a variety of strategies, including using a semantic zoom that allows classes to be represented with differing amounts of information visible, allowing fragments of classes to be arranged on independent surfaces, and representing individual methods as bubbles that can be grouped within a scrollable workspace. This project has taken a different approach by conferring a spatial structure on source code that is based on its emergent structure, and implementing a visualisation technique that uses this structure to provide a consistent spatial representation of methods. The method-flow visualisation technique has been developed to support short-term spatial memory by placing editor columns within a scrollable flow view that ensures each column maintains a consistent spatial position if scrolled. As the programmer navigates a call graph by following hyperlink-enabled method calls, editor columns are added to the right- hand end of the flow view. At any time, the programmer can scroll the flow view to see previously traversed methods. It is theorised that method-flow allows short-term visuo- spatial memory to be refreshed, and provides more time for methods to be integrated into a cognitive map within spatial memory. Method-flow has been implemented as the Visuocode prototype software development environment and has been both informally and formally evaluated. Formal evaluation consisted of two qualitative think-aloud studies — the first of software navigation, and the second of program composition. Both formal studies asked each participant to perform a number of programming tasks using both Eclipse and Visuocode. During the studies, the screen activity of participants was recorded using screen-capture software, and later analysed to determine the number and type of navigations performed during each session. During both studies, participants performed more relative navigations while using Visuocode than while using Eclipse, and performed more direct and scrolling navigations while using Eclipse than while using Visuocode. While using Eclipse, participants tended to open classes, and then scroll down through them to discover class interrelationships – forming a mental model based on the program’s composition hierarchy. In contrast, while using Visuocode, participants tended to open the outline of a class, and then use method- flow to traverse the call graph to discover how classes interrelated – forming a mental model based on the program’s call graph. Further research is required to determine the advantages and disadvantages of either form of mental model. It is concluded that the method-flow visualisation technique is both intuitive to use, and also useful, as all participants used method-flow extensively during at least one activity. Method-flow was extensively used to navigate code during the software navigation study, and during such navigation no participants were observed to become disoriented while backtracking. During the program composition study, although method-flow was mainly used to refer to Javadoc documentation, Visuocode functioned as an effective environment for composition — two out of the three participants who successfully completed a task did so using Visuocode. One issue with method-flow was identified. While using Visuocode during traversal of the call graph, participants are often not made aware of other methods that are contained within any classes traversed — analogous to a horse that is ‘blinkered’. After their sessions, one participant expressed feeling misled by method-flow, and another mentioned that it took a while for them to get used to not looking at whole source files. In conclusion, while method-flow is considered to be a promising technique for navigating software, the effects caused by being ‘blinkered’ need to better understood.