A Radical Revision of UML s Role Concept *

Transcription

1 A Radical Revision of UML s Role oncept Fiedich Steimann nstitut fü Technische nfomatik Rechnegestützte Wissensveabeitung Univesität Hannove, Appelstaße 4, D Hannove steimann@acm.og Abstact. UML s cuent definition of the ole concept comes with many poblems, not the least being that it is difficult to undestand and communicate. This pape poposes a evised UML metamodel building on a much simple ole definition. Moeove, it eplaces the athe unusual notions of association ole and association end ole as well as the aely used association genealization with the moe popula concept of oveloading, theeby leading to a consideable eduction in the numbe of modelling concepts. Despite the athe adical natue of the poposed alteations, no changes in UML notation become necessay. Howeve, a notable change in modelling style including in paticula a cleae sepaation of stuctue and inteaction diagams ae among the likely effects of the poposed evision. 1 ntoduction UML s cuent vesion [OMG 1999] has thee diffeent definitions of the ole concept: oles as names of association ends, oles as slots in collaboations, and oles as dynamic classes. The fist two ae heitage fom the entity-elationship diagam and object-oiented methods such as OORAM [Reenskaug et al. 1996], espectively, and, as will be seen, ae mostly independent of each othe. The thid is only mentioned in passing [ , p. 3-46] and is pesumably a tibute to a view of oles commonly found in the liteatue [Steimann 1999]. Of couse thee ae vaious othe uses of the tem spead ove the UML specification, fo instance the oles of an acto in diffeent use case diagams o the oles in a state chat, but these uses ae eithe instances of one of the thee definitions listed above o meely a way of speaking. Afte all, ole is one of the most elementay tems not only in modelling (cf. sect. 5), and it is difficult, if not impossible, to get along without it. The ationale of the fist definition of the ole concept is simple: to uniquely identify it, evey end of an association (like evey place of a elationship in the entityelationship diagam) can be assigned a olename, and this end is then efeed to as a ole [ ]. The second definition, the definition of oles as slots of a collaboation, involves moe: in: E Evans, S Kent, B Selic UML 2000: Poceedings of the 3d ntenational onfeence (Spinge, 2000)

2 F. Steiman: A adical evision of UML s ole concept... while a classifie is a complete desciption of instances, a classifie ole is a desciption of the featues equied in a paticula collaboation, i.e. a classifie ole is a pojection of, o a view of, a classifie. The classifie so epesented is efeed to as the base classifie of that paticula classifie ole. [ , p ] and Each association ole epesents the usage of an association in the collaboation, and it is defined between the classifie oles that epesent the associated classifies. The epesented association is called the base association of the association ole. As the association oles specify a paticula usage of an association in a specific collaboation, all constaints expessed by the association ends ae not necessaily equied to be fulfilled in the specified usage. The multiplicity of the association end may be educed in the collaboation, i.e. the uppe and the lowe bounds of the association end oles may be lowe than those of the coesponding base association end, as it might be that only a subset of the associated instances paticipate in the collaboation instance. [ibid.] These definitions become moe tanspaent when looking at the coesponding except of UML s metamodel, as compiled fom figues 2-5, 2-6, and 2-17 of the oiginal specification (shown in figue 1). Fo the sake of conciseness, classifies othe than lass and nteface have been omitted; the complete list can be found in [Rumbaugh et al. 1999]. t must be noted, howeve, that much of UML s complexity is due to this genealization and the esultant geneicity, and that the coectness of the following and all othe agumentation citically depends on what is compised unde the classifie tem. Also notice that Associationlass, a common subclass of Association and lass, has been omitted; although a handy modelling concept, it entails cetain consistency poblems that ae not dealt with hee. 1 child genealization GenealizableElement Genealization 1 paent specialization 1.. base lassifie 1 type specification AssociationEnd name 2.. Association 0..1 base 0..1 base lass nteface 1 type lassifierole AssociationEndRole 2.. AssociationRole Figue 1: An except of the abstact syntax that foms the stuctual pat of the UML metamodel. Moe than one base fo one classifie ole may only be specified if classification is multiple. 195

