Visualization Techniques for Effective Software Comprehend

Program comprehension is an important activity in software maintenance, as software must be sufficiently understood before it can be properly modified. The study of a program's execution, known as dynamic analysis, has become a common technique in this respect and has received substantial attention from the research community, particularly over the last decade. These efforts have resulted in a large research body of which currently there exists no comprehensive overview. This paper reports on a systematic literature survey aimed at the identification and structuring of research on program comprehension through dynamic analysis. From a research body consisting of 4,795 articles published in 14 relevant venues between July 1999 and June 2008 and the references therein, we have systematically selected 176 articles and characterized them in terms of four main facets: activity, target, method, and evaluation. The resulting overview offers insight in what constitutes the main contributions of the field, supports the task of identifying gaps and opportunities, and has motivated our discussion of several important research directions that merit additional consideration in the near future.

Software industry is gaining momentum due to profound impact on the productivity of the various tasks. Typically software development life cycle includes, development activity and post release activities. The post release activities cover software maintenance and support. It is inevitable to deny the significance of software maintenance and support activities due to fairly a large size of the software. In this study we are analyzing the relationship of team size, application size and software maintenance and support activities. We used the latest dataset of International Standard Benchmark Group data repository containing the software maintenance and support information to conduct this empirical investigation. The results of this empirical investigation further reinforce the current perceptions of the significantly important role of application size, team structure and size on the software maintenance and support activities.

Program Slicing is a popular technique that assists in various software maintenance activities like debugging, program comprehension and regression testing. It is a decomposition technique used for the extraction of program statements affecting the values computed at some point of interest. We propose a technique for computing slices of XML documents. Given a valid XML document, we produce a new XML document (a slice) containing the relevant information in the original XML document according to some criterion. We output a new DTD such that the computed slice is valid with respect to this DTD. Our technique first slices the associated DTD and the DTD slice is used as a slicing criterion in order to produce the associated XML slice.KeywordsTag dependence graph (TDG)Extensible Markup Language(XML)Document Type Definition (DTD)

Program comprehension is a fundamental prerequisite before software engineers may engage in software maintenance or evolution activities and requires the study of large amounts of documentation - either developer documentation or reverse engineered. Very often, from this documentation is missing a short overview document pointing to the most important classes of the system, these who are essential for starting the understanding of the systems architecture. In this work we propose a recommender tool to automatically identify the most important classes of a system. Our approach relies on modeling the static dependencies structure of the system as a graph and applying a graph ranking algorithm. We empirically identify the optimal way of building the system graph, identifying how different dependency types should be taken into account. In experiments performed on a set of open source real life systems, we compare the sets of classes recommended by our tool with these included in the architectural overviews provided by the system developers.

During software development and maintenance, developers spend a considerable amount of time on program comprehension activities. Previous studies show that program comprehension takes up as much as half of a developer’s time. However, most of these studies are performed in a controlled setting, or with a small number of participants, and investigate the program comprehension activities only within the IDEs. However, developers’ program comprehension activities go well beyond their IDE interactions. In this paper, we extend our ActivitySpace framework to collect and analyze Human-Computer Interaction (HCI) data across many applications (not just the IDEs). We follow Minelli et al.’s approach to assign developers’ activities into four categories: navigation, editing, comprehension, and other. We then measure the comprehension time by calculating the time that developers spend on program comprehension, e.g., inspecting console and breakpoints in IDE, or reading and understanding tutorials in web browsers. Using this approach, we can perform a more realistic investigation of program comprehension activities, through a field study of program comprehension in practice across a total of seven real projects, on 78 professional developers, and amounting to 3,148 working hours. Our study leverages interaction data that is collected across many applications by the developers. Our study finds that on average developers spend $\sim$ 58 percent of their time on program comprehension activities, and that they frequently use web browsers and document editors to perform program comprehension activities. We also investigate the impact of programming language, developers’ experience, and project phase on the time that is spent on program comprehension, and we find senior developers spend significantly less percentages of time on program comprehension than junior developers. Our study also highlights the importance of several research directions needed to reduce program comprehension time, e.g., building automatic detection and improvement of low quality code and documentation, construction of software-engineering-specific search engines, designing better IDEs that help developers navigate code and browse information more efficiently, etc.

Reading and understanding source code is a major task in software development. Code comprehension depends on the quality of code, which is impacted by code structure and identifier naming. In this paper we empirically investigated whether longer but more descriptive identifier names improve code comprehension compared to short names, as they represent useful information in more detail. In a web-based study 88 Java developers were asked to locate a semantic defect in source code snippets. With descriptive identifier names, developers spent more time in the lines of code before the actual defect occurred and changed their reading direction less often, finding the semantic defect about 14% faster than with shorter but less descriptive identifier names. These effects disappeared when developers searched for a syntax error, i.e., when no in-depth understanding of the code was required. Interestingly, the style of identifier names had a clear impact on program comprehension for more experienced developers but not for less experienced developers.

Developers spend a substantial amount of their time with program comprehension. To improve their comprehension and refresh their memory, developers need to communicate with other developers, read the documentation, and analyze the source code. Many studies show that developers focus primarily on the source code and that small improvements can have a strong impact. As such, it is crucial to bring the code itself into a more comprehensible form. A particular technique for this purpose are explicit feature traces to easily identify a program’s functionalities. To improve our empirical understanding about the effects of feature traces, we report an online experiment with 49 professional software developers. We studied the impact of explicit feature traces, namely annotations and decomposition, on program comprehension and compared them to the same code without traces. Besides this experiment, we also asked our participants about their opinions in order to combine quantitative and qualitative data. Our results indicate that, as opposed to purely object-oriented code: (1) annotations can have positive effects on program comprehension; (2) decomposition can have a negative impact on bug localization; and (3) our participants perceive both techniques as beneficial. Moreover, none of the three code versions yields significant improvements on task completion time. Overall, our results indicate that lightweight traceability, such as using annotations, provides immediate benefits to developers during software development and maintenance without extensive training or tooling; and can improve current industrial practices that rely on heavyweight traceability tools (e.g., DOORS) and retroactive fulfillment of standards (e.g., ISO-26262, DO-178B).

