Fluid Source Code Views Michael Desmond University of Limerick & University of Victoria
[email protected]
Margaret-Anne Storey University of Victoria, Victoria BC, Canada
[email protected]
Abstract Fluid documents enable the interactive incorporation of related material into a primary document. Visual cues within primary material indicate that related content is available and user interaction reveals related content in context. Fluid documents reduce the need for explicit navigation, maintain context when considering related material and support synthesization of disjoint yet related information. Source code documents are an excellent medium for the application of fluid document technology. The definition of software in the form of text based documents manifests a highly linked and fragmented information space requiring considerable navigation between elements during code examination and comprehension. In this paper we present fluid source code views, the application of fluid document technology to source code documents.
1. Introduction The information presented in a document often consists of primary material and related or supplemental material such as notes, illustrations, diagrams or specifications. The examination of related material is often disrupting for the reader as they must explicitly navigate to related information and then navigate back to their prior reading location. Hypertext systems introduce more direct ways of navigating between primary and related content, sections of primary material can be hyperlinked to related information and mouse clicks used to accomplish automatic transitions to the related content. Transition or navigation in this manner can also be disruptive as the reader is removed from the context of the primary material being examined.
Fluid document technology [1] tackles the issues of connecting primary and related information by enabling the presentation of related or supplemental material in the context of primary material. Discrete visual cues embedded in primary material indicate that related material is available and user interaction is used to show and hide the related material in context (See Fig. 1). When related material is presented it is accommodated by the topographical shift of primary material. Presenting related material in this manner reduces the need for explicit navigation to related material, maintains the context of the primary information when examining related information and supports the task of synthesizing disjoint yet related information. Fluid source code views are the application of the principles of fluid document technology to source code documents. The definition of a complex software system by means of text based source code documents manifests a highly fragmented, heavily linked, hyperlink-able information space. The application of software development paradigms and principles such as abstraction, object orientation, aspect orientation [2] and separation of concerns means that the definition of software may be highly fragmented. The code implementing a program operation of feature can, potentially, be fragmented over dozens of separate source code documents with often implicit and semiimplicit relationships. This phenomenon has also been described loosely as scatter [3] and delocalized plans [4]. Modern Integrated development environments (IDEs), such as Eclipse [5], help programmers find, examine, edit and navigate between points of interest in code. IDEs represent source code in terms of static text documents. Navigation occurs by "jumping" from related position in document to document using a hyperlinked information space (for instance from a method invocation point to the related method definition). At each navigation “jump” the primary
Proceedings of the 14th IEEE International Conference on Program Comprehension (ICPC’06) 0-7695-2601-2/06 $20.00 © 2006
IEEE
Chris Exton University of Limerick, Limerick, Ireland
[email protected]
material being examined is replaced with the related information.
These visual cues are completely unobtrusive to the regular functioning of the source code editor. When the mouse pointer is hovered over the cue it becomes an interactive annotation (See Fig. 3).
Figure 2. Visual cues embedded in source code
Figure 3. Interactive annotation embedded in source code Figure 1. Basic tenants of Fluid document technology As a result of this navigational model provided by IDEs, programmers are forced to navigate through complex arrangements of software definition, viewing each in isolation, and synthesize information scattered across multiple points in multiple documents when comprehending code. It also means that programmers lose context during the constant navigation that they must carry out. In this paper we present fluid source code views. A fluid source code view is an enhancement of the traditional source code editor with support for fluidly exploring the software space related to the primary source file being edited. A fluid source code view embeds unobtrusive, interactive visual cues and annotations at semantically relevant points within the source code presentation. The programmer can then interact with these points to expose related information fluidly in the context of the document being examined. We speculate that fluid source code views will reduce navigation and loss of context during code analysis and comprehension. We also believe that fluid source code views will improve general software comprehension by supporting common software comprehension tasks and patterns and providing a more natural view of the relationships between software elements.
2. Fluid source code views As part of our experimentation with fluid document technology in the Eclipse IDE we have developed a fluid document editor which allows the embedding of visual cues at semantically important points within the presentation of source code (see Fig. 2).
The annotation can then be interacted with to reveal either text or widget based content in context (See Fig. 4).
Figure 4. “Expansion” of related content We will now describe the current and planned features of our fluid source code views prototype in the Eclipse IDE.
2.1. Expansion of method invocation chains The first application of fluid source code views is the comprehension of control and data flow between method invocation chains. We use the term method chain to describe a root method calling a number of sub methods, which in turn call a number of sub methods and so on, in essence a rooted call hierarchy. In a traditional source code editor a programmer undertaking the simple task of examining the control and data flow between a number of methods must examine each method in isolation, regularly jumping back to previous methods to follow alternative control paths or to clarity information from the calling context. When a source code document is opened in a fluid source code view, each method invocation contained in the document is annotated with an unobtrusive visual cue (see Fig. 2).
Proceedings of the 14th IEEE International Conference on Program Comprehension (ICPC’06) 0-7695-2601-2/06 $20.00 © 2006
IEEE
When the programmer moves the mouse to within the bounding region specified by the visual cue an expandable annotation appears, the owning method invocation is also underlined with a visual cue (see Fig. 3). The underlining of the method invocation is useful to distinguish the “owner” of an expandable annotation in the case of method invocation nesting, where annotations can be grouped quite close to each other. Each visual cue and underlying annotation occupies a single character in the source code document and is completely unobtrusive to the normal functioning and editing features supported by the code editor. Using the caret the programmer can edit around and directly upon the visual cue, the fluid document editor takes care of repositioning the visual cues in response to document edits and the addition and removal of cues that are no longer valid expansion points. When a method invocation annotation is clicked it will expand: expansion of the method invocation annotation reveals a simulated textual representation of the target method definition in a semantically accurate context within the current source code document under examination (see Fig. 5). The related information, in this case the method definition, is colored to indicate that it is supplemental to the primary document. The expanded method definition also contains any leading comments connected with the method definition. We intend to make these comments collapsible in a future version. We also intend to make the presentation of the method signature and surrounding braces an optional feature of the expanded code. To navigate to the document within which the method definition is contained the programmer may hold the control key and click within the exposed region. Any valid method invocations within the newly expanded method definition are also available to be expanded and thus the programmer can further selectively expand deeper into the nested call hierarchy, keeping a constant visual representation of the flow of control and data through the various methods. We speculate that this feature of fluid source code documents reduces the need for navigation between multiple documents and supports comprehension of the control flow related to a particular root method definition. A programmer using this feature need not synthesize information from method call to method call as this information is visually displayed in the fluid source code view. When the programmer is finished examining the expanded code it can be collapsed by clicking its annotation again (which becomes a “collapsible” annotation). Note that exposed code is not editable however as our prototype becomes more advanced we may experiment
with this feature. We also plan to experiment with the ability to collapse sections of the expanded call tree while keeping sub trees open, to help the programmer manage clutter and focus attention.
Figure 5. Expansion of a method invocation
2.2. Inheritance Relationships The next feature of fluid source code views that we examine is support for working with inheritance relationships at the source code level. To comprehend the definition of a subclass method that overrides a super class method it is sometimes necessary to comprehend the super class implementation and so on up the hierarchy. This occurs due to the close coupling between super and subclass. However, due to the modular structure of code, the programmer is forced to navigate up the class hierarchy examining each level of implementation in isolation. When a sub class is opened in a fluid source code view any super method calls are treated as expandable and thus the programmer can reveal the effect of the various levels of super class implementations on the current subclass context. This reduces the need for bothersome navigation up through the inheritance hierarchy and allows the programmer to view from the context of the subclass method the effect of super class coupling on control and data flow (see Fig. 6). Any further expandable points within an exposed super class range are available for nested expansion. Sometimes super class methods are overloaded without the calling of the super class method itself within the subclass implementation. There is usually a good reason for this particular situation. When viewing source code using a fluid source code view, the programmer can choose to view the super class implementation of a method even when it is not explicitly called. This enables the programmer to examine and compare the overridden method in context with its replacement and thus shed light on the programming decision which resulted in the organization of code in this manner.
Proceedings of the 14th IEEE International Conference on Program Comprehension (ICPC’06) 0-7695-2601-2/06 $20.00 © 2006
IEEE
indicator is expanded, the viewer displays an ordered selection of advice elements. The programmer can then select particular advice elements for expansion thus revealing the extra control flow that is executed at the join point (see Fig. 8).
Figure 6. Examination of Inheritance relationships using fluid source code views
2.3. Polymorphic dispatch sites Fluid source code views analyze the static type structure of the software being examined and provide a set of potential matches at polymorphic dispatch sites. When a polymorphic dispatch site is encountered, it is annotated with a special annotation similar to the annotation used to annotate monomorphic dispatch sites. However when a polymorphic dispatch site is "expanded" a selection of concrete implementations is revealed and the programmer can then decide which concrete implementation they would like to view in context (see Fig. 7).
Figure 8. Fluid presentation of aspect advice Because the application of advice to a static join point can be guarded by a dynamic check, we are working on presenting advice at join points in a way that indicates firstly that dynamic checks may affect the application of advice to a join point and secondly what dynamic checks are considered when determining the application of advice. Prior Experiments applying fluid document technology to AOP are discussed here [6].
3. References [1] Chang, B.W., Mackinlay, J.D., Zellweger, P.T. and Igarashi,T.: A Negotiation Architecture for Fluid Documents. In: Proceedings of the ACM Symposium on User Interface Software and Technology, pp. 123-132 (1998).
Figure 7. Fluid view of polymorphic dispatch site The presentation of polymorphic call sites in this manner means that programmers need not leave the comprehension task at hand to examine the type hierarchy but can instead view the information they require without interruption. This view also allows the visual comparison of concrete implementations within a single editor view.
2.4. Aspect oriented programming The latest feature of Fluid source code views under development is support for the comprehension of the implicit relationship and navigation between classes and advising aspects. When an advised class is opened using a fluid source code view, it is analyzed for crosscutting structure and the static join points contained within the class that are targeted by advice are marked with an expandable indicator. When the
[2] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. V.Lopes, J-M Loingtier, and J. Irwin. Aspect-Oriented Programming. In Proceedings of the 11th European Conference on Object-Oriented Programming (ECOOP), pages 220 – 242, Jyväskylä, Finland, 1997. [3] Mark Chu-Carroll, James Wright, Annie T. T. Ying: Visual separation of concerns through multidimensional program storage. Proceedings of Aspect-Oriented Software Development, 2003: 188-197. [4] Soloway E., and Ehrlich K. 1984. Empirical studies of programming knowledge. IEEE Transactions on Software Engineering, SE-10(5), pp. 595-609. [5] The Eclipse project, http://eclipse.org [6] Kersten, M., Chapman, M., Clement, A., Colyer, A.: Lessons learned building tool support for AspectJ. Proceedings of Aspect-Oriented Software Development, 2006.
Proceedings of the 14th IEEE International Conference on Program Comprehension (ICPC’06) 0-7695-2601-2/06 $20.00 © 2006
IEEE
