Tailorable Component Architectures for CSCW-Systems - CiteSeerX

Tailorable Component Architectures for CSCW-Systems Oliver Stiemerling and Armin B. Cremers University of Bonn Department of Computer Science III Research Group HCI and CSCW (ProSEC) Römerstraße 164 53117 Bonn Germany {os,abc}@uran.informatik.uni-bonn.de Abstract Tailorability is generally regarded as a key property of CSCW-systems, because cooperative activities provide for very dynamic and diversified requirements. Extensive tailorability has to be supported by the design of the system architecture. In this contribution we investigate the value of component architectures for this purpose and discuss several design options for the questions raised by this approach. We propose a model of a component architecture, which supports tailoring activities by changing parameter settings of single components, changing the composition of components, and changing the implementation of components. Hierarchical composition of components allows for tailoring operations on different levels of abstraction and complexity. We introduce the concepts of tailoring constraints, tailoring constructs, and tailoring rights, which allow a controlled evolution of the system. Finally, we show how our approach can be employed to design a tailorable application.

1. Introduction In the CSCW literature tailorability is identified as a key requirement for groupware systems. (see e.g. [2], [7], [17]). While tailorability is also an issue outside the scope of CSCW, the special demands of cooperative work support make it a critical issue in the design of groupware applications. Complexity, dynamics, and inter- and intraindividual differences constitute the need for system designs, which can evolve over time, exhibit different behavior in different usage situations, and accommodate individual or group needs and preferences. Thus, tailoring of groupware applications raises several questions, which in the mainstream adaptability discussion are not (and do not have to be) addressed – at least not to

the degree necessary in CSCW. Since this paper focuses on architectural concerns, we will only address these issues, which have implications on or can be supported by the architectural design of the system. The system architecture should allow tailoring activities at different (and appropriate) levels of abstraction and complexity, as these activities may be performed by endusers, system-administrators or third-party consultants, each having different skills and taking different roles in the respective organization. Important for groupware are requirements concerning run-time tailoring-activities (e.g. extension of functionality without having to shut down the whole system), flexibly definable scopes (e.g. limiting the effect of tailoring activities in order to accommodate group and individual differences), tailoring rights, and the balance between centralized and distributed control. In this paper we want to investigate how component architectures can be employed to support a high degree of tailorability in groupware applications and pinpoint issues, which have to be addressed in the design of such systems. The rest of the paper consists of five parts. The first part deals with tailorability in general, describing the notions of tailorability and adaptability and modeling an adaptable system architecture on a conceptual level as a reflective computational system. From this model we derive some general questions which have to be addressed in the design of an adaptable architecture supporting tailorability. The second part gives a short overview over the component paradigm. The third part merges the concepts described in part one and two, outlining a highly tailorable component architecture for CSCW systems. We discuss a possible theoretical foundation of such an architecture, groupware-relevant control mechanisms like tailoring constraints and tailoring rights, and the aspect of appropriate decomposition. Then we present a simple example applying our concepts to a specific tailoring problem. Finally, we summarize the main ideas presented in this paper and give a short overview of further work.

2. Tailorable software systems A tailorable software system can be defined as a system, which can be appropriately adapted to changing or diversified requirements. The term "appropriately" indicates that, in our understanding, the notion of tailorability reaches beyond the purely technical, encompassing the question of user interfaces for adaptations, the embedding of tailoring tasks in the organizational context, and the support of tailoring as a collaborative activity. In the following we will refer to adaptability1 if we concentrate on technical issues, and to tailorability if we want to take a more "holistic" view. In our work, we attempt to reconcile the technical question of making a software system as adaptable as possible with the user-oriented question of making the process of tailoring as easy and quick as possible. This dilemma can easily be seen in the following examples: a software system written in C++ can, on one hand, obviously be adapted to different requirements by rewriting and recompiling the source-code. However, no one (but programmers) will consider this process especially easy or quick. An email-system, on the other hand, which allows the end-user to switch between an expert and novice level by means of a simple check box, can quickly be tailored, while - at the same time - limiting the range to only two options. The examples show that in the design of tailorability an increase in adaptability usually involves an increase in interface complexity. Thus, an important question in the design of tailorable applications concerns which aspects of the system can be rigid and which should be adaptable2. This question can only be answered empirically during the design process and with extensive user involvement. [23] discuss the use of heuristic user selection schemes in combination with evolutionary and participatory design techniques for the purpose of eliciting the necessary range of adaptability during requirements analysis. Determining the adaptable aspects of an application and the necessary range of adaptability is certainly a non-trivial exercise and much work still has to be done. In this paper, however, we want to focus on software architectures which support tailorability. Our work aims at providing a generic adaptable architecture, which takes into account the more user- and context-oriented concerns of tailorability. 1 This terminology somewhat deviates from the usage of the term adaptability in parts of the current literature, where adaptability is used to describe systems which can be changed by users as opposed to changes made by the system itself (adaptive systems, compare e.g. [13]). In our understanding a system first has to offer the opportunity to be adapted (adaptability) on a technical level, before we can decide whether we lay the task of adapting in the hands of an intelligent system component (adaptivity), or in the hands of the users (or both, in a hybrid approach). 2 The division in rigid and adaptable aspects of a software systems somewhat simplifies the issue. More realistically, the need for adaptability varies over a continuous range (see [18]).

