Role Modeling

Bottom up thumbnail on RoleModeling: take an interaction diagram or event trace for a particular situation. Flatten the vertical axis so timing information is lost, only the list of messages is left. The lines connecting the objects are what I call "channels" (Trygve doesn't call them anything). The resulting picture, retaining the list of messages, is one fragment of a RoleModel. Take all scenarios related to a use case. Smash them all together in the same way. You now have one role model. Do the same for the other use cases and scenarios in the design. You now have a traceable, unfoldable definition of the inter object collaborations.

Top down thumbnail: take an aspect of your design. Split the class into the different conversation's it will be in. Create a role model for each conversation (i.e., list all the collaborators and messages in that conversation). Now you need tool assistance. You can merge roles together to produce your classes. Normally, at this point, when you look at a class, you cannot see the different roles it is playing. You have lost that information and simply cannot recover it easily. With a role-modeling tool, you can unpack any one role out of a class, since the messages stayed tagged with their role models. You can apply the role model to another class.

I am just starting to work with these things. It looks promising, but definitely needs a tool. (Could EnvyDeveloper be used to do this?) The tension, of course, is maintenance labor vs. value. TrygveReenskaug says they get much better and tighter reuse by reusing role models, as well as tighter compliance.

-- AlistairCockburn

This sounds very interesting. Are there papers out there on this? A couple of things come to mind that sound similar and I'd like to see more about how they relate: (1) Collaborations in Catalysis/UML (2) the use of interfaces as role contracts. -- MichaelFeathers

RoleModeling is described in the book "Working With Objects" by Trygve Reenskaug with Per Wold and Odd Arild Lehne, ISBN 1-884777-10-4 . The book has many excellent ideas, but is a bit hard to read. I recommend it to any expert in object technology, though I do not know how well it will be received by novices. -- RalphJohnson

For anyone else who is interested, I found excepts and independent reviews of his book at http://www.browsebooks.com/Reenskaug/. Also found an article on OORASS by TrygveReenskaug et al. in JournalOfObjectOrientedProgramming October 1992. -- MichaelFeathers

I found Reenskaug's book pretty fascinating, albeit not as directly practical as I'd have wished. One point he makes repeatedly: You have to work with whole role models, not merely with single roles. The vision he proposes is very rich, but I believe a better tool than the OORAM suite would be more appropriate. Are there any further developments with OORAM in the last year or so? -- MichaelHill

You can now download their tool and try it out. Look at the AnnouncementForOoRam?. -- RalphJohnson

RoleModeling for ProcessModeling concerns

Most of the above topic appear to pertain to ObjectRoleModeling (a derivate of Dutch originated Natural Language Information Analysis (NIAM) approach that started in the 80's) that is linked to BusinessObjects.

I am however interested in useful comments regarding the use of RoleModeling (e.g. RoleActivityModeling? originated by Martyn Ould) for analysis of Business Processes that may not have IT implementation considerations. That last qualification was to rule out any comments (for or against) UmlTwo ActivityDiagram?.

An example of attempts to relate ActivityDiagram? and RoleActivityDiagram?/Modeling (RAD) can be found at http://www.cems.uwe.ac.uk/~sjgreen/RAD&AD_V2.pdf (around 2003). And a 2006 paper on RAD at http://arxiv.org/ftp/cs/papers/0602/0602082.pdf showed continued research interests tied to ServiceOrientedArchitecture implementations. I am however interested in the suitability of RAD within a business context.