License.

License This document is licensed under the terms of the Creative Commons Attribution-Noncommercial 3.0 Germany license. You are allowed to to Share to copy, distribute, and transmit the document to Remix to adapt the document You are ought to respect the following conditions Attribution Noncommercial use http://creativecommons.org/licenses/by-nc/3.0/de/deed.en Markus Knauß, December 12. 2008

Eclipse as a Tool for Program Understanding Markus Knauß Institute of Software Technology, Software Engineering Research Group Universität Stuttgart, Universitätsstraße 38, 70569 Stuttgart knauss@informatik.uni-stuttgart.de Abstract When developing Java programs, existing source code has to be understood again and again. This is necessary because a developer forgets about his own code, or the code was developed by a colleague, or a third party library is used. Therefore, the development environment (IDE) in daily use should support the process of program understanding. As Eclipse is probably the IDE most frequently used for Java program development, we posed the question whether, and to which degree, Eclipse supports the understanding of Java programs. In this paper, we describe questions that developers ask in order to understand a program. Eclipse was analyzed whether and to which degree it supports the generation of answers to these questions. Our contributions are an overview on studies about questions developers ask, a taxonomy to classify these questions, a list of questions asked to understand static relationships in a program, and an analysis of the abilities and possibilities of Eclipse to support program understanding. 1. Introduction During the development of a Java program, existing source code has to be understood. This is necessary because a developer forgets about his own code, works on unfamiliar code developed by colleagues, or uses a third-party library whose implementation is unknown. But not only during the development of Java programs, but also during maintenance source code has to be understood. When maintaining programs the body of unknown code is even larger. According to Corbi, about 50% of the time spent for maintaining software is spent for program understanding [Cor89]. We presume that the same ratio applies for program development; this seems to be valid especially in Agile Processes, where program understanding is a must for code reviews, collective code ownership, and refactoring. The integrated comprehension model of Mayrhauser and Vans [MV93a, MV95b] describes how a program is understood. When a developer has unfamiliar source code, studies show that the developer first builds a mental control flow abstraction of the source code. This abstraction is called a program model. The process to build this model is a systematic bottom-up one. When building this model a developer formulates hypotheses about the program. He tries to verify the hypotheses by asking questions about the code. A model that describes how questions are generated and answered using tools was developed by Sillito et al. [SMV06]. According to Sillito's model a developer first formulates a question. If the question can not be answered using a tool he divides it into sub-questions. All these questions are translated into tool questions. That questions can be answered by using a tool to deduce required information. The result sets returned from the tools must be analyzed to answer the original question. To efficiently support program understanding, the IDE in daily use should support the answer generation for these questions. Today, Eclipse is presumed to be the dominant IDE for Java program development [Gee05] and it is the major IDE used in research pro - jects 1. Therefore, we evaluated Eclipse whether, and to which degree, it supports program understanding by answering the questions a developer asks. In the next section we list questions asked by a developer in order to understand a program. Before listing the questions we describe the research method we used to deduce the questions and present a taxonomy, that we used to classify the questions. After listing the questions, we show how Eclipse supports answer generation to the questions. In the following section we discuss our results and theorize about how Eclipse 1 Searching for the terms software and eclipse or netbeans respectively yields 163 (IEEE) and 160 (ACM) results for eclipse and 7 (IEEE) and 3 (ACM) results for netbeans. The search was performed at 10/21/2008.