First, we want to discuss the technical issue of adaptability of software architectures. On a very abstract level one could say, an adaptable application has to include a representation of aspects of itself. This selfrepresentation needs to be manipulatable and causally connected to the represented aspects, i.e. if the representation changes, the application changes as well. Regard, for example, an application with an initialization file, which determines the color of the application background. In this case the initialization file is the selfrepresentation, the color of the background is the adaptable aspect of the system, and the evaluation of initialization file provides the causal connection (at system start-up time). The user interface for the manipulation of the self-representation is in this case either a multi-purpose editor or a special program (perhaps in form of an optionwindow within the application). A system containing a causally connected selfrepresentation is called a reflective computational system3 (see [15] and figure 1). The notion of computational reflection – even though stemming from the area of programming language design – can be employed to clarify some issues concerning adaptability.

(partial) self-representation of the system

adaptable system adaptable aspects of the system causally connected self-representation of the system, which determines ( ) the state of the adaptable aspects. It is subject to manipulations ( ) from inside or outside the system.

Figure 1: An adaptable software system as a reflective computational system

Viewing an adaptable software system as a (partially) reflective computational system we have identified three issues determining the tailorability of an application: Choice of self-representation. This issue reflects the question formulated above concerning the rigid and adaptable parts of the system. Only aspects which are in some way included in the self-representation of the system can be subject to tailoring activities. We believe that an important property of this self-representation in complex systems is its accessibility on different conceptual levels of complexity and from different points of view. While experienced users or system administrators might have an interest to pursue more extensive – and thus complex – tailoring activities, novice users might want to access the 3 [4] points out the relevance of reflective architectures for the design of tailorable CSCW-applications

self-representation at a level closer to the application domain. Accessibility from different points of view allows to focus on specific aspects of the system leaving out irrelevant dimension. In this context, [5] describes the notion of system “accountability” achieved by causally connected reflective self-representations of system aspects. Choice of causal connection. This issue mainly concerns the point in time when changes made to the selfrepresentation take effect. There is a spectrum of possible alternatives. If the self-representation is interpreted during run-time (similar to interpreted programming or script languages), changes become effective immediately. The other extreme are compiled representations, in which changes only have an effect, if the representation is recompiled (see C++ compiler example above). The choice of causal connection usually involves a trade-off between speed of changes’ availability and efficiency of implementation. Choice of manipulation functionality. Tailorability as understood by the author implies that the selfrepresentation is changed by the users, administrators, or other stakeholders in the system. Manipulation functionality is thus mainly concerned with presenting the current state of the self-representation to the user and offering manipulation commands. Further support may be envisaged offering functionality, which intelligently suggests or implements changes. [13] describe several levels or steps (initiative, suggestion, decision, implementation) of such system support for tailorability. In its most drastic form – adaptivity or self-adaptability – the user is completely removed from all steps of the tailoring process. Such a system could – according to our understanding of tailorability – hardly be classified as tailorable. In the context of groupware systems one might envisage CSCW-support for tailoring activities, e.g. at the decision or suggestion stage. In the rest of the paper we want to look at component architectures from the viewpoint of architectural tailorability support. In the next section we describe the notion of component architectures. In the section after the next, we will discuss, how component architectures can be employed to support tailorability.

