Software productivity has been steadily increasing over the last 30 years, but not enough to close the gap between the demands placed on the software industry and what the state of the practice can deliver [22,39]; nothing short of an order of magnitude increase in productivity will extricate the software industry from its perennial crisis [39,67]. Several decades of intensive research in software engineering and artificial intelligence left few alternatives but sofware reuse as the (only) realistic approach to bring about the gains of productivity and quality that the software industry needs. In this paper, we discuss the implications of reuse on the production, with an emphasis on the technical challenges. Software reuse involves building software that is reusable by design, and building with reusable software. Software reuse includes reusing both the products of previous software projects, and the processes deployed to produce them, leading to a wide spectrum of reuse approaches, from the building blocks (reusing products) approach on one hand, to the generative or reusable processor (reusing processes) on the other [68]. We discuss the implications of such appproaches on the organization, control, and method of software development and discuss proposed models for their economic analysis. Software reuse benefits from methodologies and tools to: 1) build more readily reusable software, and 2) locate, evaluate, and tailor reusable software, the latter being critical for the building blocks approach. Both sets of issues are discussed in this paper, with a focus on application generators and object-oriented development for the first, and a thorough discussion of retrieval techniques for software components, component composition (or bottom-up design) and transformational systems for the second. We conclude by highlighting areas that, in our opinion, are worthy of further investigation.

While a number of research systems have demonstrated the potential value of program transformations, very few of these systems have made it into practice. The core technology for such systems is well understood; what remains is integration and more importantly, the problem of handling the scale of the applications to be processed. This paper describes DMS, a practical, commercial program analysis and transformation system, and sketches a variety of tasks to which it has been applied, from redocumenting to large-scale system migration. Its success derives partly from a vision of design maintenance and the construction of infrastructure that appears necessary to support that vision. DMS handles program scale by careful space management, computational scale via parallelism

GenVoca generators synthesize software systems by composing components from reuse libraries. GenVoca components are designed to export and import standardized interfaces, and thus be plugcompatible, interchangeable, and interoperable with other components. In this paper, we examine two different but important issues in software system synthesis. First, not all syntactically correct compositions of components are semantically correct. We present simple, efficient, and domainindependent algorithms for validating compositions of GenVoca components. Second, components that export and import immutable interfaces are too restrictive for software system synthesis. We show that the interfaces and bodies of GenVoca components are subjective, i.e., they mutate and enlarge upon instantiation. This mutability enables software systems with customized interfaces to be composed from components with “standardized ” interfaces. 1

Abstract 1 Refactorings are behavior-preserving program transformations that automate design level changes in object-oriented applications. Our previous research established that many schema transformations, design patterns, and hotspot meta-patterns are automatable. This research evaluates whether refactoring technology can be transferred to the mainstream by restructuring non-trivial C++ applications. The applications that we examine were evolved manually by software engineers. We show that an equivalent evolution could be reproduced significantly faster and cheaper by applying a handful of general-purpose refactorings. In one application, over 14K lines of code were transformed automatically that otherwise would have been coded by hand. Our experiments identify benefits, limitations, and topics of further research related to the transfer of refactoring technology to a production environment. 1.

Abstract. A software product-line is a family of related programs. Each program is defined by a unique combination of features, where a feature is an increment in program functionality. Modularizing features is difficult, as feature-specific code often cuts across class boundaries. New modularization technologies have been proposed in recent years, but their support for feature modules has not been thoroughly examined. In this paper, we propose a variant of the expression problem as a canonical problem in product-line design. The problem reveals a set of technology-independent properties that feature modules should exhibit. We use these properties to evaluate five technologies: model of feature composition that is technology-independent and that relates compositional reasoning with algebraic reasoning 1. 1

Abstract 1 Domain-specific generators will increasingly rely on graphical languages for declarative specifications of target applications. Such languages will provide front-ends to generators and related tools to produce customized code on demand. Critical to the success of this approach will be domain-specific design wizards, tools that guide users in their selection of components for constructing particular applications. In this paper, we present the P3 ContainerStore graphical language, its generator, and design wizard. 1

Feature-Oriented Software Development (FOSD) provides a multitude of formalisms, methods, languages, and tools for building variable, customizable, and extensible software. Along different lines of research different ideas of what a feature is have been developed. Although the existing approaches have similar goals, their representations and formalizations have not been integrated so far into a common framework. We present a feature algebra as a foundation of FOSD. The algebra captures the key ideas and provides a common ground for current and future research in this field, in which also alternative options can be explored.

Although numerous mechanisms for promoting software reuse have been proposed and implemented over the years, most have focused on the reuse of implementation code. There is much conjecture and some empirical evidence, however, that the most effective forms of reuse are generally found at more abstract levels of software design. In this paper we discuss software reuse at the architectural level of design. Specifically, we argue that the concept of “architectural style ” is useful for supporting the classification, storage, and retrieval of reusable architectural design elements. We briefly describe the Aesop system’s Software Shelf, a tool that assists designers in selecting appropriate design elements and patterns based on stylistic

One of the factors that can make a program difficult to understand is that code responsible for accomplishing more than one purpose may be woven together in a single section. We call this interleaving, and it may arise either intentionally -- for example, in optimizing a program, a programmer may use some intermediate result for several purposes -- or unintentionally, due to patches, quick fixes, or other hasty maintenance practices. To understand this phenomenon, we have looked at a variety of interleaving instances in actual programs and have distilled characteristic features. If the characterization proves to be robust then it will enable the design of tools for detection of interleavings and the extraction of the individual strands of computation.

Conventional software engineering tends to focus on a small part of the software life cycle: the design and implementation of a product. The bulk of the lifetime cost is in the maintenance phase, where one must live with the product previously developed. Presently, we have little theory and fewer tools to help us manage the maintenance activity. We contend that a fundamental cause of the difficulty is the failure to preserve design information. This results from an over preoccupation with the synthesis and maintenance of code. We offer an alternative paradigm: . make the design the central focus of the construction process---get code as a byproduct; . make the design the central focus of the maintenance process---preserve revised designs and get code as a byproduct. A transformational scheme for accomplishing this is presented. We call it the Design Maintenance System. The programming roles change radically from coding instances for ill-defined specifications to specifiers of func...