We utilize roles in our book "Streamlined Object Modeling." One of 
our main collaboration patterns is called Actor-Role. That pattern is 
used create collaborations such as a person taking on a role of an 
employee, and the employee role taking on further roles such as a 
manager or team member.

We use this pattern whenever a person, place, or thing can 
participate in multiple contexts. For each context define a role with 
information, behaviors, and collaborations that depict its 
involvement in the context. When contexts are nested, then the role 
itself has a new role depicting its involvement in that inner context.

We show how to object model with roles as well as how to implement 
these models in both Java and Squeak. And as for interesting 
conflicts that may result from using the actor-role pattern, our 
example implementations integrate the necessary business-rule 
processing that helps distribute and mange the complex behavior.

Mark Mayfield



>At 7:01 AM -0500 2/25/02, Sam Adams wrote:
>>I haven't read the PIE papers in a very long time, but I have done lots of
>>thinking about roles and object modeling over the years, especially wrt CRC
>>modeling.  This thread prompted a design thought that I'll throw into the
>>soup:
>>
>>The basic object was a RolePlayer and contained a collection of Roles,
>>where each Role instance would have the state and behavior appropriate to
>>its role (and know its player).  The issues that arise are how to deal with
>>shared state between roles (e.g. annualSalary in EmployeeRole could also be
>>annualIncome in TaxPayerRole), and how to deal with message handling
>>priority (aka, which role dominates in a particular scenario, eg
>>takeSickChildToDoctor in FatherRole vs attendImportantBusinessMeeting in
>>AmbitiousEmployeeRole).  The shared state problem seems to call for
>>valueholder-like reference objects that would be constructed and installed
>>in each Role with overlapping state when the roles are installed in the
>>RolePlayer.
>>
>>The switching issue could be handled as it is with persons, namely, if you
>>have a request for someone where you assume no particular role bindings or
>>conflicts, you simply send the message to the object.  If you want to make
>>sure that a particular role behavior is invoked, then call out the role as
>>in "as the father of my children I expect you to..." or "as an employee of
>>this company you need to ...".
>>
>>This could be implemented using a mix of composite and facade behavior
>>where both RolePlayer and Role had a common interface for handling
>>roleplayer-style  messages (ala composite) but where at anytime from the
>>perspective of a sender, one Role instance or another was acting as a
>>facade for the RolePlayer. So if the RolePlayer recieved a message, it
>>would delegate handling to the first understanding Role in its collection
>>using a default priority order.  If a Role recieved the message that it
>>understood, it would simply do it. But if it did not understand, it would
>>delegate to the RolePlayer.  Of course, a guard against infinite regress
>>would be in order.  If a sender wanted a particular Role facade or
>>perspective on an object, it could use something like the old conversion
>>protocols (asString asForm asByteArray) except the returned object would be
>>the appropriate Role facade (playingFather or playingAmbitiousEmployee).
>>
>>The result would be a system where each object could present multiple faces
>>to its collaborators, and new roles (or subsets of
>>responsibilities/interfaces) could be added and removed dynamically.  Lots
>>of details to work out, but there's the basic idea.  I'll leave the
>>meta-roles, geno-roles, and pheno-roles for another time.   ;-)
>>Regards,
>>Sam
>>
>>Sam S. Adams, IBM Distinguished Engineer, IBM Research
>>tie line 444-0736, outside 919-254-0736, email: ssadams at us.ibm.com
>><<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>
>>
>>
>>
>>
>> 
>>                                                                                                                                         
>>                       Jecel Assumpcao 
>>Jr                                                                                                    
>>                       <jecel at merlintec.com>                   To: 
>>squeak-dev at lists.squeakfoundation.org                               
>>                       Sent by: cc:
>>                       squeak-dev-admin at lists.squeakfou Subject: 
>>PIE (was: Getting rid of metaclasses)                               
>>
>>ndation.org                                                                                                           
>>
>> 
>>                                                                                                                                         
>>
>> 
>>                                                                                                                                         
>>                       02/24/02 01:53 
>>PM                                                                                                     
>>                       Please respond to 
>>squeak-dev                                                                                          
>>
>> 
>>                                                                                                                                         
>>
>> 
>>                                                                                                                                         
>>
>>
>>
>>On Sunday 24 February 2002 19:18, Alan Kay wrote:
>>>        Goldstein and Bobrow eventually found a very interesting way to
>>>  implement these enriched objects: they used Smalltalk instances for
>>>  each role/perspective. So a PIE object could be made from many
>>>  Smalltalk objects.
>>
>>I suppose they used a flat "perspective space", right? Some other
>>proposals allow role inheritance, but that easily becomes a big mess.
>>
>>How do you know which perspective to use at any given time? How do you
>>switch between them?
>>
>>Sorry about the questions, but there is essentially nothing online
>>about PIE. I am trying (http://www.merlintec.com:8080/software/8) to
>>come up with something similar.
>>
>>-- Jecel
>
>
>--