1 Superimposition: A Component Adaptation Technique Jan Bosch University of Karlskrona/Ronneby Department of Computer Science and Business Administration S-372 25 Ronneby, Sweden e-mail: Jan.Bosch@ide.hk-r.se www: http://www.ide.hk-r.se/~bosch Abstract Several authors have identified that the only feasible way to increase productivity in software construction is to reuse existing software. To achieve this, component-based software development is one of the more promising approaches. However, traditional research in component-oriented programming often assumes that components are reused “as-is”. Practitioners have found that “as-is” reuse seldomly occurs and that reusable components generally need to be adapted to match the system requirements. Existing component object models provide only limited sup- port for component adaptation, i.e. white-box techniques such as copy-paste and inheritance and black-box approaches such as aggregation and wrapping. These techniques suffer from problems related to reusability, effi- ciency, implementation overhead or the self problem. To address these problems, this paper proposes superimposi- tion, a novel black-box adaptation technique that allows one to impose predefined, but configurable types of functionality on a reusable component. Three categories of typical adaptation types are discussed, related to the component interface, component composition and component monitoring. Superimposition and the types of com- ponent adaptation are exemplified by several examples. 1 Introduction Component-oriented programming is receiving increasing amounts of interest in the software engineering community. The aim is to create a collection of reusable components that can be used for component-based application develop- ment. Application development then becomes the selection, adaptation and composition of components rather than implementing the application from scratch. The concept of component-oriented programming almost seems analo- gous to object-oriented programming. The notion of a component refers to an module that contains both code and data and presents an interface that can be invoked by other components. The naive view of component reuse is that the component can just be plugged into an application and reused as is. However, many researchers, e.g. [Hölzle 93, Samentinger 97, Yellin & Strom 94], have identified that “as-is” reuse is very unlikely to occur and that in the majority of the cases, a reused component has to be adapted in some way to match the application’s requirements. Adapting a component can be achieved in several ways, but traditional tech- niques can be categorised into white-box, e.g. inheritance and copy-paste, and black-box, e.g. wrapping, adaptation. The white-box adaptation techniques generally require understanding of the internals of the reused component, whereas the black-box adaptation techniques ideally only require knowledge about the component’s interface. In this paper, we argue that the aforementioned techniques are insufficient to deal with all required types of adaptation without experiencing, potentially considerable, problems. Examples of these problems are the lack of reusability of components, since they cannot be adapted, and the adaptation specification itself. In addition, the software engineer may spend considerable effort on understanding the component before being able to adapt it. Also, non-transparent adaptation techniques may lead to the self problem [Lieberman 86] and, finally, the adapting a component may require considerable amounts of code with extremely simple behaviour, e.g. forwarding a message. To address these problems, we introduce the notion of superimposition, a technique that enables the software engineer to impose predefined, but configurable, types of functionality on a component’s functionality. Examples of superim- posing behaviour are interface adaptation as in the Adapter design pattern [Gamma et al. 94], client specific interfaces and implicit invocation. Superimposition allows the software engineer to adapt a component using a number of prede- fined adaptation behaviours that can be configured for the specific component. Since one may identify new types of adaptation behaviour, the software engineer can define new adaptation types. Finally, the software engineer may com- pose multiple adaptation behaviour types for a single component.