We say that a system built from components has a component architecture. On the component level such a system can be described using an appropriate composition language (see [22]). The possible form of the composition language depends on the underlying component model. In this paper we do not want to focus on a specific component model or composition language. Our discussion, however, is based on the assumption that a composition language offers constructs to describe the bindings between components (composition) and parameter settings of single components. Advantages which component oriented software engineering hopes to provide include facilitation of reuse (especially by third parties), speed-up of development processes, reduction of development costs, and higher quality (standard components are less prone to exhibit errors if they have already been used and tested in prior projects). Components have been successfully employed to support the design of graphical user interfaces. Application builders like MICROSOFT VISUAL BASIC (component model: VBX, OCX, see [19]) or LOTUS BEANMACHINE (component model: JavaBeans, see [10]) provide often used generic visual design elements (e.g. buttons, textboxes, combo-boxes), which are configured and composed during the design process to yield domain-specific applications. The notion of components, however, has been applied to areas of software engineering other than GUI-design, as well. Formal component models and composition languages have been employed to describe the architecture of complex (even distributed) systems (see e.g. WRIGHT described in [1], or DARWIN described in [16]). An advantage of viewing complex systems as compositions of components is that one can reason about the system on a high level (high in the sense of conceptually close to the application domain, or further away from implementation details). The level depends on the granularity of the components employed. The current discussion, however, exploits this advantage mostly in the design process. In this contribution we want to investigate how component architectures can be employed for the support of system adaptation during the use of the system.

3. Component architectures Component oriented programming (see [25]) is motivated by the successes classical engineering disciplines like electronics or mechanical engineering have had with building complex artifacts from standardized components (e.g. transistors, resistors, cogs, or screws). Taking into account this motivation, a software component can be defined as “a unit of composition with contractually specified interfaces and explicit context dependencies only. Components can be deployed independently and are subject to composition by third parties.” ([25], p. 130).

4. Tailorability and component architectures for CSCW In this section we outline how a tailorable component architecture might look like, taking into account requirements relevant for CSCW-systems. The component view of an application's architecture induces three classes or levels of generic (in the sense of domain-independent) transformations which are supported by component architectures: changing parameters of

single components, changing the composition of components, and changing the implementation of a component. In order to support such transformations on one of the levels during the use of an application, the description of the application on the respective level has to be included in the self-representation of the system. Additionally, the choice concerning the mode of causal connection has to be made for every level, i.e. whether the self-representation is evaluated during run-time (interpreted) or before (e.g. at start-up-time). In the following we want to describe design issues and options for tailorability on the three levels of component architectures, taking into account the requirements for tailorability in groupware stated in the introduction.

4.1 Tailoring by changing parameters of single components Tailoring on this levels aims at adapting the behavior of single components to changing requirements. The component offers a set of different behavioral alternatives and the choice concerning the appropriate behavior is specified employing a simple parameter representing an element of the set of alternatives. A component of the user interface, for example, might offer a variety of background colors to choose from during tailoring While tailoring with simple parameters is also used for adapting classical monolithic applications, the concept of component architectures allows to make explicit the limitation of the scope of the tailoring activity to a certain part (i.e. component) of the system. Users or other parts of the system which do not rely on the tailored component are not affected by the adaptation.

4.2 Tailoring by changing the composition of components Tailoring of single components as described above usually limits the range of possible tailoring options to a predefined set of anticipated alternatives determined by the range of parameters, respectively the expressiveness of the rule language. Changing the composition of components, however, allows to take into account unanticipated requirements by changing the structure of the application (e.g. reconfiguring the composition of already existing components) and adding new functionality in form of new components to the system. [24] has shown how compositional techniques can be employed to implement tailorability in CSCW-systems. Her approach uses the mediator design pattern ([6]) to allow flexible extension of functionality of CSCW-object (e.g. shared workspaces). CSCW-functionality (e.g. awareness, access control, convention control) is encapsulated in so-called Enabler-objects which are