3 F. Steiman: A adical evision of UML s ole concept lose inspection of the oiginal specification eveals that thee ae many poblems in association with oles. Some of them ae obvious and easily avoided. Fo instance, a classifie ole must not specify a classifie ole as its base, and association ends and association end oles must not be mixed in one association. 1 Othe things ae subtle and become appaent only when woking though the textual specification. Some of these will be discussed next. 2 Poblems 2.1 Base vs. Pojection The use of the tem base in connection with collaboation oles (as eflected in the metamodel of figue 1) suggests that the oles of a collaboation ae deived fom thei bases. And indeed, one well-fomedness ule fo association end oles states that the base classifie of the classifie ole connected to the association end ole must be the same as o a specialization 2 of the classifie connected to the association end ole s base [ , p ]: self.type.base = self.base.type o self.type.base.allpaents->includes (self.base.type) But this obsevation is supeficial. The ule only equies that the base itself, if not the same classifie, is a specialization, not that the classifie ole is a specialization of its base. Quite the contay: a ole epeats only pats of the featues of its base (the availablefeatues [ , p ]) and in case of the classifie ole, lets instances of any classifie engage in the association as long as it confoms to whateve is equied by this ole. Theefoe, the extent of the ole is bigge than that of its base, 3 and use of the tem base (eminiscent of base type/deived type) is misleading. 4 But if the classifie ole is moe geneal than its base, why is this base allowed to be a specialization of the oiginal type? Why should one fist estict the extent of a classifie ole (by selecting a specialization as its base) and then widen it (by educing the numbe of available featues)? And doesn t widening the extent conflict with the view that only a subset of the associated instances paticipate in the collaboation instance? Admittedly, it does make sense to let instances of abitay type paticipate in a collaboation as long as they do what is equied by the ole they play, but then this libety should not be limited to collaboations, since a geneal association specification may be equally pemissive. 5 1 Poblems of this kind can easily be (and some actually ae) fixed though wellfomedness ules. 2 Thoughout this text, specialization is defined as the invese of genealization. 3 Note that the semantics of the base elation diffes depending on what is being elated, because the same does not hold fo association and association end oles: thei extents ae samlle. 4 The oles ae actually also efeed to as pojections o views of thei bases (although patial specifications would seem moe adequate). 5 n fact, seveal extensions of the entity-elationship model allow ad hoc disjunctions (which ae not genealizations!) of entity types to occu in the places of elationship types [Steimann 1999]. ntefaces may seve as such ad hoc disjunctions [Steimann 2001], but this is not discussed in the UML specification. 196

4 F. Steiman: A adical evision of UML s ole concept 2.2 nteface Specifies vs. lassifie Roles n UML, each association end can specify one o moe classifies as inteface specifies (mapped to the specification pseudo-attibute, see figue 1) which ae to estict the access to the instances of the classifie acoss the association. n a way, these inteface specifies paallel the specification of base classifies with a classifie ole, but despite the symmetic stuctue of the metamodel this paallelism is unappaent. nstead, the UML specification offes vaious nebulous explanations, fo instance A ole may be static (e.g., an association end) o dynamic (e.g., a collaboation ole) in the glossay o The use of a olename and inteface specifie ae equivalent to ceating a small collaboation that includes just an association and two oles, whose stuctue is defined by the olename and attached classifie on the oiginal association. Theefoe, the oiginal association and classifies ae a use of the collaboation. The oiginal classifie must be compatible with the inteface specifie (which can be an inteface o a type, among othe kinds of classifies) in the notation guide [ , p. 3-66]. Undoubtedly, both inteface specifies of an association end and base classifies of a collaboation ole seve to specify what is equied fom the instances engaging in an association (o collaboation). Howeve, AssociationEnd genealizes AssociationEndRole, not lassifierole, and it lets the fome inheit the olename attibute. But what happened to the specification pseudo-attibute that should also be inheited fom AssociationEnd? Has it been dopped? f an association end ole in a collaboation specifies an association end as its base and this base lists inteface specifies, must the classifie ole of such an association end ole confom to these inteface specifies? And while the inteface specifies only seve to estict access, not to constain the type of the instances (this is the task of the connected type classifie), the classifie ole does both: it povides a patial specification of the classifies whose instances can play the ole, and it esticts access to the featues of this patial specification. Last but not least, while the base classifie of a classifie ole must connect to the base association of its association ole, no such constaint is imposed on the inteface specifies. Thus, the alleged symmety is eally an asymmety (and a vey confusing one at that). 2.3 Static Stuctue Diagams vs. ollaboation Diagams The duality of concepts just citicized is paalleled by a second one: that of static stuctue and collaboations. Fo an example of this, look at the diagam of figue 2a. Accoding to the UML specification it is a pefect collaboation diagam, albeit one without inteaction infomation. But whee is the collaboation? s the stuctual infomation given in figue 2a less geneally elevant than that of figue 2b, which is a class diagam? O is the existence of (classifie) oles the tue (and only) eason to declae one as a collaboation diagam and not the othe? ndeed, one might pefe to model Teache and Student as subclasses (athe than oles) of Peson 6 would this 6 admittedly a poo pefeence: oles ae no subtypes [Fiesmith & Hendeson-Selles 1998; Steimann 1999] 197