could support program understanding. In the end we present related work, conclude our article and give an outline of future work. 2. Questions Developers Ask To deduce the questions a developer asks in order to understand a program a meta study was carried out. It led to 59 questions that were classified and filtered using a taxonomy. This taxonomy was created to categorize the information sources a developer uses during program understanding to answer his questions about the program. As a result 23 questions were identified that a developer asks about static code attributes. The subsequent sections describe the steps in detail. 2.1. Research Method To deduce the questions a developer asks in order to understand a program, we did a meta study on articles about studies which analyzed the information requirements of a programmer during program understanding. The articles were found by analyzing the proceedings of the International Workshop on Program Comprehension (ICPC). At least three groups of authors remained that report on the topic. These authors are Mayrhauser and Vans [MV93a, MV93b, MV95a, MV97], Ko et al. [KAM05, Ko+06, KDV07], and Sillito et al. [SMV06]. The studies the authors reported on, the tasks to be done in the study, and the participants are listed in table 1. The authors analyzed a developer's information needs for program understanding by monitoring him at work. This was done by audio-taping a thinking-aloud session, taking handwritten notes, capturing or video- Table 1: Overview of studies on the information requirements of a developer during program understanding Task Participants Type of study Reference Understanding of a self selected piece of code in a 40-KLOC C program Self selected maintenance task on an at least 40-KLOC program. One session with a debugging task, another with a testing task Individual maintenance tasks on a 40-KLOC C program Understand, track down, and correct a reported bug in a 40- KLOC program Five maintenance tasks on a Java program (503 LOC, nine classes) within a 70-minute session Study 1: Correcting bugs or enhancing ArgoUML in a 45- minute session Study 2: Doing a change task on the participants own software in 30-minute session Monitoring of the daily work, eleven participants corrected bugs One maintenance engineer Audio-taped thinking aloud [MV93a] Professional maintenance programmers (the article reports on observations of two programmers) Nine professional maintenance programmers Four professional maintenance programmers Ten Java programmers that claimed that their skills are at least above average Study 1: Nine students doing pair programming in a laboratory setting Study 2: 16 programmers in an industrial setting Audio-taped thinking aloud Audio-taped thinking aloud Audio- and video-taped thinking aloud, subsequent record analysis Survey on programming expertise, screen capturing Study 1: Audio recording, screen capturing of IDE, interview after session Study 2: Thinking aloud, interview after session 17 developers Recording the work done using handwritten notes, crosscheck of the results with a survey among 42 other developers [MV93b] [MV95a] [MV97] [KAM05], [Ko+06] [SMV06] [KDV07]

Information Sources Domain-specifi c Task-specifi c Program-specifi c Code Development Documentation Static Dynamic Figure 1: Taxonomy for information sources a developer relies on taping the programmer's screen, or by automatically recording the actions a programmer carried out. The monitoring usually resulted in large data sets describing the work the programmer did. From these data sets typical actions were derived and information needs for taking an action were identified. Using the information needs identified in the analyzed articles we deduced questions that a developer will ask to satisfy his information needs. Some authors already formulated developer questions that we could use. Duplicates in the deduced questions were eliminated. This resulted in a set of 59 questions. 2.2. A Taxonomy for the Information Needs of a Developer To organize and filter the questions we first classified them. Then we developed a taxonomy for the information sources a developer uses to answer questions in order to understand a program. 2.2.1. Classification. Classification was done along two dimensions. The first dimension is the abstraction level to which a question refers; this is either architecture, module, or statement. The second dimension is the type of the question as defined by Erdem et al. [EJM98]. A question is either used for verification (is), for identification (what), to get procedural knowledge (how), to gain knowledge about the motivation for an implementation (why), to get information about runtime characteristics (when), or to locate an item (where). Questions of type is, what, how, and where can be answered using the source code as the only information source. But for answering questions of types why and when additional information sources are needed. For instance, to answer a type when question traces of program executions are needed; to answer a type why question the design rationale is required. 2.2.2. Taxonomy. To gain further understanding of the information sources on which a developer relies, in order to understand a program, we developed a taxonomy for these information sources. The taxonomy is shown in figure 1. Categories that are of no interest for our analysis of Eclipse's support of program understanding were not pursued any further. Atomic categories in figure 1 are described below. Domain-specific: Any information that describes the domain in which the program is used. Task-specific: Any information about the task for which the program is used. Development: Information about the development process of the program. For instance, log entries from the configuration management. Documentation: Any additional documentation that is not part of the source code. For instance, the design documentation. Dynamic (Code): Information about the execution of the program such as execution traces. Static (Code): Any information that is available using only the source code. To analyze Eclipse's support of program understanding we evaluated only questions that can be answered using information from the static category. This is because, first we presume that a Java developer will use the Java perspective for reading the source code that does not show dynamic or development information and, second, additional documentation, such as specification or design documents, is out of scope of a standard Eclipse installation. 2.3. Questions Asked Filtering our questions by applying the taxonomy yielded 23 questions that a developer may ask about static source-code attributes to understand a program. The questions, a short description, their abstraction level, and their type are listed in table 2. As the analyzed articles were based on developers working on source code in different programming languages, we paraphrased the questions to use object-oriented Javaspecific terms.

