An important step toward efficient software maintenance is to locate the code relevant to a particular feature. In this paper we report a study applying an execution slice-based technique to a reliability and performance evaluator to identify the code which is unique to a feature, or is common to a group of features. Supported by tools called ATAC and Vue, the program features in the source code can be tracked down to files, functions, lines of code, decisions, and then c- or p-uses. Our study suggests that the technique can provide software programmers and maintainers with a good starting point for quick program understanding.

Abstract not found

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

The paper recasts the problem of feature location in source code as a decision-making problem in the presence of uncertainty. The main contribution consists in the combination of two existing techniques for feature location in source code. Both techniques provide a set of ranked facts from the software, as result to the feature identification problem. One of the techniques is based on a Scenario Based Probabilistic ranking of events observed while executing a program under given scenarios. The other technique is defined as an information retrieval task, based on the Latent Semantic Indexing of the source code. We show the viability and effectiveness of the combined technique with two case studies. A first case study is a replication of feature identification in Mozilla, which allows us to directly compare the results with previously published data. The other case study is a bug location problem in Mozilla. The results show that the combined technique improves feature identification significantly with respect to each technique used independently. * 1.

Concept location in source code is the process that identifies where a software system implements a specific concept. While it is well accepted that concept location is essential for the maintenance of complex procedural code like code written in C, it is much less obvious whether it is also needed for the maintenance of the Object-Oriented code. After all, the Object-Oriented code is structured into classes and well-designed classes already implement concepts, so the issue seems to be reduced to the selection of the appropriate class. The objective of our work is to see if the techniques for concept location are still needed (they are) and whether Object-Oriented structuring facilitates concept location (it does not). This paper focuses on static concept location techniques that share common prerequisites and are search the source code using regular expression matching, or static program dependencies, or information retrieval. The paper analyses these techniques to see how they compare to each other in terms of their respective strengths and weaknesses. 1.

The first task of a programmer who wants to understand how a certain feature is implemented is to localize the implementation of the feature in the code. If the implementations of a set of related features are to be understood, a programmer is interested in their commonalities and variabilities. For large and badly documented programs, localizing features in code and identifying commonalities and variabilities of components and features can be difficult and time-consuming. It is useful to derive this information automatically. The feature-

This paper describes an approach to the feature location problem for distributed systems, that is, to the problem of locating which code components are important in providing a particular feature for an end user. A feature is located by observing system execution and noting time intervals in which it active. Traces of execution in intervals with and without the feature are compared. Earlier experience has shown that this analysis is di#cult because distributed systems often exhibit stochastic behavior and because time intervals are hard to identify with precision.

As programs evolve, their code increasingly becomes tangled by programmers and requirements. This mosaic quality complicates program comprehension and maintenance. Many of these activities can benefit from viewing the program as a collection of features. We introduce an inexpensive and easily comprehensible summary of program changes called the feature signature and investigate its properties. We find a remarkable similarity in the nature of feature signatures across multiple non-trivial programs, developers and magnitudes of changes. This indicates that feature signatures are a meaningful notion worth studying. We then show numerous applications of feature signatures, establishing their utility. 1

Aspect mining is a reverse engineering process that aims at finding crosscutting concerns in existing systems. This paper proposes an aspect mining approach based on determining methods that are called from many different places, and hence have a high fan-in, which can be seen as a symptom of crosscutting functionality. The approach is semi-automatic, and consists of three steps: metric calculation, method filtering, and call site analysis. Carrying out these steps is an interactive process supported by an Eclipse plug-in called FINT. Fan-in analysis has been applied to three open source Java systems, totaling around 200,000 lines of code. The most interesting concerns identified are discussed in detail, which includes several concerns not previously discussed in the aspect-oriented literature. The results show that a significant number of crosscutting concerns can be recognized using fan-in analysis, and each of the three steps can be supported by tools.

Key parts of software change are concept location and change propagation. We introduce a tool RIPPLES that supports both. It uses the Abstract System Dependence Graph (ASDG) of the program, enriched by conceptual dependencies. A case study of NCSA Mosaic demonstrates the use of the tool. Precision and recall are used to evaluate the quality of support provided by RIPPLES.