5 F. Steiman: A adical evision of UML s ole concept simple modification tun the collaboation diagam into an odinay class diagam? Hadly. Note well, the poblem hee is not that collaboation diagams expess stuctue, but that oles (othe than the olenames of association ends) ae excluded fom class diagams. Many kinds of constaints on associations (including multiplicities, exclusive os etc.) have been devised, but it is impossible to expess in a class diagam that of all pesons only teaches can be membes of a staff and give couses, even though this may vey well be a fundamental stuctual popety of a modelling poblem. n such cases, the intoduction of an exta collaboation diagam to expess stuctue (but lacking an actual inteaction) must appea atificial, as is the case fo figue 2. (a) faculty membe tuto student /Teache:Peson 1 1 lectue /Student:Peson paticipant 1 faculty :Faculty given couse :ouse taken couse (b) tuto 0..1 student Faculty faculty 0..1 faculty membe lectue 1 Peson paticipant given couse taken couse ouse Figue 2: (a) ollaboation diagam without inteaction infomation (fom [OMG 1999]) (b) coesponding class diagam (adapted fom [Övegaad 1999]) 2.4 Specification vs. nstance Level n UML, inteaction diagams ae offeed at two levels: the specification (o classifie) and the instance level [ , p ]. Howeve, inteactions (and collaboations) always take place between actual objects, not thei oles o classes, and it seems that the specification level is needed only insofa as inteactions equie o impose additional stuctue, stuctue that, because of its geneality, should indeed be expessed on the classifie level. The specification of inteaction itself howeve must be able to distinguish diffeent objects even if they play the same ole and, moe impotantly, must be able to expess that the same object plays diffeent oles in one inteaction. Such is not possible on the classifie level, and it would appea that the instance level is the natual domain fo inteaction specification. The definition of 198

6 F. Steiman: A adical evision of UML s ole concept collaboations with geneic inteaction pattens on the classifie level tends to blu this distinction, and is athe difficult to communicate. 2.5 Association Roles vs. Association Genealization As quoted above, association oles specify a paticula usage of an association in a specific collaboation in which the constaints expessed by the association ends ae not necessaily equied to be fulfilled in the specified usage [OMG 1999, , p ]. Fo instance: The multiplicity of the association end may be educed in the collaboation, i.e. the uppe and the lowe bounds of the association end oles may be lowe than those of the coesponding base association end, as it might be that only a subset of the associated instances paticipate in the collaboation instance. n othe wods: the extent of an association ole is a subset of the extent of its base association. And the UML specification continues: Similaly, an association may be tavesed in some, but pehaps not all, of the allowed diections in the specific collaboation, i.e. the isnavigable popety of an association end ole may be false even if that popety of the base association end is tue. [...] The changeability and odeing of an association end may be stengthened in an association-end ole, i.e. in a paticula usage the end is used in a moe esticted way than is defined by the association. [ , p ] But association oles ae not the only way to estict the use of an association in a UML model: as indicated by the metamodel in figue 1, associations can also be genealized. Wheeas the cuent OMG specification is vey bief about association genealization ( Genealization may be applied to associations as well as classes, although the notation may be messy because of the multiple lines. An association can be shown as an association class fo the pupose of attaching genealization aows. [OMG 1999, , p. 3-80] is the only textual mention found), othe souces go into moe detail: As with any genealization elationship, the child element [of an association genealization] must add to the intent (defining ules) of the paent and must subset the extent (set of instances) of the paent. Adding to the intent means adding additional constaints. A child association is moe constained than its paent. [Rumbaugh et al. 1999, p. 163]. But isn t disallowing navigation moe constained than leaving navigability open (that is, allowing it), and isn t being soted moe constained than not being soted (it is implied by an additional condition, that of the elements being odeed)? All in all, it seems that the semantics of association oles is lagely coveed by the specialization of thei base associations, but this duality of concepts (yet anothe one!) is neve mentioned. 2.6 ntefaces vs. lasses Fo some unappaent eason, UML doesn t make much use of intefaces. n fact, even though thee appeas to be a basic awaeness of the geneal impotance of inte- 199

