''StefanLazar wrote asking about Role patterns.  I forwarded the query to MartinFowler who gave this reply...'' 
''Stefan Buehlmann: No, have a look at http://www.martinfowler.com/apsupp/roles.pdf
---------------

I haven't done any work trying to come up with patterns about defining and
using roles (although it is a good idea to do something along those lines).
Peter Coad [1] has a very brief outline in his Actor-Transaction pattern, but
like most of his patterns its a very generic outline, useful but not that
detailed. There are also some ideas discussed by David Hay [2] in his chapter
on Contracts. (Hay's book is not an object-oriented book, but is conceptual
and thus still very valuable.)

There is divided opinion about how much you should use roles. Coad's style is
really to use roles all the time, while Hay's style is to avoid using roles
except for very rare cases. This difference in style between Coad and Hay is
echoed right across the modeling community.

My own preference is to start without using roles, just putting features on
Person, Organization or their supertype: Party. If you find that in different
contexts Parties get at significantly different behaviour, then that is the
force that leads you to roles. I wouldn't use them without that force (don't
build a complication you don't need.)

There is always an alternative to using roles, that is to look at the
relationship itself. For example, you can model a person being employed by a
company in four ways.

	1 you can have an association between Person and Company.

	2 you can have Employee as a subclass of Person. Employee has an association to Company.

	3 you can have Person with many PersonRoles. A subtype of PersonRole is Employee, which has an association to Company.

	4 you can have a class Employment which is associated with Person and Company (you can think of it as turning the association between Person and Company into a class).

I would start with (1) as it is the simplest. If there was significantly
different behavior for employees I would move to one of the others. (2) is
conceptually simple and works well if there are few such roles. However it
would probably require you to change the class of a Person, which although
conceptually simple, is rather more awkward to implement. (3) and (4) are very
similar: they both make it easy to switch the Person from being an Employee to
non-employee; you can have many roles at once, including many employee roles;
by adding a date range to the class you can easily keep a history of the times
the person was an employee. The choice between the two is mainly on whether
you wish to emphasize the relationship that defines the role (4) or the role
itself (3). My experiences have usually led to to (4), but that does not make
(3) wrong. (For an example of how I have done this take a look at my paper on
organization structures [3]).

All this is off the top of my head, and is probably a little too general for
your particular problem, but I hope it is helpful. If you have any more
questions feel free to email me and I will do what I can to help
further.Someday I may even write a pattern on this.

-----------

[1]	Coad, P., North, D. and Mayfield, M. Object Models: strategies,
patterns and applications, Prentice Hall, Englewood Cliffs, 1995.

[2]	Hay, D. Data Model Patterns: conventions of thought, Dorset House, New
York, NY, 1996.

[3]	Fowler, M. "Modelling Organization Structures," Report on Object
Analysis and Design, 2,2, (1995), pp. 20-23.
----
I have worked on money transfer systems at banks where the concept of "role" is currently in use (but is now being questioned).  

A money transfer involves moving cash from one bank to another - often through a third bank (or other financial institution).  Each bank may be a "sending institution" on one money transfer, a "receiving institution" on a second money transfer and a "correspondent bank" (an intermediary) on a third money transfer.  Since the information about a bank does not change from one money transfer to the next it is useful to keep the bank information (which remains constant on all of the transactions) separated from the transaction information.  The role information currently describes the sequence in which parties in the transaction will send money to one another.  

Since the responsibilities of a bank remain constant (pass the money along to the next party in the payment chain) no matter what the role, there have been some discussions about changing the system (an international interbank network) to just have a list of parties.

--ShalomReich