During software maintenance, understanding source code is one of time-consuming activities. Good programming practice suggests that programmers should insert blank lines to divide source code into functional segments, and a comment at the beginning of each functional segment. Those help developers to understand functional segmentation of source code, such as start and end points of each functional segment. Unfortunately, programmers do not always follow this practice. In this paper, we propose an approach to dividing source code into functional segments. Our approach uses cohesion metric for code portion to identify start and end points of each functional segment.

On regression testing of object-oriented programs

Comprehending and modeling the behavior of user interfaces exposed by Rich Internet Applications (RIAs) are important activities in software maintenance, testing, and evolution. This paper presents an ‘agile’ process for the reverse engineering of Rich Internet Application User Interfaces: the process is based on dynamic analysis of the application, is iterative and exploits heuristic clustering criteria for reducing the data gathered by dynamic analysis. Moreover, it is based on the continuous validation feedback of the process executor, and allows the incremental reconstruction of a Finite State Machine for modeling the behavior of RIA GUIs. This approach is supported by CReRIA, an integrated reverse engineering environment that provides automatic facilities for executing the process and incrementally recovering the FSM model. A preliminary experiment involving the analysis of three real Web applications showed the feasibility of the approach, and highlighted interesting advantages of using the agility in reverse engineering processes.

Software maintenance is the most demanding and effort-consuming phase in software development. It has been recognized as being a tedious step in software development process. Two basic activities in software maintenance are the understanding of the system and the assessment of the potential effects of a change. A change to a system, however small, can lead to several accidental effects, which are often not obvious and easy to identify. The main purpose of impact analysis is not only to find the impact set in terms of coding elements but also in terms of effort and resources required for implementing the change so that analysts could analyze the impact of the requested change in terms of budget. The objective of this paper is to find the impact set of the change requested by user or client. By using the impact set we estimate the regression test effort. We illustrate our results with a case study. As the results of this work, we get the impact set having impact element as class names with respect to the requested change, the test suite and the effort required for regression testing after the implementation of the requested change.

The past two decades have seen increasing sophistication in software work. Now and in the future, the work of both practitioners and researchers would be helped by a more objective and finer granularity recognition of types of software evolution and software maintenance activities as actually done. To these ends, this paper proposes a clarifying redefinition of the types of software evolution and software maintenance. The paper bases the proposed classification not on people's intentions but upon objective evidence of maintainers' activities ascertainable from observation of activities and artifacts, and/or a before and after comparison of the software documentation. The classification includes taking into account in a semi‐hierarchical manner evidence of the change or lack thereof in: (1) the software, (2) the documentation, (3) the properties of the software, and (4) the customer‐experienced functionality. A comparison is made with other classifications and typologies. The paper provides a classified list of maintenance activities and a condensed decision tree as a summary guide to the proposed evidence‐based classification of the types of software evolution and software maintenance. Copyright © 2001 John Wiley & Sons, Ltd.

Unit testing represents a key activity in software development and maintenance. Test suites with high internal quality facilitate maintenance activities, such as code comprehension and regression testing. Several guidelines have been proposed to help developers write good test suites. Unfortunately, such rules are not always followed resulting in the presence of bad test code smells (or simply test smells). Test smells have been defined as poorly designed tests and their presence may negatively affect the maintainability of test suites and production code. Despite the many studies that address code smells in general, until now there has been no empirical evidence regarding test smells (i) distribution in software systems nor (ii) their impact on the maintainability of software systems. This paper fills this gap by presenting two empirical studies. The first study is an exploratory analysis of 18 software systems (two industrial and 16 open source) aimed at analyzing the distribution of test smells in source code. The second study, a controlled experiment involving twenty master students, is aimed at analyzing whether the presence of test smells affects the comprehension of source code during software maintenance. The results show that (i) test smells are widely spread throughout the software systems studied and (ii) most of the test smells have a strong negative impact on the comprehensibility of test suites and production code.

Many techniques and tools have been developed to improve program comprehension but most tools are unsuitable for novices. Some tools are not user friendly, some designs are more suitable to expert programmers and some integrated development environments (IDEs) are very simple and fail to support program comprehension needs among the users. These factors hinder the learning process and may become obstacles to users who have no programming background. This paper attempts to improve program comprehension by using Zoom Visual Flow (ZViF) technique that represents source code in graphical views. It also gives some insights on how to improve visual presentation method in a program editor or an IDE. A lab experiment was conducted to determine the effectiveness of the technique. The respondents were asked to determine their preference between ZViF technique and Control Structured Diagram (CSD). CSD is one of the best techniques that uses graphic to visualize a program. The result shows that users prefer the proposed technique compared to CSD as the ZViF helps to improve program comprehension among novices.

Understanding source code is crucial for successful software maintenance. A particularly important activity to understand source code is navigating the call graph [4]. Programmers have developed distinct strategies for effective call graph exploration [3, 9]. We introduce Blaze, a source code exploration tool tailored closely to these strategies. In a study, we compare Blaze to Stacksplorer [2], a tool that visualizes the immediate neighborhood of the current method in the call graph, to a tool resembling the standard Call Hierarchy view in the Eclipse IDE, and to an unmodified Xcode installation. The call graph exploration tools significantly increased success rates in typical software maintenance tasks, and using Stacksplorer or Blaze significantly reduced task completion times compared to using the Call Hierarchy or Xcode.