7 F. Steiman: A adical evision of UML s ole concept faces, the metamodel has no dedicated use fo it (as it has, e.g., fo collaboation oles). nstead, the moe geneal lassifie (compising classes and intefaces) is consistently (ab)used to specify intefaces whee the use of the nteface concept wee in place. Fo instance, the inteface specifies of an association end may be classes, and classifie oles ae geneal classifies although thei pupose is clealy that of a patial specification and hence that of an inteface 7. 3 Revision t should be clea fom the above that UML s cuent ole concept is poblematic. The alleged symmety of association end and collaboation ole is only seeming, and paticulaly the intoduction of association oles and association end oles which shae only supeficial popeties with classifie oles (such as having bases and being slots in a collaboation) appeas to be a peculiaity of UML that is difficult to tanspot. As a matte of fact, the desciption of the connection between associations and association oles emains athe sketchy, and it may be speculated that any attempt to pin it down pecisely would lead to moe poblems. Fotunately, thee is a simple solution to all this. Roles ae no specialty of collaboations and the inteactions they enable, they ae a coe stuctual element (although not necessaily a static one). Roles ae bidges between instantiable classifies and thei associations, be it in the scope of a collaboation o outside the context of any inteaction. But oles ae no association ends (o the names theeof) a ole (moe pecisely, a ole type) is a classifie like a class, only that it does not have instances of its own. nstead, a ole ecuits its instances fom those classifies that ae declaed compatible with the ole, that is, that comply with the patial specification that makes the ole. As fo the emaining UML oles, namely the association oles and association end oles: they too ae not limited to the scope of collaboations. But unlike classifie oles, they ae ivaled by an equally suitable (an much bette undestood) concept: association oveloading. Oveloading, expessing that the same association (opeation, elation, o function) has diffeent popeties depending on the classifies (types) being associated, is ubiquitous in object-oiented pogamming as well as in the theoy of type stuctues [Bläsius et al. 1989], and it gacefully accounts fo the fact that an association in a collaboation (with only a subset of the instances involved) may have diffeent popeties than the same association outside the scope of the collaboation. At the same time, oveloading accounts fo most of the semantics of association specialization as a puely stuctual modelling element the only obvious diffeence is that a specialized association can have a diffeent name than its genealization. Note well, the suggested evision is not a plea against collaboations. ollaboations emain as an impotant means of zooming into paticula stuctual aspects of a model and as a basis fo expessing the inteactions that build upon them. The point hee is that the stuctual aspects of a collaboation can be expessed with the same modelling concepts as any classifie stuctue, be it in o outside the scope of collaboation. 7 pehaps not an inteface in the definition of UML, but that is anothe issue 200