Table 2: Questions about static code attributes for program understanding Question Abstraction Level Type What members are accessed by this method? Module What What methods are declared in this type? Module What What members are defined in this type? Module What What are the siblings of this type? Module What What types implement or extend this interface? Module What What members of this type are accessible? Module What What types are used (imported) by this type? Module What What are the commonalities between these types? Module What How are the files organized? Module How How do these types use each other? Module How Where is this type located in the type hierarchy? Module Where Where is this type defined? Module Where Where is this member declared? Module Where Where is this method defined? Module Where What objects, fields, or variables are modified by this statement? Statement What / What is the static type of the object that is returned by this method? Statement What What is statically related to this statement? Statement What What is the condition for this branch to be executed? Statement What / What is the condition for this exception to be thrown? Statement What / Where is a member used? Statement What Where in the code is a certain kind of text? Statement Where Where is this type referenced? Statement Where Where are instances of this type accessed? Statement Where Eclipse's support 3. Eclipse's Support for Program Understanding To analyze how Eclipse supports program understanding we evaluated how the deduced questions can be answered using tools built into the standard Eclipse distribution. Eclipse in Version 3.4.1 (Ganymede, SR 1) for Java developers [Eclipse] without any additional plug-ins except the metrics plug-in [Metrics] was used for the evaluation. We presume that a Java developer will use the Java perspective by default. Based on the process for answering questions as described by Sillito et al. [SMV06] we quantified the degree of Eclipse's support for program understanding. The quantification was done by the number of steps to be made in order to answer a question. At best nothing has to be done because the information to answer the question is displayed in the Java perspective. In the worst case three steps have to be made. These steps are: 1) divide the question into sub-questions that can be answered using a tool provided by Eclipse, 2) use each tool and retrieve the needed information, and 3) integrate the results to answer the original question. The degrees of Eclipse's support we defined are listed below in ascending order. No support: The question at hand cannot be answered using the standard Eclipse distribution. Multiple tools needed: There is no single tool in Eclipse that can be used to answer the question at

hand. But by using multiple tools and integrating the results an answer can be derived. Result set has to be filtered: Eclipse provides a single tool that will answer the question at hand. But the result set returned by the tool must be filtered to get the correct answer. For instance, using the search tool will yield more results than needed. Tool available: A tool is provided with the Eclipse standard distribution that can be used to answer the question. No tool needed: The information needed to answer the question is displayed in the Java perspective. To quantify Eclipse's support for program understanding we tried to answer the questions on the birthday calendar application. The birthday calendar application is a little Java desktop application with a graphical user interface that is implemented using Swing components. We primarily use this application in the classroom to teach how to design a three-tier application and how to apply design patterns. The application consists of 23 classes, 1 interface, and a total of 1317 lines of code. How Eclipse supports program understanding by answering the deduced questions is shown in table 2. The mapping from the degree of support to the icon in the Eclipse's support column is: No support Multiple tools needed Result set has to be filtered Tool available No tool needed 4. Discussion In the subsequent sections we will discuss how Eclipse supports program understanding and how it should do. First we describe our results that are also documented in table 2. Then we theorize about how Eclipse should support program understanding. 4.1. How Eclipse Supports Program Understanding First of all, Eclipse does support program understanding. It does so by providing tools that deliver the required information to answer our deduced questions to a large extent. A typical Eclipse Java development perspective is shown in figure 2. In the subsequent dis- 4 5 2 6 1 3 6 Figure 2: A typical Eclipse Java development perspective

