Hi,
I have now managed to go through the document on interaction diagrams
in some detail and have quite a few comments in my notes below. I hope
we will not try to move too fast into standardising as I think it is
important to explore the many issues that come up when people put
forward suggestions, others comment on them, etc. It is important we
allow sufficient time to really try to address the issues and problems
that different people find.
Anyway, here are my notes, ordered by the order in the document...
In terms of the work we are doing, this document raises the question
as to whether protocol specifications should be between agents (or
agent types) or between roles. We have up until now used agent types -
which then means we don't have to deal with role changes within a
protocol specification as they are simply internal to an agent type
and don't involve inter-agent messaging. (We would show these at a
lower level).
However, we have mostly worked with design of closed systems. For open
systems it may be more necessary to specify protocols in terms of
roles as one doesn't know what roles are combined into any one agent
within an open system. Although actually the example given
(participant role becomes buyer role) does assume a design where these
roles are within the one agent. I think we need to do more work within
open systems design to understand whether in fact you can allow lack
of specification of which roles belong to which agent type, or whether
you may as well use a notion of agent type. (Agents could have
multiple types, but perhaps not within the same interaction?)
p.3. there seems to be some wrong referencing to figure numbers.
2.2.2 When defining a specific agent on a detour, it is likely that a
description rather than a name will be needed. E.g. "winner" in
the auction protocol.
2.2.3 The 2 constraints seem to conflict: Must have only one instance
of a role. Consider breaking out a specific instance of a role on
a separate lifeline. I think the first constraint should be
dropped. Whether one shows more than one instance will depend on
the protocol and what is needed for clarity. It may make sense to
require that if there are multiple instances of a role there is
some way to differentiate them?
figure 8. Presumably could also show send-payment as coming from the
detour?
2.3.1 senders and receivers of messages can have same or different
roles. What assumptions do we want to make about same roles being
different agents. I would suggest an assumption that if a message is
shown going to the same role, then the assumption is that it is to
a different agent in that role - or at least that it is not only
to itself. I.e. it may be a message sent by one agent in a role X,
to all other agents in role X, including itself. However you
wouldn't show a message if it was a single agent sending a message
to itself.
Re 1:n, n:1, n:n, etc. We (thanks to Steve Fonseca for this
suggestion) suggest that it is useful to number the roles themselves
separately to the messages between roles. Sometimes the role
numberings can be inferred from message numberings, but not always.
Synchronous vs asynchronous messages: it is very unclear to me that
this is useful for a number of reasons:
* the difference in message type appears visually at the receiver end,
but exists semantically at the sender end. This is confusing.
* it would seem to me that the lifeline provides sufficient ability to
indicate synchronisation if this is required. If nothing else
happens on the lifeline of A, until a response is received from a
message sent from A, then that can be regarded as a synchronous
message, at least with respect to inter-agent communications
* figure 11 doesn't appear to make sense. The controller sends a
synchronous message, "ready for vote" (which means according to
synchronous message semantics as stated informally at least, that it
gives up control until it receives a response to this message). the
next thing to happen is that the controller sends another message,
which is what then receives a response.
Figure 10: I don't like the notation for showing alternatives. I much
prefer the original XOR notation - the diamond. I think its much
easier to read, particularly if you envision this choice being on a
message between 2 non-adjacent agents in the protocol.
Figure 11: How would you distinguish between the case where the
controller must wait for one of the messages to come back vs waiting
for all the votes to be received. How do you indicate how long to wait
for "all" - e.g. if one has dropped out, do you wait forever?
Constraints: What is the semantics of multiple non-blocking
constraints? And semantics violates the "if" in "if and only if" while
or semantics violates the "only if". Suggest that we define
non-blocking constraints as being anded and having "if" semantics
rather than if and only if. Or semantics will then require complex
constraint expressions (or decision points that have same meassage,
but different constraint). This issue is likely to give some problems
in the formal semantics, so important not to finalise it too early.
I need to see examples of timing constraints before having comments on
them.
Interaction operators:
I tend to prefer the old style for Alt (XOR) and Par (AND).
I think something that addresses the concept captured by break is
important, but i would prefer some mechanism that indicates an
exception point and allows the exception behaviour itself to be
defined separately: Often exception behaviour is the same for many
places/protocols, it occurs often and clutters up the view of the
normal execution of the protocol. It needs to be defined clearly, but
should be extracted out. Some way to name an exception point (a bit
like a merge point) and then define it elsewhere would be good.
I think the negative operator is totally impractical. you can never
define ALL the messages that are invalid in the interaction. Surely
the interpretation is that any message not defined as valid, is
invalid. i think this should be dropped.
I think ignore is quite useful. It allows to define a message that is
not invalid, but does not result in any response. An example is a late
incoming bid in some of the auction protocols. At certain points, bid
messages can be expected to arrive, and are not invalid, but they
don't result in any action. being able to specify these on the
protocols is (IMHO) very useful. Not clear on what the intended
notation is here, so unsure whether I will like that :-)
Loop is useful - and a box with a constraint is probably an OK
notation.
A related but slightly different thing is the need sometimes to tag a
piece of interaction and be able then to refer back to it, or include
it, elsewhere. related to nesting protocols, but where the first
instance may appear in line and then other instances are referred to
by label.
Fig 15 as it stands doesn't make sense as a protocol unless you have
the semantics that an alternative box ends the protocol unless there
are explicit continuations. I.e. the protocol can't just "fall
through" to the next step. If this is the intent, I don't really like
allowing continuations within the same diagram as it can too easily be
confusing. At the same time I don't like the idea of starting a new
diagram each time you have a choice point either as you won't see the
continuity. This is further reason for my preferring the previous
choice notation - though with some improvements. In particular there
needs to be a clean way to indicate where one choice leads to one
continuation of the protocol, and another leades to a different
continuation. My preference is to choose one continuation as "normal"
or default and show that on the diagram, whereas all other choices
somehow point to or tag an alternative continuation. This mechanism is
then also what is used for exception handling.
I am unclear what is the difference between nested and interleaved
protocols. The example given seems to me to be what I would refer to
as nested protocols - i.e. you label it, but the details are defined
elsewhere. One concern I have here (whether its called nested or
interleaved) is how you identify the agents participating in the
nested/interleaved protocol when they are not adjacent on a protocol
involving many agents. An alternative notation which we have
discussed for this is a named box on the lifeline of all the agents
participating in the nested/interleaved protocol, with a horizontal
line joining these boxes. If the nested/interleaved protocol uses
different role names, there needs to be a mechanism to match the roles
between the two.
The stop notation: I agree we need a mechanism for showing end
points. I don't think this is adequate as typically an agent/role may
either stop or continue depending on the situation. E.g. on fig 15,
where would put the cross to show the stop after not understood? one
also needs to consider that if there are several asynchronous threads
happening as part of a single protocol, it may be possible for a
certain message to result in a stop of that piece of interaction, but
other pieces to still continue. we have some examples of these we have
discussed but i don't have them in my head at present.
Interaction Overview diagram: I agree we want something that is more
like activity diagrams, that shows more of the within-agent
activity. We have been doing some work here and I prefer what we have
come up with to what is shown here. I will discuss with Steve Fonseca
and Michael Winikoff and we will try to send in some examples of
possible alternatives here.
I fine the communication diagram totally confusing! (maybe because it
comes at the end and I am tired now :-) It doesn't currently seem
useful to me at all...
I think timing diagrams (or rather the information captured by them)
can maybe be captured OK in our variant of activity diagrams.
thats all for now...
Lin