8 F. Steiman: A adical evision of UML s ole concept Moe specifically, the evision of UML s ole concept is compised by the following fou commitments. 1. The metaclasses nteface and lassifierole ae meged into a new metaclass Role. The estictions egading intefaces in UML (that they cannot have attibutes o occu in othe places than the taget ends of diected associations) ae dopped. lass and Role ae stictly sepaated: while classes can be instantiated (unless of couse they ae abstact), oles cannot. 2. The association between classifie oles and thei base classifies is eplaced by a new elationship, named populates 8, which elates classes with the oles thei instances can play. (t is convenient to speak of a class as populating a ole and of an instance as playing a ole. t is impotant that these ae distinguished: populating oughly coesponds to the subclass elationship among classes, and playing to the instance-of elationship of an instance to its class. The diction in this egad is often ambiguous in the liteatue.) 3. Association ends ae equied to connect to oles exclusively. Because oles ae intefaces and suboles can combine seveal intefaces, both pseudo-attibutes type and specification ae eplaced by one new elationship specifies associating each association end with one ole. The classes whose instances actually paticipate in an association ae specified only indiectly via the populates elationship between classes and oles. Association ends need not be given a olename; if they ae, this name must equal the connected ole s. Evey ole must be unique within an association, i.e., no two association ends of one association must specify the same ole. 4. The metaclasses AssociationEndRole, AssociationRole, and the genealization of associations ae eplaced by association oveloading. Fo this pupose, a new metaclass, Signatue, is intoduced whose instances stand between an association and its (oveloaded) association ends. Thus, athe than giving ise to an association ole, an association esticted in the context of a collaboation specifies a new instance of Signatue, compising new association ends, each connected to a ole defined by the collaboation. The metamodel the suggested changes esult in is pesented in figue 3. Fist and foemost, it does not distinguish between coe and collaboation modelling elements: association ends ae always connected to oles, which ae always populated by classes (epesentative of all othe classifies), although a paticula diagam may choose not to show this. Second, UML s indiffeence with egad to a classifie s being a class o an inteface is lifted: intefaces, now temed oles, exclusively occu at associations ends, and classes exclusively as populating them. Last but not least, it accounts fo the fact that the same association can occu multiply in one model, each occuence disambiguated by a diffeent signatue, always involving diffeent association ends and usually also connecting to a diffeent set of oles. 8 Altenative tems fo populates would be implements o ealizes, but these ae athe technical. 201

9 F. Steiman: A adical evision of UML s ole concept genealizes lass Role populates genealizes fills AssociationEnd 2.. Signatue 1.. Association Figue 3: The evised metamodel fo UML A final note on the epesentation of genealization in figue 3. UML intoduces Genealization as an instantiable metaclass (see figue 1). n ode to avoid inconsistencies, it must be declaed fo all genealizable elements what is inheited down each genealization elationship (instance of the Genealization metaclass). The changed metamodel takes a simple appoach: it epesents genealization as an oveloaded elationship of the metamodel. Note that genealizes is of the same ode as populates 9, while all instances of Association ae of a lowe ode. This way, no pecautions avoiding inconsistencies and paadoxes need to be taken. 4 hanges fo the Modelle The good news fist: thee ae no changes of notation necessay. The definition of the new ole concept as a mege of collaboation oles and intefaces and the emphasis on the inteface aspect suggests that oles ae dawn like intefaces, i.e., as steeotyped classifies o, pefeably, as cicles. The oveloading of associations coveing both association genealization and association oles is implicitly expessed by diffeent associations with the same name (and, unde cetain conditions, may be explicated by genealization aows). All othe changes have no impact on the notation itself, only on the style diagams ae composed. 4.1 A New Style fo Stuctue Diagams The most obvious consequence of the new metamodel on diagam style is that all associations must end at oles. Thus, oles (fomely intefaces) should be seen moe fequently in class diagams, whee they function as inteface specifies esticting access to instances acoss the association, but also as patial specifications of the classes whose instances link. n fact, placing oles, not classes, at association ends means lifting the pogam to an inteface maxim (that is consideed good pactice in object-oiented pogamming [Gamma et al. 1995; D Souza & Wills 1998; Steimann 2001]) to the modelling level; it entails that instances of vaious classes can intechangeably engage in the same association as long as thei classes populate the ole specified. n a collaboation diagam at specification level, all associations aleady end at oles (fomely, classifie oles). Howeve, the classes that (by default) populate the oles, the fome base classes (if povided), ae no longe implicit pats of the ole symbols, but have to be shown explicitly. Note that oles in a collaboation diagam seve no 9 UML specifies a simila elationship of types and implementation classes: [...] types may only specialize othe types and implementation classes may only specialize othe implementation classes. Types and implementation classes can be elated only be ealization [3.27.1, p. 3-46]. But the distinction of types and implementation classes is not that of oles and classes. 202

