3C Clear Clean Concise  UML                       Previous   Contents   Next
communityUML 2torial

5.4.2               Role

In the works as you browse...                  constr3.gif (1712 bytes)

A role is used to specify an action, association or relationship without identifying a particular participant in that action, association or relationship. That is, a role serves as a placeholder, used when the modeler does not wish to be more specific at that place in the model.

For each role, there is a type that specifies the model elements that may be bound to that role.

A role is one kind of abstraction. Abstraction is "the process of suppressing irrelevant detail to establish a simplified model, or the result of that process." [ODP] When using a role, the irrelevant detail that the modeler suppresses is the identity of the particular model element that is being used in the specification.

Roles are used when specifying associations and actions.  
And so roles are used when specifying:
  -- attributes, operations and behaviors
  -- all kinds of correspondences, including generalization, combination and abstraction
  -- collaborations, use cases, processes and data flows
  -- interfaces, connectors and protocols
  -- software architectures, components, and deployments


Q:  What are some examples of roles?

A:  In UML 1:  classifier roles, actors, association ends.

Q:  And in UML 2?

A:  Any model element that is specified as a variable.

Q:  Please give some concrete examples.

A: 

In the generic relationship, generalization:
           UML 1: child and parent
           U2P submission: special and general
           3C submission: specialized and generalized
                With classes bound to these roles: Cat in the role, specialized, and Animal in generalized

In the generic action type, CORBA request: client and object.
In the more general generic action type, client-server operation invocation: client and server

More examples are given in the RunningExample.   There you will find an example of a collaboration with object bound to some roles, but not to others.

Q:  Can you explain in other terms?

A:  Let's use some metaphors.  (These are just metaphors: a figure of speech in which a word literally denoting one object or idea is used in place of another to suggest a  likeness or analogy.)

In a Java program, a method declaration starts with a method header that includes an identifier for the method and a formal parameter list.   A formal parameter may be declared with a type followed by a identifier.  In the metaphor, the Java identifier is the UML variable name, that is, the name of the role, and the Java type is the [UML] type of that role; when the method is invoked, a value is bound to that role:

Metaphor:
  identifier : role name
  type : type
  actual parameter : value bound to role

In Love's Labor Lost, there is a role named 'Don Adriano de Armado'.  The manuscript specifies a type for the actor in that role: "a fantastical Spaniard."  Lily Tomlin might play that role.

Metaphor:
  Don Adriano : role
  fantastical Spaniard : type
  Lily : object
  playing a role : bound to a role

Why does Lily satisfy the type, fantastical Spaniard?   Because she is able to act as a fantastical Spaniard as conceived by Shakespeare.   (To bring this metaphor closer to home, yYou might prefer to specify the type for the role, Don Adriano, as: actor able to play a fantastical Spaniard.)

In another performance, the understudy, say Jody Foster, might play the Don.

Metaphor:
  different actors playing the same role at different times : different objects bound to the same role at different times

Q:  OK, OK.  Enough of that.  Can   you explain how roles are used in a collaboration or in a process definition?

A:  Yes we can.  See <when they are ready> Collaboration and Process.  <Right now> see an example of roles in a collaboration in the RunningExample.


 

Previous   Contents   Next         RunningExample

  DA.gif (4367 bytes)

The OMG mark, ‘UML,’  is a trademark of Object Management Group, Inc. (OMG). 


During development of this web site, please send comments to Joaquin Miller. mailto:joaquin@acm.org    
Copyright © 2000 Financial Systems Architects