Software change requests are often formulated as requests to modify or to add a specific feature or concept. To implement these changes, the features or concepts must be located in the code. In this paper, we describe the scenarios of the feature and concept location. The scenarios utilize a computer-assisted search of software dependence graph. Scenarios are demonstrated by a case study of NCSA Mosaic source code. 1. Introduction In software maintenance and evolution, change requirements are often formulated as requests to modify or to add specific program concepts or features [2, 26]. An example of such a request is "Add a new external viewer to Mosaic web browser". Before any actual change can be made to the system, software programmers must locate the implementation of the concepts ("external viewer") in the source code. Concept location is a process that maps domain concepts to the software components. The input is the maintenance request, expressed in natural language and usin...

Abstract not found

To facilitate software maintenance and evolution, a helpful step is to locate features concerned in a particular maintenance task. In the literature, both dynamic and interactive approaches have been proposed for feature location. In this paper, we present a static and non-interactive method for achieving this objective. The main idea of our approach is to use the information retrieval (IR) technology to reveal the basic connections between features and computational units in source code. Due to the characteristics of the retrieved connections, we use a static representation of the source code named BRCG to further recover both the relevant and the specific computational units for each feature. Furthermore, we recover the relationships among the relevant units for each feature. A premise of our approach is that programmers should use meaningful names as identifiers. We perform an experimental study based on a GNU system to evaluate our approach. In the experimental study, we present the detailed quantitative experimental data and give the qualitative analytical results. 1.

This paper presents a model of change propagation during software maintenance and evolution. Change propagation is modeled as a sequence of snapshots, where each snapshot represents one particular moment in the process, with some software dependencies being consistent and others being inconsistent. A snapshot is changed into the next one by a change in one software entity and the dependencies related to it. The formalism for this process is based on graph rewriting. The paper discusses two basic processes of change propagation: change-and-fix, and top-down propagation. It also describes a prototype tool "Ripples 2" which supports both processes, and an example of the use of the tool. 1. Introduction Change propagation is one of the key parts of software maintenance and evolution. In order to explain change propagation, we have to understand that software consists of entities (classes, objects, functions, etc.) and their dependencies. The dependency between entities A and B means that...

as conforming

Software systems contain entities, such as functions and variables, which are related to each other. As a software system evolves to accommodate new features and repair bugs, changes occur to these entities. Developers must ensure that related entities are updated to be consistent with these changes. This paper

Incremental software change adds new functionality to software. It is the foundation of software evolution, maintenance, iterative development, agile development, and other software processes. Highly interactive tool JRipples provides the programmer with the organizational support that makes the incremental change process easier and more systematic. JRipples supports impact analysis and change propagation, the two most difficult activities of the incremental change. 1.

We propose a sound and practical approach, based on a formal method (known as Interval Temporal Logic), to cope with `change' and analyse its effect. The approach allows us to capture a snapshot of system's behaviour over which various interesting properties, such as liveness, timeliness and safety properties, can be validated compositionally. These properties may include invariants that are required to be valid after changes have taken place. We also present and evaluate the design and implementation of a formal tool, AnaTempura, which supports the developed approach. A case study is presented to illustrate our approach and the tool. 1. Introduction Computing systems, both hardware and software, are continually evolving. This evolution will inevitably lead to their rapid growth in size and change to their original requirements rendering them to `legacy' status. In fact, some consider a system to be in a legacy state even before it is being deployed! The evolution of software system...

Software change requests are often formulated as requests to modify or to add a specific feature or concept. To implement these changes, the features or concepts must be located in the code. In this paper, we describe the scenarios of the feature and concept location. The scenarios utilize a computer-assisted search of software dependence graph. Scenarios are demonstrated by a case study of NCSA Mosaic source code.