Adaptation Strategies in Componentware Klaus Bergner, Andreas Rausch, Marc Sihling, Alexander Vilbig Technische Universit¨ at M ¨ unchen Institut f¨ ur Informatik Arcisstrasse 21, 80290 Munich, Germany bergner rausch sihling vilbig @in.tum.de Abstract In the context of componentware, there are several dif- ferent strategies to adapt a given ge¯ ner ¯ ic component. They differ in the necessary prerequisites and the achieved qual- ity of the resulting specific component with respect to re- liability, efficiency and reusability. In this paper, we dis- cuss a number of conceivable adaptation strategies for com- ponents, like wrapping, composition, or inheritance. We use the graphical user interface of a computer aided engi- neering system as an example to illustrate the transfer of a selected adaptation strategy into practical system develop- ment. 1 Introduction Component-oriented software development promises to allow the production of well-structured software systems using generic, truly reusable building blocks. However, it is still an open question if this promise can be kept, as it re- quires the existence of a universal set of configurable com- ponents which are prepared to be used in a specific context [BRSV98b]. Practical experience with today’s components suggests a different situation—most components cannot be used “out of the box”, but have to be adapted and tailored to the specific requirements and the given technical envi- ronment. Obviously, these observations apply especially to large, complex legacy components which have not been built according to componentware design criteria. In this paper, we argue that besides predetermined con- figuration, component adaptation is also a very useful strat- egy for embedding reusable components into new systems. Adaptation addresses the problem that many reusable com- This paper originates from the research in the project A1 “Methods for Component-Based Software Engineering” at the chair of Prof. Dr. Man- fred Broy, Institut f¨ ur Informatik, Technische Universit¨ at M¨ unchen. A1 is part of “Bayerischer Forschungsverbund Software-Engineering” (FOR- SOFT) and supported by Siemens AG, Department ZT. ponents have to offer very generic functionality in order to be useful in many situations, while specific systems require components with very specific properties and functionality. In order to specialize generic components and to adapt them to a given situation, there are different conceivable adapta- tion strategies which have to be applied in the context of an overall system architecture. In Section 2, we first introduce an application exam- ple, namely, a large computer aided engineering applica- tion based on a three-tier architecture and a common prod- uct model. It illustrates different possibilities for the use of generic components which have to be adapted to the chosen architecture and design. Section 3 then presents a number of different adaptation strategies, like wrappers, dedicated adaptor components, and inheritance, from a more abstract point of view. Finally, in Section 4, a combination of se- lected techniques is applied to provide a solution for the graphical user interface of the application example. The conclusion contains an evaluation of the proposed solution as a trade-off between potential benefits and necessary ef- forts as well as an outlook to other, more advanced uses of adaptation strategies. 2 Application Example: An Engineering Sys- tem In today’s engineering, many experts of different areas collaborate to work on a given project. The necessary co- ordination of the distributed work and communication be- tween the involved parties is supported by dedicated soft- ware systems. They offer a set of general technical services, like version and access control for project documents, and a set of specific business-oriented services for tasks like sim- ulation, product model validation, and visualization. Ex- amples for such systems arise in various engineering dis- ciplines, from CAE platforms [Ste97, ATL] to CASE tools [BRS98]. Because of the distributed usage of these systems, they are usually organized according to a three-tier architec- ture [Den91, BMR 96] as shown in Figure 1.