[Modeling] Comments on the latest Interaction Diagram specification draft.

Marc-Philippe Huget M.P.Huget@csc.liv.ac.uk
Fri, 23 May 2003 17:15:53 +0100

Hello Misty and all,

Sorry for this silence, I was modifying the interaction diagram
specification, I can now answer to some of your questions.

Marian Nodine wrote:

> This document is definitely making good progress! I appreciate all the
> hard work that has been put into it.


> In the beginning of Section 2, there is some mixing up of the terms
> "agent" and "role" with respect to the lifelines. This document should
> make it crystal clear what the head of those lifelines is, which is a
> *role*.

Point taken, hope I fixed it well.

> On page 10, I reiterate my comment that I think the snippet box at the
> top of the protocol frame is very overloaded. It contains the "sd
> <protocol name>", the parameters (with no names?) and the language and
> ontology variables. Could you please sort this out, and perhaps
> propose some alternative to this overloading?

I put outside parameters, you are right, if we have numerous parameters that
will be too cumbersome

> On page 14, with respect to role cardinalities, there is also the
> issue of relative cardinalities. For example, what if you want the
> participants to be "all of the UN Security Council"? What about quorum
> cardinalities, such as ">50% of the committee"?.

I add the notion of condition for message and role cardinality

> On page 17, I reiterate that I do not like detours. They get
> especially difficult if the detour involves some alternatives, as I am
> not sure how to draw the lifelines in that case. Rather, I would
> prefer to see the event that caused the "detour" to instead cause the
> receiver to role switch to another role (e.g., "winner". Thus, for
> example, in an auction there would be two alternatives in announcing
> the result. The first alternative would have the seller informing the
> participant that it is the winner, and the winner changing roles to
> the "Winner" role, where it can do such things as arrange for
> payment. The second alternative would have the seller informing the
> participant that it is the loser, in which case the participant's
> lifeline would stop and the interaction would end.

That is certainly due to Word document track changes since this element no
longer exists in the specification

> On page 18, I have similar issues with message cardinality that I did
> with role cardinality. What about ">2/3 of the receivers"? "All of the
> entities in the receiving role except for those not also in role xyz"?
> I can definitely see times where this type of cardinality restriction
> would be useful.

See above

> There is an issue in both Figures 21 and 24, related to these nested
> conversations. How do the roles in the nested interactions relate to
> the roles in the outer interaction? For example, in Figure 21, the
> Payment interaction may have two roles: payer and payee. How do these
> map to the customer and server of the outer conversation? In Figure
> 24, the Interaction Overview diagram, the overview does not have a
> notion of roles yet; however, they will be needed to show how the
> agents progress from role to role in the interactions shown in the
> overview.

Point taken on role dynamics.


Marc-Philippe Huget

Agent Applications, Research and Technology Group
Department of Computer Science
University of Liverpool
Chadwick Building, Peach Street
L69 7ZF Liverpool
United Kingdom

email: mph@csc.liv.ac.uk