A Systematic Survey of Program Comprehension through Dynamic Analysis

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.

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.

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.

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.

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.

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 procedure have been attracted a lot of attentions and have been investigated using a variant methodologies such as thinking aloud, summary analysis, and Eye-tracking. Program comprehension tools main objective is understanding source code which is substantial factor in software maintenance activities. Visualization is a popular approach in earning this understanding. This paper present a comprehend analysis of concepts and techniques that have been used in building the visualization tools. Then we display a thorough comparison between two widely visualization tools which are SHriMP and LEONARDO.

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.

Software maintenance and evolution constitutes an important part of the total cost of the life cycle of software. Some even argue this is the most important fraction of the cost. The added value of software maintenance and evolution is often not fully understood by the customer leading to a perception that software maintenance organizations are costly and inefficient. A common view of maintenance and evolution is that it merely fixes bugs. However, studies over the years have indicated that in many organizations the majority of the maintenance effort is devoted to value-added activities. To improve customer perceptions it is important to provide them with better insight into the activities performed by the maintenance organization and to document such performance with objective measures of software maintenance activities. In this paper, software maintenance trend analysis is used as a basis for improvement. First, the differences between software maintenance activities and the Information System (IS) department development projects are described. Then a trend model is developed as a mean to manage the expectations of customers. To conclude, some remarks are made regarding the application of trend analysis by maintenance work categories for software maintenance managers.

On regression testing of object-oriented programs

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.

One of the most frequent problems faced by software maintainers is to find the location of the code related with specific features. This is a costly task because features tend to be scattered in the code. Considering this problem, several approaches for locating features using dynamic analysis have been developed. Nonetheless, the use of dynamic analysis is not fully incorporated in the daily practice of software maintainers. Empirical studies that reveal strengths and weaknesses of the use dynamic analysis in maintenance tasks can bring better understanding of this problem. This study contributes with an empirical assessment of the use of execution traces on software maintenance. We report on a controlled experiment performed with developers when they were performing actualmaintenance activities on systems of different sizes. There are benefits related with a systematic use of execution traces by reducing the execution time and increasing the correction of the developer task during software maintenance. Also, a lower level of difficulty of the tasks was perceived by the participants using dynamic information. Another conclusion is that the approach seems to be useless in maintenance activities where the problem of feature scattering does not occur clearly. This study also reveals that there are still some challenges related to false negatives.

Developers often encounter unfamiliar code during software maintenance which consumes a significant amount of time for comprehension, especially for novice programmers. Researchers have come up with automated techniques that can provide effective code comprehension and summaries by analyzing a source code and present key information to the developers. Existing debuggers represent the execution states of the program but they do not show the complete execution at a single point. Studies have revealed that the effort required for program comprehension can be reduced if novice programmers are provided with worked examples. Hence, we propose COSPEX (Comprehension using Summarization via Program Execution) - an Atom plugin that dynamically extracts key information for every line of code executed and presents it to the developers in the form of an interactive example-like dynamic information instance. As a preliminary evaluation, we presented 14 undergraduates having Python programming experience up to 1 year with a code comprehension task in a user survey. We observed that COSPEX helped novice programmers in program comprehension and improved their understanding of the code execution. The source code and tool are available at: https://github.com/rishalab/COSPEX, and the demo on Youtube is available at: https://youtu.be/QQY-8KuDaEM.

During software development and maintenance, developers spend a considerable amount of time on program comprehension. 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.

Feature location aims at locating pieces of code that implement a given set of features (requirements). It is a necessary first step in every program comprehension and maintenance task if the connection between features and code has been lost.We have developed a semi-automatic technique for feature location using a combination of static and dynamic program analysis. Formal concept analysis is used to explore the results of the dynamic analysis.We describe new experiences with our technique. Specifically, we investigate the gain of information and increase of costs when the system under analysis is profiled at basic block level rather than routine level as in our earlier work. Furthermore, we explore the influence of the scenarios used for the dynamic analysis (minimal versus combined scenarios).