10 F. Steiman: A adical evision of UML s ole concept diffeent pupose than oles in a (new style) class diagam: they specify the inteface (including attibutes!) that ae equied fom the collaboatos, but they do not commit the collaboation to the classes whose instances can play the ole. Figue 4 shows a collaboation diagam and a class diagam in the new style, showing stuctue, but no behaviou. Because with the new style class diagams and the stuctual aspects of collaboation diagams ely on the same modelling concepts, thee is no syntactical diffeence between the two diagam types: both show associations connecting oles and classes populating them. onsequently, the diffeence between the two can be based only on intention: dawing a sepaate collaboation diagam is useful if and only if (a) inteaction infomation is to be povided o (b) associations that ae elevant only within the scope of an actual collaboation (fomely: association oles) ae to be shown. (a) tuto student faculty membe Teache Peson Student faculty given couse taken couse lectue paticipant Faculty ouse (b) tuto student faculty paticipant taken couse faculty membe Peson ouse Faculty lectue given couse Figue 4: New style collaboation diagam (a) and class diagam (b) coesponding to the diagams of figue 2. Note that collaboation diagam diffes fom the class diagam only by the intoduction of the suboles Teache and Student. Finally, a collaboation diagam at instance level specifies behaviou by showing pototypical objects as they inteact. Although not eseved fo the instance level, it is hee that UML s lollipop notation unfolds its intuitive expessiveness: in an inteaction, objects should be accessed exclusively via the oles they play, and these oles (which ae themselves no instances) ae connected to thei playes by unlabeled lines 203

11 F. Steiman: A adical evision of UML s ole concept to expess that they ae the plugpoints between (substitutable) objects and the specified inteaction. Figue 5 gives an example of this. 1:teaches() student 1.1[i:=1..n]: lectue() paticipant taken couse 1.i.1:name() lectue given couse Figue 5: New style collaboation diagam on the instance level. All objects can, but need not, emain anonymous and lack class infomation. The lollipop notation of an object and its oles is eminiscent of the pieces of a jigsaw puzzle, which is intentional. Mapping. Mapping of the new style diagams to instances of the evised metamodel is staightfowad. Evey class maps to an instance of lass, evey ole to one of Role. Realization aows map to instances of the populates association, and genealization aows to instances of the espective genealization associations. Evey occuence of an association with the same name maps to the same instance of Association, but to a diffeent instance of Signatue with coespondingly diffeent instances of AssociationEnd. Figue 6 shows the mapping fo a simple diagam. D s a a t E :lass D:lass E:lass :Role s:role t:role :AssociationEnd :AssociationEnd :AssociationEnd :AssociationEnd :Signatue :Signatue a:association Figue 6: Mapping of a new style stuctue diagam to an instance of the evised metamodel. Association labels of the object diagam ae omitted, but can easily be econstucted fom the class diagam of figue

12 F. Steiman: A adical evision of UML s ole concept 4.2 Retaining Old Style Diagams Evey diagam of the new style is a valid UML diagam, mapping to the old as well as the evised metamodel. But thee ae even bette news: all diagams of the old style that map to instances of the old metamodel also map to the evised one. Howeve, as one may imagine, the mapping is not staightfowad, and it is moe instuctive to look at a systematic tansfomation of conventional diagams into diagams of the new style, fo which mapping is one-to-one. The outline of the mapping pocedue is as follows: Fist, it is ensued that evey association end connects to a suitable ole. Then, the classifie fomely occupying the association end is elated to that ole, eithe as populating, as specializing, o as being identical to it. Finally, in case the association is a specialization o an association ole, the necessay oveloading is declaed. Duing this pocedue it may become necessay to intoduce a (default) ole fo a class that is defined as the class s complete inteface. n these cases, the ole is given the same name as the class (only that the name is set in italics), and it is undestood that the two ae diffeent types even though they cay the same names. 10 Mapping. n class diagams of the old style classifies (mostly classes) diectly connect to association ends. Howeve, these association ends usually come with olenames. Even though these olenames ae no oles, but mee labels, they could be, and the fist step in mapping is to intoduce a ole fo evey association end with the olename as its name, and to let the classifie fomely connected to the association end populate that ole. f no olename is povided, the ole is given the class s name (the default ole), and if the classifie is an inteface, it is consideed a diect subole of the ole intoduced by the olename (if povided), o eveything is left as is (if no exta olename is povided). Figue 7 a shows the mapping fo all fou cases. Next come the inteface specifies. The inteface specifies at association ends always come with olenames, but the association ends may connect to classes o intefaces. The mapping to the new dawing style in eithe case is as above, only that each inteface specifie is made an immediate supeole of the ole connected to the association end. f an inteface specifie is a class, its default ole is assumed. Figue 7 b shows the details. Note that the inteface specifies ae independent of the association end, since it is not equied that they paticipate in the same association. Finally the collaboation oles. Hee, we estict ouselves to single classification, which is still pedominating in the object-oiented wold. Thus, only one base classifie is listed with each classifie ole. f this base classifie is a class the classifie ole is mapped to an inteface with the base classifie populating that inteface (figue 7 c). Whethe o not the ole is the default ole of the class depends on whethe the classifie ole is a patial specification of the base class, i.e., whethe it esticts the available featues. By default, we must assume that this is the case so that a new ole is intoduced caying the classifie ole name if specified o a new name othewise; if not, the default ole can be used. Finally, if the base classifie is an inteface, it eplaces the new ole and the class populating it (figue 7 d). Note in paticula that the mapping of inteface specifies and classifie oles have not much in common. 10 The names may be thought of as being qualified by a lass o a Role suffix, espectively, but this suffix is left implicit fo the sake of eadability. 205

