Role Models

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.

you can have an association between Person and Company.
you can have Employee as a subclass of Person. Employee has an association to Company.
you can have Person with many PersonRoles?. A subtype of PersonRole? is Employee, which has an association to Company.
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