cussion of the tools used, we reference Eclipse's tools displayed in figure 2 by the numbers added in the figure. References to these numbers are written in parentheses like (1). Questions which can be answered on the basis of the source code are obviously supported and do not require a tool. Examples are what objects, fields, or variables are modified by this statement or what is statically related to this statement. Two special cases are the questions what is the condition for this branch to be executed and what is the condition for this exception to be thrown. Answers to these questions can be given either by looking at the code, and therefore no tool is needed, or by browsing and searching for the condition. Eclipse provides no tool for finding a specific condition. Therefore, whether the information is handy to answer these questions depends on the distance between the condition and the line in the source code the developer currently reads. Frequently used Eclipse tools to answer the questions are the hierarchy view (1), the outline view (2), the call hierarchy view (3), the open declaration tool (4), and the package explorer (5). These tools can be used to answer questions such as what are the siblings of this type, what members of this type are accessible, where is a member used, or where is this member declared. A tool that usually returns more information than is needed is the search tool (6). For instance, when the question where in the code is a certain kind of text has to be answered, the search tool will deliver the re - quested information. But to decide which of the locations in the source code, where the text was found, is the correct one requires an analysis of the result set. The questions how do these types use each other and what is the type of the object that is returned by this method can only be answered by using multiple tools. For instance, when one is trying to answer the question for the type of a returned object he has to read through the source code, use the open declaration tool (4) at any return statement to reveal the declaration of the object, and there use the open declaration tool (4) again to open the object type. If the run-time type is a subtype of the declared type, the inheritance hierarchy tool (1) must also be used. Not supported by a tool are the questions what members are accessed by this method and what are the commonalities between these types. These questions can only be answered by reading the code and manually collecting the required information. 4.2. How Eclipse Should Support Program Understanding As shown in the preceding section, Eclipse does support program understanding by providing tools that supply information to answer questions about the source-code's static attributes. The deficiency of the provided tools in Eclipse is, in our opinion, that they are apart from the source code in separate views. If a developer uses a tool to gain this information, he has to leave the source code, get the information from the tools view, and then return to the code. This often leads to context-loss, and the developer has to delve into the source code over and over again. The good is that, in the majority of cases, the views are interlinked. This helps the developer to quickly regain the context he was working in. Static information about the source code is intangible. Therefore, a model of the information is needed to capture the information. This model has to be visualized in order to use the information. This visualization has to meet three requirements at least. 1. The model that is the basis for the visualization must provide information to answer the questions a developer asks in order to understand a program. 2. The visualization must employ techniques from the information visualization domain. This is necessary to visualize the information in an efficient way and to maintain the context the developer currently works in. 3. The way of using the visualization must support the process of program understanding. Especially the process for bottom-up program understanding. Currently we are exploring ways to meet these requirements in order to better support program understanding. 5. Related Work The body of knowledge in the program understanding domain is quite large. Also in the domain concentrating on tools to support program understanding. But no articles were found that analyzed the suitability of Eclipse for program understanding tasks. For the reader who wants to delve into the topic of program understanding, methods of program understanding, and tool support for program understanding, Storey's article is a good starting point [Sto05]. Related work that analyzed the information needs of a developer during program understanding was introduced in section 2. One article that was not incorporated in the meta study but that also lists information needs of a developer during program understanding, is