flexibly connected to the shared workspace object via the mediator object. The user doing the tailoring can simply select the functionality he wants and add it to the respective shared workspace. Netscape Plug-Ins and Microsoft Word Plug-Ins are a similar examples for successful implementations of the compositional paradigm to achieve tailorability. The examples described above, however, only allow to make use of compositional techniques at selective points of the architecture and only at one level of abstraction. We believe that a consequent realization of a scaleable (in the sense of hierarchically definable) component architecture allows for a much higher degree of flexibility than a selective implementation of compositional flexibility. In order to achieve such a systematic realization several issues have to be addressed: First, as formal foundation of such an architecture we need a composition language which allows the (hierarchical) description of the application at the composition level. Based on this language one can define a number of transformations (e.g. exchange of one component, “rewiring” of components, or addition of new components) which allow to describe the effect of tailoring operations on this level in a precise way. Additionally, the composition language should contain constructs to specify the parameter settings of single components, thus integrating the single-component-level of tailoring (see above) into our formal foundation. The design of the composition language is informed by results from the theoretical study of communicating processes. [3], for example, show that 2-way communication interfaces are sufficient for implementing n-way synchronization. The notion of bisimilarity (see [20]) could serve as foundation for a component- and interaction-type system. Secondly, we have to be aware that total flexibility is not necessarily a desirable goal, especially so in CSCW where several users might – potentially – be affected by a tailoring operation. Thus, it should be possible to control the evolution of the application. There are several design options for such control mechanisms: - Tailoring constraints, which limit the evolution of the artifact in a way that either certain application states (static constraints) or certain application transformations are not allowed (transitional constraints). Tailoring constraints might be applied to aspects of the system which have to remain rigid or standardized in order to make co-operation possible (e.g. network protocol choices, naming conventions) - Tailorability constructs, which explicitly mark the flexible part of the application in its composition language description. This more conservative approach can be regarded as the opposite to tailoring constraints, allowing tailorability only where explicitly declared. On a technical level, tailoring constructs might take the form of additional

components, which control the adaptability of certain aspects of the application, e.g. provide a list of alternatives, a link to an option-server, etc. - Tailoring rights allow for a very differentiated model of the distribution of tailoring activities in an organization. The IT department, for example, might be granted total control of the evolution of the system, while most users may only perform very limited tailoring operations (e.g. changing the labeling of buttons). An implementation might offer a combination of tailoring constraints and tailoring rights with the former defining the basic rigidity of the system (e.g. network protocols, naming conventions) and the latter being responsible for fine-controlling the distributed evolution of the application. Third, if implementing a specific application with the proposed component architecture, the central challenge is to find an appropriate decomposition of the application into components. Concerning tailorability, the chosen decomposition should reflect the results of the design process with respect to the necessary range of flexibility (see [23]). The set of components in the resulting framework constitutes the basic "vocabulary" at the composition level and thus is the primary determinant for the range of flexibility provided by the component architecture approach. [9] discuss decomposition of CSCW functionality on a descriptive level.

system to search for documents (e.g. Microsoft Word documents). In several workshops the POLITeam-users voiced very diverse opinions about how the search-tool is supposed to present results and how the privacy of document-owners can be protected by limiting the possible search space of the tool. Another important issue was the handling of search results. Some users preferred a link (a basic POLITeam concept supporting cooperation concerning documents) to the found documents, while others wanted to create a copy of it. It became obvious that there was no one-best-way solution to the design problems, thus the search-tool constitutes an excellent example for the application of the tailoring concepts presented in this paper. See [11] and [23] for a detailed description of the design problem. We have implemented the tailorable search tool using the JavaBeans component model (see [10]). The search tool "component language" consists of the four atomic components shown in Figure 2. For the purpose of this paper we have simplified the example a little. In reality, the search engine (first component in Figure 2) is a complex component encompassing visible components for the specification of the search and invisible components for database and groupware connectivity.

4.3 Tailoring by changing or extending the implementation of components Assuming components on the lowest level of abstraction (i.e. atomic with respect to hierarchical decomposition) are objects defined in an object-oriented programming language, one can envisage different ways to change or extend the implementation of the components, e.g. overriding as in Java or extending as with the INNERconstruct in the Beta Programming Language (see [14] and [21]). These tailoring operations, however, lie at one outermost end of our notion of tailorability. Their particularities depend more on the design of the programming language than on component architectures and are therefore not the focus of this paper.

Figure 2: Four atomic components for the search tool application

The gray ports denote input, the white ports output. The shape of the port specifies the type of input or output. In this simple example we only have oval control ports (transmitting and receiving action events like mouse clicks on a control button) and rectangular data ports. The semantics of the components are best understood by regarding the simple example in Figure 3.

5. Application example In this section we describe the application of the concepts described in this paper to a specific tailoring problem. The example is taken from the context of the POLITeam-project which is concerned with providing electronic support for the work of the distributed German government in Bonn and Berlin (see [12]). The example application is the search tool employed in the POLITeam-

Figure 3: Simple search tool example

