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...

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...

in software requirements. This paper presents a theoretical model for the evolution of component-based software, based on evolving interoperation graphs. The model assumes that each change consists of smaller granularity steps of change propagation, each of them being a visit to one specific component. If the component is modified, it may no longer fit with the other components because it may no longer properly interact with them. In that case secondary changes must be made in neighboring components, which may trigger additional changes, etc. The paper contains an example of evolution of a calendar program, represented in UML. 1.

Traffic routing is a key component in a network planning system. This paper concentrates on the routing algorithms and follows their evolution over multiple releases of a planning tool during a period of six years. The algorithms have grown from the initial stage of finding shortest paths with Dijkstra's algorithm to cover more complex routing tasks such as finding protected and unprotected routes and capacity limited routing. We present the algorithms and in particular emphasize the practical aspects: how previous algorithms were reused and what were the practical experiences of using the algorithms. A conclusion of the study is that algorithms should be considered with an engineering attitude. It is not enough to focus on selecting the most sophisticated state-ofthe -art algorithm for a given problem. Evolution capability, potential for reuse, and the development cost over the system lifetime are equally important aspects. 2001 Elsevier Science Inc. All rights reserved.

In this report, we present an overview of the existing software re-engineering process and its related concepts. We also classify existing software reuse techniques and we propose how to integrate such techniques into the software re-engineering process by following a component-based approach. In addition, we demonstrate how our methodology can be applied on a client-server legacy 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.