This thesis defines a set of program restructuring operations (refactorings) that support the design, evolution and reuse of object-oriented application frameworks. The focus of the thesis is on automating the refactorings in a way that preserves the behavior of a program. The refactorings are defined to be behavior preserving, provided that their preconditions are met. Most of the refactorings are simple to implement and it is almost trivial to show that they are behavior preserving. However, for a few refactorings, one or more of their preconditions are in general undecidable. Fortunately, for some cases it can be determined whether these refactorings can be applied safely. Three of the most complex refactorings are defined in detail: generalizing the inheritance hierarchy, specializing the inheritance hierarchy and using aggregations to model the relationships among classes. These operations are decomposed into more primitive parts, and the power of these operations is discussed from the perspectives of automatability and usefulness in supporting design. Two design constraints needed in refactoring are class invariants and exclusive components. These constraints are needed to ensure that behavior is preserved across some refactorings. This thesis gives some conservative algorithms for determining whether a program satisfies these constraints, and describes how to use this design information to refactor a program.

Invisibility is an inherent and significant problem in the task of developing large software systems. There are no direct solutions to this problem

Abstract—Software system documentation is almost always expressed informally in natural language and free text. Examples include requirement specifications, design documents, manual pages, system development journals, error logs, and related maintenance reports. We propose a method based on information retrieval to recover traceability links between source code and free text documents. A premise of our work is that programmers use meaningful names for program items, such as functions, variables, types, classes, and methods. We believe that the application-domain knowledge that programmers process when writing the code is often captured by the mnemonics for identifiers; therefore, the analysis of these mnemonics can help to associate high-level concepts with program concepts and vice-versa. We apply both a probabilistic and a vector space information retrieval model in two case studies to trace C++ source code onto manual pages and Java code to functional requirements. We compare the results of applying the two models, discuss the benefits and limitations, and describe directions for improvements.

Systematic discovery and exploitation of commonality across related software systems is a fundamental technical requirement for achieving successful software reuse. By examining a class/family of related systems and the commonality underlying those systems, it is possible to obtain a set of reference models, i.e., software architectures and components needed for implementing applications in the class. FORM (Feature-Oriented Reuse Method) supports development of such reusable architectures and components (through a process called the “domain engineering”) and development of applications using the domain artifacts produced from the domain engineering. FORM starts with an analysis of commonality among applications in a particular domain in terms of services, operating environments, domain technologies, and implementation techniques. The model constructed during the analysis is called a "feature " model, and it captures commonality as an AND/OR graph, where AND nodes indicate mandatory features and OR nodes indicate alternative features selectable for different applications. Then, this model is used to define parameterized reference architectures and appropriate reusable components instantiatable during actual application development. Architectures are defined from three different viewpoints (subsystem, process, and module) and have

Abstract: It is important to be able to reason architecturally about a software system. However, architectural documentation frequently does not exist and even when it does exist, it is often out of sync with the implemented system. In addition, it is rare that software development begins with a clean slate; systems are almost always constrained by existing legacy code. As a consquence, we need to be able to extract information from existing system implementations and reason architecturally about this information. This paper presents Dali, an open, lightweight workbench that aids an analyst in extracting, manipulating, and interpreting architectural information. By assisting in the reconstruction of architectures from extracted information, Dali helps an analyst redocument architectures and discover the relationship between as-implemented and asdesigned architectures. 1 Software Architecture as Shared Hallucination The formal study of software architecture has been a significant addition to the software engineering repertoire in the 1990s. It has promised much to designers and developers: help with the high

The object-oriented design community has recently begun to collect so-called design patterns: cliches plus hints to their recommended use in software construction. The structural design patterns Adapter, Bridge, Composite, Decorator, and Proxy represent packaged problem/context/solution/properties descriptions to common problems in object-oriented design. Localizing instances of these patterns in existing software produced without explicit use of patterns can improve the maintainability of software. In our approach, called the Pat system, design information is extracted directly from C ++ header files and stored in a repository. The patterns are expressed as Prolog rules and the design information is translated into facts. A single Prolog query is then used to search for all patterns. We examined four applications, including the popular class libraries zApp and LEDA, with Pat. With some restrictions all pattern instances are found; the precision is about 40 percent. Since manual filtering of the output is relatively easy, we consider Pat a useful tool for discovering or recovering design information.

Software engineering research has focused mainly on software construction and has neglected software maintenance and evolution. Proposed is a shift in research from synthesis to analysis. Reverse engineering is introduced as a possible solution to program understanding and software analysis. Presented is reverse engineering technology developed as part of the Rigi project. The Rigi approach involves the identification of software artifacts in the subject system and the aggregation of these artifacts to form more abstract architectural models. Reported are some analyses on the source code of SQL/DS, performed by the authors while visiting the Program Understanding project at the IBM Centre for Advanced Studies in Toronto.

Many reverse-engineering tools have been developed to derive abstract representations from source code. Yet, most of these tools completely ignore recovery of the all-important rationale behind the design decisions that have led to its physical shape. Design patterns capture the rationale behind proven design solutions and discuss the trade-offs among their alternatives. We argue that it is these patterns of thought that are at the root of many of the key elements of large-scale software systems, and that, in order to comprehend these systems, we need to recover and understand the patterns on which they were built. In this paper, we present our environment for the reverse engineering of design components based on the structural descriptions of design patterns. We give an overview of the environment, explain three case studies, and discuss how pattern-based reverse-engineering helped gain insight into the design rationale of some of the pieces of three large-scale C++ software systems. Keywords Reverse-engineering, design recovery, design component,

Legacy systems pose problems to maintainers that can be solved partially with effective tools. A prototype tool for determining collections of files sharing a large amount of text has been developed and applied to a 40 megabyte source tree containing two releases of the gcc compiler. Similarities in source code and documentation corresponding to software cloning, movement and inertia between releases, as well as the effects of preprocessing easily stand out in a way that immediately conveys nonobvious structural information to a maintainer taking responsibility for such a system.

TXL is a special-purpose programming language designed for creating, manipulating and rapidly prototyping language descriptions, tools and applications. TXL is designed to allow explicit programmer control over the interpretation, application, order and backtracking of both parsing and rewriting rules. Using first order functional programming at the higher level and term rewriting at the lower level, TXL provides for flexible programming of traversals, guards, scope of application and parameterized context. This flexibility has allowed TXL users to express and experiment with both new ideas in parsing, such as robust, island and agile parsing, and new paradigms in rewriting, such as XML markup, rewriting strategies and contextualized rules, without any change to TXL itself. This paper outlines the history, evolution and concepts of TXL with emphasis on its distinctive style and philosophy, and gives examples of its use in expressing and applying recent new paradigms in language processing.