the article of Erdös and Sneed [ES98].They identified the developer's information needs based on their industrial experience. As result they defined seven questions that a developer has to answer to understand a program. Because these questions were redundant with the questions deduced from the work described in section 2 and that we analyzed only work was analyzed in the meta study that is based on monitoring developers Erdös and Sneed's article was not included. 6. Conclusion and Future Work In this article we presented an overview of studies that analyzed the information needs of a developer in order to understand a program. We developed a classification for questions about a program along two dimensions, the abstraction level and the type according to [EJM98]. Also, a taxonomy was developed for the information a developer relies on during program understanding. This taxonomy was used to identify questions that can be answered using only static sourcecode information. At the end 23 questions were identified that a developer asks in order to understand a program. Furthermore Eclipse was analyzed for the support it provides towards answering the identified questions. Our work presented here is a starting point for the development of tools that support program understanding. In our view the results are the requirements analysis for program-understanding tools, and especially those tools that extend Eclipse's support of the bottomup understanding process. Also, we see potential in further investigation and extension of our taxonomy for the information sources used during program understanding. Currently we are working on an information interchange model to capture the information required to answer the identified questions for program understanding. Based on this model a visualization is developed that will utilize information visualization techniques that exceed the views and editors of Eclipse and that, as a matter of course, will provide necessary information to answer the questions presented here. References [Cor89] T. A. Corbi, Program Understanding: Challenge for the 1990s, IBM Systems Journal, 28(2), 1989, pp. 294-396. [Eclipse] The Eclipse Platform, Version 3.4.1, http://www.eclipse.org (Oct. 14. 2008). [EJM98] A. Erdem, W. L. Johnson, and S. Marsella, Task- Oriented Software Understanding, In Proceedings of the 13 th International Conference on Automated Software Engineering, 1998, pp. 230-239. [ES98] K. Erdös and H. M. Sneed, Partial Comprehension of Complex Programs (Enough to Perform Maintenance), In Proceedings of the 6 th International Workshop on Program Comprehension, 1998, pp. 98-105. [Gee05] D. Geer, Eclipse Becomes the Dominant Java IDE, IEEE Computer, 38(7), 2005, pp. 16-18. [KAM05] A. J. Ko, H. H. Aung, and B. A. Myers, Eliciting Design Requirements for Maintenance-oriented IDEs: A Detailed Study of Corrective and Perfective Maintenance Tasks, In Proceedings of the 27 th International Conference on Software Engineering, 2005, pp. 126-135. [Ko+06] A. J. Ko, B. A. Myers, M. J. Coblenz, and H. H. Aung, An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks, IEEE Transactions on Software Engineering, 32(12), 2006, pp. 971-987. [KDV07] A. J. Ko, R. DeLine, and G. Venolia, Information Needs in Collocated Software Development Teams, In Proceedings of the 29 th International Conference on Software Engineering, 2007, pp. 344-353. [Metrics] Eclipse Metrics Plugin, Version 1.3.6, http://metrics.sourceforge.net (Oct. 14. 2008). [MV93a] A. von Mayrhauser and A. M. Vans, From Code Comprehension Models to Tool Capabilities, In Proceedings of the 5 th International Conference on Computing and Information, 1993, pp. 469-473. [MV93b] A. von Mayrhauser and A. M. Vans, From Program Comprehension to Tool Requirements for an Industrial Environment In Proceedings of the 2 nd Workshop on Program Comprehension, 1993, pp. 78-86. [MV95a] A. von Mayrhauser and A. M. Vans, Industrial Experience with an Integrated Code Comprehension Model, IEE Software Engineering Journal, 10(5), 1995, pp. 171-182. [MV95b] A. von Mayrhauser and A. M. Vans, Program Comprehension during Software Maintenance and Evolution, IEEE Computer, 28(8), 1995, pp. 44-55. [MV97] A. von Mayrhauser and A. M. Vans, Program Understanding Needs during Corrective Maintenance of Large Scale Software, In Proceedings of the 21 st International Computer Software and Applications Conference, 1997, pp. 630-637. [SMV06] J. Sillito, G. C. Murphy, and K. De Volder, Questions Programmers Ask during Software Evolution Tasks, In Proceedings of the ACM SIGSOFT Conference on the Foundations of Software Engineering, 2006, pp. 23-33. [Sto05] M.-A. Storey, Theories, Models and Tools in Program Comprehension: Past, Present and Future, In Proceedings of the 13 th International Workshop on Program Comprehension, 2005, pp. 181-191.