Understanding the implementation of a certain feature of a system requires to identify the computational units of the system that contribute to this feature. In many cases, the mapping of features to the source code is poorly documented. In this paper, we present a semi-automatic technique that reconstructs the mapping for features that are triggered by the user and exhibit an observable behavior. The mapping is in general not injective; that is, a computational unit may contribute to several features. Our technique allows to distinguish between general and specific computational units with respect to a given set of features. For a set of features, it also identifies jointly and distinctly required computational units.

Concept location identifies parts of a software system that implement a specific concept that originates from the problem or the solution domain. Concept location is a very common software engineering activity that directly supports software maintenance and evolution tasks such as incremental change and reverse engineering. This paper addresses the problem of concept location using an advanced information retrieval method, Latent Semantic Indexing (LSI). LSI is used to map concepts expressed in natural language by the programmer to the relevant parts of the source code. Results of a case study on NCSA Mosaic are presented and compared with previously published results of other static methods for concept location. 1

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

Many of the approaches that analyze software evolution consider a static perspective of a system. Static analysis approaches focus on the evolution of static software entities such as packages, classes and methods. Without knowledge of the roles software entities play in system features, it is difficult to interpret the motivation behind changes and extensions in the code. To tackle this problem, we propose an approach to software evolution analysis that exploits the relationships between features and software entities. Our definition of a feature is a unit of observable behavior of a software system. We define history measurements that summarize the evolution of software entities from a feature perspective. We show how we use our feature perspective of software evolution to interpret modifications and extensions to the code. We apply our approach on two case studies and discuss our findings.

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.

Abstract—This paper recasts the problem of feature location in source code as a decision-making problem in the presence of uncertainty. The solution to the problem is formulated as a combination of the opinions of different experts. The experts in this work are two existing techniques for feature location: a scenario-based probabilistic ranking of events and an information retrieval-based technique that uses latent semantic indexing. The combination of these two experts is empirically evaluated through several case studies, which use the source code of the Mozilla Web browser and the Eclipse integrated development environment. The results show that the combination of experts significantly improves the effectiveness of feature location when compared to each of the experts used independently. Index Terms—program understanding, feature identification, concept location, dynamic and static analyses, information retrieval, Latent Semantic Indexing, scenario-based probabilistic ranking, open source software.

Nowadays, the majority of productivity applications are interactive and graphical in nature. In this paper, we explore the possibility of taking advantage of these two characteristics in a design recovery tool. Specifically, the fact that an application is interactive means that we can identify distinct execution bursts corresponding closely to "actions " performed by the user. The fact that the application is graphical means that we can describe those actions visually from fragments of the application display itself. Combining these two ideas, we obtain an explicit mapping from high-level actions performed by a user (similar to use case scenarios/specification fragments) to their low-level implementation. This mapping can be used for design recovery of interactive graphical applications. We demonstrate our approach using L Y X, a scientific word processor.

Without a clear understanding of how features of a software system are implemented, a maintenance change in one part of the code may risk adversely affecting other features. Feature implementation and relationships between features are not explicit in the code. To address this problem, we propose an interactive 3D visualization technique based on a combination of static and dynamic analysis which enables the software developer to step through visual representations of execution traces. We visualize dynamic behaviors of execution traces in terms of object creations and interactions and represent this in the context of a static classhierarchy view of a system. We describe how we apply our approach to a case study to visualize and identify common parts of the code that are active during feature execution. 1

The dynamic analysis approach to feature identification describes a technique for capturing feature behavior and mapping it to source code. Major drawbacks of this approach are (1) large amounts of data and (2) lack of support for sub-method elements. In this paper we propose to leverage sub-method reflection to identify and model features. We perform an on-the-fly analysis resulting in annotating the operations participating in a feature’s behavior with meta-data. The primary advantage of our annotation approach is that we obtain a fine-grained level of granularity while at the same time eliminating the need to retain and analyze large traces for feature analysis.

Introduction Software product line architectures promise significant benefits over traditional architectures such as shorter time-to-market, shorter and cheaper development cycles, and higher exploitation of the reuse potential at hand. While the ideas and concepts of product lines are well suited for developing new products, it is not obvious if and how one can apply this technology in the presence of legacy software. Migrating legacy software systems to a product line provides ways for extending and developing successful products and o#ers a chance to protect and preserve a company's former investments. The legacy artifacts have been designed under significantly di#erent circumstances and typically for just one single application domain. Therefore turning legacy software into a software product line requires a new design aware of the old product's key assets---assuming reuse really pays. Consequently, reengineering e#orts have to address a number of issues unique to product line de