The paper focuses on investigating the combined use of semantic and structural information of programs to support the comprehension tasks involved in the maintenance and reengineering of software systems. Here, semantic refers to the domain specific issues (both problem and development domains) of a software system. The other dimension, structural, refers to issues such as the actual syntactic structure of the program along with the control and data flow that it represents. An advanced information retrieval method, latent semantic indexing, is used to define a semantic similarity measure between software components. Components within a software system are then clustered together using this similarity measure. Simple structural information (.e., file organization) of the software system is then used to assess the semantic cohesion of the clusters and files, with respect to each other. The measures are formally defined for general application. A set of experiments is presented which demonstrates how these measures can assist in the understanding of a nontrivial software system, namely a version of NCSA Mosaic.

Source code duplication occurs frequently within large software systems. Pieces of source code, functions, and data types are often duplicated in part, or in whole, for a variety of reasons. Programmers may simply be reusing a piece of code via copy and paste or they may be "reinventing the wheel".

Program slicing is a viable method to restrict the focus of a task to specific sub-components of a program. Examples of applications include debugging, testing, program comprehension, restructuring, downsizing, and parallelization. This paper discusses different statement deletion based slicing methods, together with algorithms and applications to software engineering.

Generic language technology and compiler construction techniques are a prerequisite to build analysis and conversion tools that are needed for the re-engineering of large software systems. We argue that generic language technology is a crucial means to do fundamental re-engineering. Furthermore, we address the issue that the application of compiler construction techniques in re-engineering generates new research questions in the field of compiler construction.

We present conditioned slicing as a general slicing framework for program comprehension. A conditioned slice consists of a subset of program statements which preserves the behavior of the original program with respect to a set of program executions. The set of initial states of the program that characterize these executions is specified in terms of a first order logic formula on the input variables of the program. Conditioned slicing allows a better decomposition of the program giving the maintainer the possibility to analyze code fragments with respect to different perspectives. We also show how slices produced with traditional slicing methods can be reduced to conditioned slices. Conditioned slices can be identified by using symbolic execution techniques and dependence graphs. 1 Introduction The comprehension of an existing software system consumes from 50% up to 90% of its maintenance time. Comprehending a software system can be defined as the process of abstracting higher level d...

When programmers perform maintenance tasks, program understanding is required. One of the first activities in understanding a software system is identifying its subsystems and their relations, i.e. its software architecture. Since a large part of the effort is spent in creating a mental model of the system under study, tools can help maintainers in managing the evolution of legacy systems, by showing them architectural information. In this paper, an environment for the architectural analysis of software systems is described. The environment is based on a hierarchical architectural model that drives the application of a set of recognizers, each producing a different architectural view of the system or of some of its parts. Recognizers embody knowledge about architectural clich'es and use flow analysis techniques to make their output more accurate. 1

The large size and high-percentage of domain-specific code in most legacy systems makes it unlikely that automated understanding tools will be able to completely understand them. Yet automated tools can clearly recognize portions of the design. That suggests exploring environments in which programmer and system work together to understand legacy software. This paper describes such an environment that supports programmer and system cooperating to extract an object-oriented design from legacy software systems. It combines an automated program understanding component that recognizes standard implementations of domain independent plans with with a structured notebook that the programmer uses to link object-oriented design primitives to arbitrary source code fragments. This jointly extracted information is used to support conceptual queries about the program's code and design. 1 Introduction The standard goal of most program understanding efforts is a tool that takes source code and extrac...

ion: Usually an OO component can be characterized by a noun, e.g., calendar, flight manager, fire alarm system. Operations: Components have operations, and these are characterized in the Operations facet. Operates On: This facet describes the objects that the component acts on, e.g., integers, set, list, resource. Dependencies: These are non-functional dependencies and characteristics which limit the scope of reuse to a certain context, e.g., C++ code, Unix-based software, HOOD design models. An example could be a stack (abstraction) of integer (operates on) written in C++ (dependencies) with operations push, pop, top, and swap. It is possible to have more than one term for each facet. In addition to the terms filled in for the facets, a component will have other attributes, such as size, developer, and date. The distinction between facets and other attributes is that the facets are the properties most relevant for reuse. For the facets, structured term spaces are provided, facilita...

Many existing software systems can benefit from restructuring to reduce maintenance cost and improve reusability. Yet, intuition-based, ad-hoc restructuring can be difficult and expensive, and can even make software structure worse. We introduce a quantitative framework for software restructuring. In the framework, restructuring decisions are guided by visualized design information and objective criteria. The design information can be extracted directly from code to restructure existing or legacy software. Criteria for comparing alternative design structures including measures of design-level cohesion and coupling. Restructuring is accomplished through a series of decomposition and composition operations which increase the cohesion and/or decrease the coupling of individual system components. An example and a case study demonstrate the framework. The framework insures that restructuring results in measured improvements to design quality.

Programs express domain-level concepts in their source code. It might be expected that such concepts would have a degree of semantic cohesion. This cohesion ought to manifest itself in the dependence between statements all of which contribute to the computation of the same concept. This paper addresses a set of research questions that capture this informal observation. It presents the results of experiments on ten programs that explore the relationship between domain-level concepts and dependence in source code. The results show that code associated with concepts has a greater degree of coherence, with tighter dependence. This finding has positive implications for the analysis of concepts as it provides an approach to decompose a program into smaller executable units, each of which captures the behaviour of the program with respect to a domain-level concept. ∗On sabbatical leave from Loyola College in Maryland.