The search engine is triggered by a control button. The search results are fed into a switch, which is parameterized to channel all documents found on one’s own virtual desktop into the upper result list, while documents found elsewhere are displayed in the lower result list (the parameterization of result switches, buttons, and the search engine is not shown here). In this example the user can only create a link to a found document (port L in each result list). The result list component also offers control port C, which allows creating a copy. We found that from this simple set of components one can build any search tool required by the POLITeam users during our workshops. The more complex example in Figure 4 shows how the design of the search tool benefits from the concept of complex, hierarchical components. While still based on the four basic components the search tool can now be regarded on an abstract level as being composed of a search component A and a display component B, yielding the "root" or system component S. A system administrator now might design several alternative display components B1 to Bn, which the end users can choose from, without actually having to know about "low level" components like the search engine and the result switch. However, the design activity is still based on the same compositional technique. The only difference lies in the level of abstraction and complexity.

Figure 4: Hierarchically structured search tool with search component A and display component B

If a users, who has so far only tailored at the level of search and display components, desires to design a new display component, he does not have to learn a completely new language, only three new "words": the result switch component, the result list, and the control button component, the latter two of which he is already familiar with, because they are visible during regular use of the search tool. How can the concepts of tailoring constraints, tailoring rights and tailoring constructs be applied to this example?

Tailoring constraints could be used to state certain sensible invariants of the search tool. It would, for example, make no sense not to connect the search engine to a result list. Thus, a possible invariant would be: the search engine has to be connected to at least one result list (directly or indirectly via switches). Tailoring constructs could be used to explicitly allow the user to exchange the display component B, providing a simple interface displaying a list of administrator-defined alternatives. In this case the user action would be as simple as parameterization, while taking effect on the more complex architecture level of composition (for a usercentered taxonomy of tailoring complexity, see [8]). Tailoring rights could be applied to ensure that end users can only compose search tools which search one’s own virtual desktop. This can be achieved by attaching access rights to the respective search parameter in the search engine, allowing only system administrators to change it. We will use the prototype to experiment with different methods to control the evolution of component-based applications.

6. Summary and further work In this paper we have outlined how the paradigm of component oriented programming can be employed to design highly tailorable architectures for CSCW-systems. Our proposed component architecture allows for tailorability on three levels: tailoring single components by changing parameter settings, tailoring by changing the composition of components, and tailoring by changing the implementation of components. We have suggested to base the architecture on a formally defined composition language, which allows to reason about tailoring operations on different levels of abstraction in a precise and meaningful way. In order to support controlled system evolution, we have introduced the notion of tailoring constraints, tailoring constructs and tailoring rights. We have discussed implementation issues concerning appropriate decomposition. Finally, we have shown, how the concepts described in this paper can be applied to a specific example application, the search tool in the POLITeam project. At this point of our work, we are fairly certain that the component paradigm is a solid foundation for highly tailorable architectures, which can deal with dynamically changing and diversified requirements as encountered in the field of CSCW and also support different mechanism for evolution control. In order to further investigate this approach, we plan to employ a formal composition language. The next step of our work will be the empirical investigation of the applicability of our approach to different areas of system design. From these experiences

we hope to derive a set of domain-independent transformations on the different levels of a component architecture. Using the composition language as formal foundation we will be able to specify these transformations precisely. We hope that our approach will lead to a better understanding of how to design complex systems, which have to cope with dynamically changing and diversified requirements.

[13]

[14]

Bibliography [1]

