Comparison of Object-Oriented Approaches for Roles in Programming Languages Daniel Chernuchin, Oliver S. Lazar and Gisbert Dittrich University of Dortmund Abstract the techniques in the area of the statically typed languages like Java and C++. None of the approaches has until now This paper presents, explores and compares object-oriented approaches for roles in statically typed programming lan- become standard. guages. We choose five solutions which support informa- This paper is a compendium of (Lazar 2005). tion hiding. On the one hand, we investigate the estab- In the next section we discuss the related work in the lished object-oriented possibilities multiple and interface in- object-oriented area. Then we introduce criteria of com- heritance and the role object pattern, on the other hand, we parison of approaches and present an example of an appli- examine the language extensions Object Teams and the syn- cation for role investigations. In the following sections we tactical extension of classes with roles. We discuss all ap- consider the approaches multiple and interface inheritance, proaches in turn, using a versatile example. role object pattern, Object Teams and roles as components of The investigation shows that standard approaches interface classes. The last section presents results and the conclusion inheritance and role object pattern are more appropriate for of our comparison. enterprise projects. New approaches are not developed far enough to be used widespread. But they are all promising proceedings, particularly the approach of roles as components Related Work of classes. The definitions of the term role are various. They vary from the observable (Steimann 2001), perspective-dependent be- Motivation havior of objects (Mezini 1998), to a certain part of sub- jective behavior (Kristensen 2001). In this paper we con- Object-oriented development is standard today. One of the sider natural types which relate to the essence of the objects. most important reasons is the comprehensibility of models Roles, which appear in specific perspectives, are called role and codes. This comprehensibility stems from transferring types (Sowa 1984). A context is an expedient collaboration aspects of the real world to programming languages. In this of several roles and classes. way classes, objects, methods, inheritance and templates are An extensive object in a computational system often com- originated. An aspect of the real world is the possibility that pletes its tasks while crosscutting a certain amount of vari- an object appears in different roles. In object-oriented de- ous contexts. Such an object can be reclassified in subunits velopment roles are visible properties of an object (Riehle corresponding to contexts. Hence, in each context an object 2000). An object may play different roles simultaneously. It provides a specific role. can be viewed from different perspectives, so that different In this article we can not explore all approaches for roles, properties appear. we have chosen only five representatives which support in- Advantages of object-oriented languages are informa- formation hiding well. Now we shortly discuss some other tion hiding and encapsulation. Functionality and proper- related work. ties are organized in classes on different abstraction levels B. B. Kristensen and K. Østerbye describe a conceptual and clients can only access the information on the permit- model for roles (Kristensen & Østerbye 1996). They dis- ted level. A role concept should improve information hiding tinguish between intrinsic and extrinsic properties of ob- and encapsulation. jects. Another approach is Object-Oriented Role Analysis The research of roles in the object-oriented area is exten- and Modelling (Andersen 1997). In an OOram role model, sive. But the definitions, modelling ways, examples and tar- patterns of interacting objects are abstracted into a corre- gets are often different (Steimann 2000). We pick out five sponding pattern of interacting roles (Reenskaug, Wold, & approaches which all support a high level of information Lehne 1995). There are also class libraries developed for hiding. These approaches allow the programmer only to ac- Smalltalk and Java to handle with roles (Gottlob, Schrefl, & cess relevant role properties. In our opinion, it is one of the Roeck 1996; Schrefl & Thalhammer 2002). most important features by dealing with roles. We explore Aspect-oriented approaches for role modelling facilitate Copyright c 2005, American Association for Artificial Intelli- further modularisation. Aspect-oriented programming has gence (www.aaai.org). All rights reserved. been controversially discussed in this context. On the one hand, it is described as a promising approach for role mod- tial roles and the substitution of method contents depend- els (Kendall 1999), on the other hand, in (Hanenberg & Un- ing on the current context. land 2002) the conclusion is drawn that roles and aspects are 4. Identity sharing: The object and its roles are seen and too different. (Hanenberg, Stein, & Unland 2005) even sug- can be manipulated as one entity. gest that role programming is a special case of the aspect- oriented programming. Object Teams (Herrmann 2002b), 5. Several same roles: An object may play the same role Chameleon (Graversen & Beyer 2002) and EpsilonJ (Tamai several times. 2005) are aspect-oriented approaches which syntactically A not explicitly named criterion is information hiding. define roles. In our comparison we take Object Teams as When being addressed in a certain role, features of other a representative of the aspect-oriented approaches. roles of the object remain invisible. All investigated ap- One goal of using roles is to make possible that several proaches support information hiding. teams of developers work independently from each other on Another not explicitly named criterion is hierarchy of role a software project. This idea was suggested by (Ossher et and natural types. As information hiding it is fulfilled in al. 1995; 1996) as subject-oriented programming. With every investigated approach. subject-oriented programming the denotation of a method The following list shows general properties: invocation for a given object is said to be subjective if dif- 1. Closeness to the object model: This criterion evaluates ferent method interpretations can result (Kristensen 2001). how far an approach is geared to the object-oriented par- Those interpretations depend on the current role of an ob- adigm. ject. That is whenever we speak about programming of roles we speak about subject-oriented programming. The 2. Maintainability and extensibility: This criterion exam- five presented approaches deal with subjective views. The ines how far the modelling and implementation of an ap- main projects of the subject-oriented community deal with plication or a module is maintainable and extensible. aspect oriented programming. There are Hyper/J (Thang 3. Comprehensibility: This criterion judges the compre- & Katayama 2002) and Concern Manipulation Environment hensibility of models and codes. Furthermore, the close- (Harrison, Ossher, & Tarr 2004). ness of modelling roles and the corresponding code will Further role approaches are variational-oriented program- be evaluated. From our point of view this criterion is the ming (Mezini 1998) and Templates (VanHilst & Notkin most important. 1996). The information hiding is not their main focus. M. 4. Documentation: This criterion evaluates the documenta- Mezini handles with incremental behavior variations in dy- tion of an approach concerning roles. namic typed languages. M. VanHilst and D. Notkin work on the composition of roles to classes by means of inheri- 5. Progress of development: This criterion evaluates the tance and templates. The solution of the diamond problem quality and the amount of supporting tools and how far the is given by the inheritance order. The information hiding is progress of development is sophisticated. Moreover, the not given, because a role can access properties of other roles. support for graphical modelling is considered e.g. UML. An overview of several role approaches can be find in There are correlations between the criteria. For example (Baumgart 2003; Steimann 2000). comprehensibility strongly depends on the closeness to the object model. Criteria of comparison We need criteria for the comparison of the approaches. We Example distinguish between features and general properties of the We illustrate all approaches using a versatile example de- approaches. The properties of roles in (Kristensen 1996; veloped for this purpose. The following example is a part Steimann 2000) form the basis for our research. of a hospital information system (HIS). As there is no stan- We consider the following feature criteria: dard method for graphically modelling roles in a computa- 1. Encapsulation: This is a distribution of information so tional system (Steimann 2001), we suggest using a modi- that relevant information to one subject stands together fied UML-classdiagram as shown in figure 1. For a better in pieces of code of appropriate size separated from non- general survey all get- and set-methods have been masked relevant information. out. Mapping roles into discrete classes is not a compulsory presetting for the approaches. This is just one possible al- 2. Dependency: A role can influence another one. Hence, ternative which we have chosen to visually illustrate the ex- a role-based approach has to provide a possibility to ex- ample. The roles of Patient are marked with gray