13 F. Steiman: A adical evision of UML s ole concept (a) (b) :D,...,S :D,...,S D... S D... S D D (c) : : /R: /R: /R /R s R R s R R (d) : : /R: /R: /R /R R R R R Figue 5: Mapping of old style notation to the new style (a) fo association ends, (b) fo association ends with inteface specifies, (c) fo collaboation oles with classes as bases, and (d) fo collaboation oles with intefaces as bases. A collaboation diagam does not only intoduce classifie oles, but also association oles and association end oles. These oles ae implicitly given if (a) the association is unique to collaboation diagams o (b) the use of the association is esticted in the context of the collaboation (so that the association has a base association). The latte may esult fom a estiction in multiplicity, navigability, etc. and esults in an 206

14 F. Steiman: A adical evision of UML s ole concept oveloading of associations (and thei ends). Thus, to povide complete mapping ules it would be necessay to conside all othe uses of the association. n figue 5, oveloading is shown only in the context of classifie oles connecting to association ends with olenames, because it is assumed that the olename is heitage fom a class diagam with the same association 11 and that this association is being esticted within the scope of the collaboation. Given these mapping ules the diagams of figue 2 ae easily tansfomed to the new style diagams of figue 4 (with multiplicities and oveloaded associations omitted). Howeve, a couple of things deseve mention. Fist, if an association end (of a class diagam) is to be filled with instances of the specified classifie only, the coesponding ole must not be populated by othe classes. Second, if the same olename occus in diffeent associations, it must be checked whethe the coesponding oles ae actually the same o diffeent. hances ae good that they ae the same if they compise the same set of instances (the ole playes) and if they come with the same set of featues. n case they ae diffeent, olenames can be qualified by thei association names. 5 The Big Pictue The definition of oles as pesented hee is not just anothe fomalization of the same old concept the elation of oles and classes o natual types (as opposed to ole types) of individuals as eflected by the metamodel in figue 3 is easily fomalized using ode soted pedicate logic (including a theoy of oveloading), and is at the same time deeply founded in disciplines as divese as sociology, linguistics, and ontology [Steimann 2000]. Paticulaly the latte two have an obvious influence on modelling, and both leave no doubt that oles and elations ae mutually dependent concepts. n this dependency, classes meely seve as the povides of instances (which oles don t have) and as takes of the esponsibility fo the ealization of whateve the oles of a model pomise. The biggest advantage of this sepaation is that stuctue and inteaction ae specified lagely independently of the classes that delive instances and implementation. As a esult, classes ae kept exchangeable even on the model level. n fact, it seems that modelling with oles delives on the long equested decoupling of classes in a natual and intuitive way. This has been ecognized not only by seveal objectoiented modelling methods such as OORAM [Reenskaug et al. 1996], OPEN [Fiesmith & Hendeson-Selles 1998] and ATALYSS [D Souza & Wills 1998], but also in diffeent application aeas of object-oiented modelling, fo instance by the patten community [Buschmann 1998] and in famewok design [Riehle 2000]. With oles defined as above at hand, instantiating the omposite patten in a model simply amounts to the involved classes populating (o ealizing) the omponent, omposite, and Leaf oles. A majo advantage of the intoduction of oles as patial specifications of classes is that polymophism and substitutability in modelling ae no longe bound to the genealization hieachy of classes (which mainly seves as an abstaction mechanism 11 intoducing olenames fo association ends in collaboation diagams is edundant, since classifie oles can have olenames 207

15 F. Steiman: A adical evision of UML s ole concept and, not only in UML, to specify the paths of inheitance), but apply equally to oles and thei implementos. The advantage hee is that substitutability, if bound to oles, is less demanding than equiing the full substitutability of (the instances of) one class fo anothe 12, because a ole pomises only limited functionality and behaviou. n fact, the liteal meaning of the tem polymophism is that objects (not functions) have diffeent foms, and an object playing diffeent oles may indeed be consideed polymophic in this liteal sense [Steimann 1999]. Last but not least, oles give intefaces a pominent conceptual abstaction that would othewise be missing in object-oiented modelling. Pehaps this lack explains why UML teats intefaces so negligently, but be that as it may, with oles as a natual and intuitive modelling concept (compising the puposes of intefaces and classifie oles), intefaces should finally get thei ightful place in object-oiented modelling. 6 onclusion The distinction between class diagams as static stuctue diagams (with classifies as types and as inteface specifies of association ends) on one side and collaboation diagams as behaviou diagams (with classifie oles and thei base classifies) on the othe is notoiously difficult to undestand (and even moe difficult to wite about). This unfotunate situation is wosened by the fact that UML s offeed divesity of modelling concepts opens the doo wide up fo intoducing inconsistencies into models that ae not easily caught unless an automated tool with full mastey of the UML specification is used. n fact, it may be conjectued that the building of such a tool (mapping all diagams into a single instance of the metamodel) would unveil many moe flaws in the UML specification. Keeping this specification is likely to esult in pactitiones ignoing lage pats of it, if only to be on the safe side. What is equally disappointing is that the UML specification does not pomote the use of the inteface concept, which is today a poven design and implementation constuct. nstead, the metamodel allows it that intefaces and othe classifies ae intechangeably used whee eithe one o the othe is equied. Fo instance, in UML neithe the inteface specifies of association ends no the base classifies of classifie oles need be intefaces, although thei pupose is clealy that of specifying an inteface. nstead, it seems that UML has adopted JAVA s notion of intefaces and follows it athe slavishly to the point that intefaces can only occu at the taget ends of diected associations an undue limitation that is unacceptable fo the ole concept. ORBA and DL, othe OMG standads, ae much moe flexible in this egad. Refeences [Bläsius et al. 1989] KH Bläsius, U Hedtstück, R Rollinge (eds) Sots and Types in Atificial ntelligence Lectue Notes in Atificial ntelligence 418 (Spinge 1989). 12 which is neve eally given because othewise thee would be no need to have diffeent classes 208

