Using Role Components to Implement Collaboration-Based Designs Michael VanHilst and David Notkin Department of Computer Science and Engineering University of Washington PO Box 352350 Seattle, Washington 98195-2350 USA {vanhilst,notkin}@cs.washington.edu Abstract In this paper we present a method of code imple- mentation that works in conjunction with collab- oration and responsibility based analysis model- ing techniques to achieve better code reuse and resilience to change. Our approach maintains a closer mapping from responsibilities in the analy- sis model to entities in the implementation. In so doing, it leverages the features of flexible design and design reuse found in collaboration-based de- sign models to provide similar adaptability and reuse in the implementation. Our approach re- quires no special development tools and uses only standard features available in the C++ language. In an earlier paper we described the basic mech- anisms used by our approach and discussed its advantages in comparison to the framework ap- proach. In this paper we show how our approach combines code and design reuse, describing spe- cific techniques that can be used in the develop- ment of larger applications. 1 Introduction The notion of collaborations is well accepted in object-oriented design. In collaborations, groups of objects cooperate to perform a task or to main- tain an invariant. In the collaboration view, a role is the part of an object that fulfills its responsibil- ities in the collaboration. In most design method- ologies, roles are an ephemeral concept, existing Permission to make digital/hard copy of part or all of this work for personal Or C!~SrOom Use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication and its date appear, and notice is given that COPYing iS by permission of ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. OOPSLA ‘96 CA, USA 0 1996 ACM O-89791 -788-x/96/001 0...$3.50 briefly, if at all, between the description of collab- orations and the specification of classes. They do not generally exist as identifiable components of the implementation. In our approach to object-oriented implementa- tion, roles are an important key to code reuse and adaptation. Compared to classes, roles encapsu- late fewer decisions and are thus more stable with respect to evolution. We provide a method to im- plement roles as source code entities-specifically, class templates defined in a stylized way-and compose them into classes using separate spec- ification statements-classes defined in terms of instantiations of those class templates. Our ap- proach improves code reuse and adaptability, and overcomes a number of other limitations found in more traditional approaches to implementation. In this paper we demonstrate how a design that originates with a collaboration-based methodol- ogy can be implemented directly using role com- ponents. In the second section we describe collaborations and roles more fully and discuss their significance in object-oriented design. In the third section, we present the basic details of our method of imple- menting roles as source code components.r In the fourth section we describe the design of a con- tainer recycling machine similar to the one pre- sented in Jacobson, et al. [ll]. In the fifth section, we show how to implement that design using role components. The sixth section discusses some of the differences between our implementation and ‘A lengthier discussion of the details is available in an earlier paper, in which we compared our approach to the use of frameworks [17]. 359the implementation presented by Jacobson, et al., with respect to possible changes. We also describe some of our experiences with a much larger ap- plication, a telescope imaging system. The sev- enth section contains a discussion of related work, while the last section contains a concluding sum- mary. 2 Collaborations, Roles, and Collaboration-based Designs A collaboration is a set of objects together with obligations on and relationships among those ob- jects. Collaborations are often used to model se- quences of message passing and state changes de- rived from use-case-like scenarios in the require- ments analysis. In so doing, collaborations offer a view that complements the static view of class and inheritance structures. Collaborations are of- ten informal [2, 3, 11, 201, but they have also been formalized in contracts [lo], given a nota- tion [14, 151, and associated with framework im- plementations [7, 131. A collaboration can address only the parts of objects needed to participate in a particular task, concern, or pattern. In this view of collabora- tions, a role specifies a part of a single object that participates in a particular collaboration. Collab- orations may be seen, then, not so much as collec- tions of objects, but as collections of roles.2 An object participates in a collaboration by having a role in that collaboration. An object that participates in several collab- orations may have several roles, one from each of the collaborations. The relationship between objects and roles has a number of significant fea- tures. Just as a collaboration may be viewed as a collection of roles, an object, or its class, may also be viewed as a collection of roles. So, a role is a unit of design common to both views. Any object that has the proper role may play that role in a collaboration. Thus the same spec- ‘Some methodologies make a distinction between col- laborations of objects and collaborations of roles. Where that