Visual support for incremental abstraction and refinement in Ada 95

ion, that is, the process of successively building up mental representations of various levels of abstractions of source code text structures and their relationships. These mental representations are often called chunks have been shown in the literature to play significant roles in human comprehension of software [3,7,10,11,15,16,18,21]. The study of fundamental cognitive processes has revealed well-defined limits on the capacity of the human mind during comprehension tasks. Miller [16] described the classic 7 ±2 limit on short-term memory and others have demonstrated that this capacity diminishes as task complexity increases [15]. Thus, grouping portions of source code together into chunks allows the chunk of code to be understood abstractly as a unit rather than through the complete details of its components. This concept of chunking builds upon itself in that lower-level chunks are combined to form higher-level chunks, thus providing a method of comprehending a program in terms of various levels of abstraction in a systematic way, while addressing the inherent limits on the capacity of the human mind. Before chunks can be used as part of a comprehension strategy, they must be identified. The process of scanning through the source code, in either a forward or backward direction, to identify appropriate chunks is known as tracing [7]. Although chunks may not be delineated by particular syntax boundaries in the source code, they are often delineated by control structures and program modules. The CSD directly supports the tracing process by providing clear and intuitive visual cues to both control structure boundaries and program module boundaries. This visual support can be especially significant when tracing large regions of code where single control structures might span hundreds of lines of code. The identification and comprehension of chunks involves both semantic and syntactic knowledge [21]. Semantic knowledge is relatively independent of any particular language and involves understanding basic concepts such as looping structures and fundamental algorithms, and recognizing design patterns in code. Syntactic knowledge is language specific and allows semantic structures to be recognized in a particular language [7]. A clear relationship exists between the syntactic form of source code and the ability of human readers to construct useful mental abstractions from that source code [13]. Source code that is well structured and visually appealing facilitates the tracing and chunking process. The intuitive visualization of the CSD, displayed as a companion to well-indented, pretty-printed source code thus provides direct support for chunking and tracing during program comprehension. The visual presentation of a chunk can have a significant impact on its understandability [14]. Chunks that are visually distinct from the rest of the program are much easier to comprehend. GRASP provides direct support of this concept by allowing the CSD to be viewed in user-selectable granularities. A user can select portions of code according to control structure boundaries, program module boundaries, or arbitrary boundaries, and then fold them into the single CSD symbol shown in Figure 3. Figure 3. CSD folding symbol Thus, a user of GRASP can fold the CSD into levels of abstractions, or chunks, as the source code is being read and understood. The folded portions of source code can then be labeled with a comment or with the source language construct that begins the chunk (e.g., a procedure heading). Figure 4 illustrates folded C SDs for a procedure body, a block, an if-then, and a while loop. The folded portions of the construct can be arbitrarily large and contain regions of code that are themselves folded. Thus, folding in GRASP is implemented as a natural form of ou tlining in which the code is folded and unfolded based on the control structures in the CSD. What makes this approach so effective is the visual clarification of the chunks resulting from the folded CSD. That is, the folds are visually labeled by CSD symbols, much as chunks are abstractly labeled according to functionality. Figure 4. Folded CSDs As an example of the use of folding, Figures 5 through 8 show the presentation of Ada 95 source code in increasing levels of detail, as the code might be presented in a classroom setting. The source code is taken from the text by Michael Feldman [12] used in the CS 2 (data structures) course at Auburn University. Folding offers a pedagogically sound technique for teaching algorithms presented in source code. GRASP provides students with a robust and efficient tool to facilitate reading code and learning algorithms through natural chunking processes. Figure 5 shows a GRASP CSD window displaying the source code for inserting a new element into a threaded binary search tree. The source code has been completely folded except for the procedure heading. This hides all the detail of the algorithm by abstracting away everything except the public interface to the implementation. Figure 6 unfolds the CSD to the next level of detail where the module summary comments are shown but where both the eclarations and the executable statement section are folded. Figure 7 shows the unfolded declaration section, revealing a nested subprogram. Figure 8 shows the declaration section again folded, but the statement section expanded to reveal two subchunks, each identified by the CSD folding symbol and a leading comment. Figure 5. Source code folded to module heading

[1]  Harlan D. Mills,et al.  Stepwise refinement and verification in box-structured systems , 1988, Computer.

[2]  Darrell R. Raymond,et al.  Characterizing visual languages , 1991, Proceedings 1991 IEEE Workshop on Visual Languages.

[3]  Anneliese Amschler Andrews,et al.  Identification of Dynamic Comprehension Processes During Large Scale Maintenance , 1996, IEEE Trans. Software Eng..

[4]  Michael B. Feldman Software Construction and Data Structures with Ada 95 , 1996 .

[5]  W. Kintsch,et al.  Memory and cognition , 1977 .

[6]  Lorraine Borman Directions in human/computer interaction , 1983, SGCH.

[7]  Vairam Arunachalam,et al.  Cognitive processes in program comprehension: An empirical analysis in the Context of software reengineering , 1996, J. Syst. Softw..

[8]  Kate Ehrlich,et al.  An empirical investigation of the tacit plan knowledge in programming , 1984 .

[9]  Marian Petre,et al.  Why looking isn't always seeing: readership skills and graphical programming , 1995, CACM.

[10]  R BasiliVictor,et al.  Comparing the Effectiveness of Software Testing Strategies , 1987 .

[11]  Brian Henderson-Sellers,et al.  A conceptual model of cognitive complexity of elements of the programming process , 1995, Inf. Softw. Technol..

[12]  Mark Gluck,et al.  Memory and cognition , 2000, Clinical Neurophysiology.

[13]  Victor R. Basili,et al.  Comparing the Effectiveness of Software Testing Strategies , 1987, IEEE Transactions on Software Engineering.

[14]  PetreMarian Why looking isn't always seeing , 1995 .

[15]  John S. Davis,et al.  Chunks: A basis for complexity measurement , 1984, Inf. Process. Manag..

[16]  N. Pennington Stimulus structures and mental representations in expert comprehension of computer programs , 1987, Cognitive Psychology.

[17]  Aaron Marcus,et al.  Software visualization for debugging , 1997, CACM.

[18]  Darrel C. Ince,et al.  Transformational data refinement and VDM , 1995, Inf. Softw. Technol..

[19]  John Barnes,et al.  Programming in ADA , 1989 .