[Modeling] Comments on Comments on the latest Interaction Diagram
Wed, 30 Apr 2003 16:32:54 -0400
I have not had the chance yet to study the diagram but some of the problems
posed by Nodine, I ahve faced before and may add my suggestions.
>In Figure 15, what does a synchronous message mean in an agent system?
>I am not questioning the notation here, just why anyone would use
>one. The receiver of the message is autonomous, and can do whatever he
>feels like before replying, so why should my agent even think about
>waiting for it? On the notation side, now, what does figure 15 really
>mean? is the "ready" the message that will unblock the wait for the
>"ready for vote"? Couldn't you effectively represent the same thing by
>making it a CriticalRegion? Also, how do you implement a synchronous
>message to n receivers?
Cybele actually supports multiple blocking messages. The Cybele semantics
is based on a given number of expected responses and a timeout. The
synchronous barrier is passed at either trigger.
>I have a similar problem with Figure 16. It seems like you have a
>problem if access is granted, but the information never becomes
>available. This is a design issue, not a notational issue,
>though. There is an issue here with alternatives (it shows up in
>several of your figures) as to what the semantics are for evaluating
>the guards in the alternatives. Do you start with the top, and move
>down? It is certainly not a good idea to assume that you will always
>have a well-formed set where exactly one guard will be true in any
>given circumstance. Is there such a thing as a default guard?
>As a corollary to the above paragraph, Figure 19 should have guards on
In a system with more then one guard true, the non-determinism of the
system is inherent. A system of priorities between transitions can be
composed to avoid double interpretation if a deterministic approach is
needed. (I'm not sure yet IF it is needed, more on that when I have time to
study the subject...)
>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
>By the way, I really like the notion of an interaction overview diagram.
I second both points, about the importance of the interaction overview
diagram and about the need to role to role matching in nested interactions
(it can be either named or positional, not much choice there....)
Intelligent Automation, Inc.
7519 Standish Place, ste 200
Rockville, MD 20855