Allen, R. and Garlan, D., “Formalizing Architectural Connection”, in: Proceedings of 16th International Conference on Software Engineering. Sorrento, Italy, 1994. [2] Bentley, R. and Dourish, P., “Medium versus Mechanism: Supporting Collaboration through Customisation”, in: Proceedings of ECSCW 95, H. Marmolin, Y. Sundblad, and K. Schmidt, Eds. Stockholm, Sweden: Kluwer, 1995, pp. 133-148. [3] Cremers, A. B. and Hibbard, T. N., “Subspaces: Factorization and Communication”, in: Proceedings of Computational And Combinatorial Methods in Systems Theory, C. I. Byrnes and A. Lindquist, Eds. Stockholm, Sweden: Elsevier Science Publishers B.V. (NorthHolland), 1986, pp. 383-396. [4] Dourish, P., “Designing for Change: Reflective Metalevel Architectures for Deep Customisation in CSCW,” Rank Xerox Research Centre, Cambridge Laboratory, UK, Research Report EPC-1993-102, 1993. [5] Dourish, P., “Accounting for System Behaviour: Representation, Reflection and Resourceful Action,” Rank Xerox Research Centre, Cambridge Laboratory, UK, Research Report EPC-1995-101, 1995. [6] Gamma, E.,Helm, R.,Johnson, R., and Vlissides, J., Design Patterns: Elements of Reusable Object-Oriented Software: Addison-Wesley Publishing Company, 1995. [7] Greenberg, S., “Personalizable groupware: accommodating individual roles and group differences”, in: Proceedings of ECSCW ’91. Amsterdam, The Netherlands, 1991, pp. 1731. [8] Henderson, A. and Kyng, M., “There's No Place Like Home: Continuing Design in Use,” in Design At Work, J. Greenbaum and M. Kyng, Eds. Hillsdale, New Jersey: Lawrence Erlbaum Associates, Publishers, 1991, pp. 219240. [9] Hofte, G. H. t.,Lugt, H. J. v. d., and Houtsma, M. A. W., “Co4: A Comprehensive Model of Groupware Functionality”, in: Proceedings . APTEC Conference of Euromedia, 1996. [10] JavaSoft, “JavaBeans 1.0 API Specification”, . Mountain View, California: SUN Microsystems, 1997. [11] Kahler, H., “Developing Groupware with Evolution and Participation”, in: Proceedings of PDC ’96 (Participatory Design Conference). Boston, MA, USA, 1996, pp. 173182. [12] Klöckner, K.,Mambrey, P.,Solenkamp, M.,Prinz, W.,Fuchs, L.,Kolvenbach, S.,Pankoke-Babatz, U., and

[15] [16]

[17]

[18]

[19] [20]

[21]

[22]

[23]

[24]

[25]

Syri, A., “POLITeam --- Bridging the Gap between Bonn and Berlin for and with the Users”, in: Proceedings of ECSCW ’95, H. Marmolin, Y. Sundblad, and K. Schmidt, Eds. Stockholm, Sweden: Kluwer, 1995, pp. 17-32. Kühme, T.,Dieterich, H.,Malinowski, U., and SchneiderHufschmidt, M., “Approaches to Adaptivity in User Interface Technology: Survey and Taxonomy”, in: Proceedings of IFIP ’92, 1992. Madsen, O. L.,Møller-Pedersen, B., and Nygaard, K., Object-Oriented Programming in the Beta Programming Language: Addison-Wesley Publishing Company, 1993. Maes, P., “Computational Reflection,” University of Bruessels, Bruessels, Research Report 87.2, 1987. Magee, J.,Dulay, N.,Eisenbach, S., and Kramer, J., “Specifying Distributed Software Architectures”, in: Proceedings of 5th European Software Engineering Conference. Barcelona, 1995. Malone, T. W.,Lai, K.-Y., and Fry, C., “Experiments with Oval: A Radically Tailorable Tool for Cooperative Work”, in: Proceedings of ICSCW. Toronto, Canada: ACM Press, 1992, pp. 289-297. Mens, K.,Steyaert, P., and Lucas, C., “Reuse Contracts: Managing Evolution in Adaptable Systems,” Special Issues in Object-Oriented Programming: Workshop Reader of the 10th European Conference on Object-Oriented Programming ECOOP ’96, Linz, pp. 37 42, 1996. Microsoft, “Visual Basic”, , 4.0 ed, 1996. Milner, R.,Parrow, J., and Walker, D., “A calculus of mobile processes, Parts I and II,” Journal of Information and Computing, vol. 100, pp. 1-77, 1992. Mørch, A., “Method and Tools for Tailoring of Objectoriented Applications: An Evolving Artifacts Approach”, in Department of Computer Science. Oslo: University of Oslo, 1997. Nierstrasz, O. and Meijler, T. D., “Research Directions in Software Composition,” ACM Computing Surveys, vol. 27, pp. 262-264, 1995. Stiemerling, O.,Kahler, H., and Wulf, V., “How to Make Software Softer - Designing Tailorable Applications”, in: Proceedings of DIS ’97. Amsterdam: ACM Press, 1997. Syri, A., “Tailoring Cooperation Support through Mediators”, in: Proceedings of ECSCW ’97. Lancaster, 1997, pp. (to appear). Szyperski, C. and Pfister, C., “Component-Oriented Programming: WCOP '96 Workshop Report,” Special Issues in Object-Oriented Programming: Workshop Reader of the 10th ECOOP ’96, Linz, pp. 127-130, 1996.