16 F. Steiman: A adical evision of UML s ole concept [Buschmann 1998] F Buschmann Falsche Annahmen (Teil 2) OBJEKTspektum 4 (1998) [D Souza & Wills 1998] DF D Souza, A Wills Objects, omponents and Famewoks with UML: The ATALYSS Appoach (Addison-Wesley, Reading 1998). [Fiesmith & Hendeson-Selles 1998] DG Fiesmith, B Hendeson-Selles Upgading OML to vesion 1.1 pat 2: additional concepts and notations Jounal of Object-Oiented Pogamming 11:5 (1998) [Gamma et al. 1995] E Gamma, R Helm, R Johnson, J Vlissides Design Pattens: Elements of Reusable Object-Oiented Softwae (Addison-Wesley 1995). [OMG 1999] OMG Unified Modeling Language Specification Vesion 1.3 ( June 1999). [Övegaad 1999] G Övegaad A fomal appoach to collaboations in the Unified Modeling Language in: UML '99 LNS 1723 (Spinge, 1999). [Reenskaug et al. 1996] T Reenskaug, P Wold, OA Lehne Woking with Objects The OORAM Softwae Engineeing Method (Manning, Geenwich 1996). [Riehle 2000] D Riehle Famewok Design: a Role Modeling Appoach doctoal dissetation (ETH Züich, 2000). [Rumbaugh et al. 1999] J Rumbaugh, Jacobsen, G Booch The Unified Modeling Language Refeence Manual (Addison-Wesley, Reading 1999). [Steimann 1999] F Steimann On the epesentation of oles in object-oiented and conceptual modelling Data & Knowledge Engineeing to appea. [Steimann 2000] F Steimann Fomale Modellieung mit Rollen thesis (Univesität Hannove, 2000). [Steimann 2001] F Steimann Role = nteface: a mege of concepts Jounal of Object-Oiented Pogamming (2001) to appea