[Modeling] Re: Comments on interaction diagram modeling doc

[Lin Padgham]

> Lin Padgham wrote:
> > 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.
> 
> I find it useful on ordinary UML sequence diagrams to be able to show
> messages from an object to itself, in order to indicate local
> processing within the thread of control of that object.  It would be a
> shame not to have a similar ability in AUML, even though a "message to
> self" would probably eventually be implemented using a more efficient
> mechanism than inter-agent messaging.

we tend to show within agent processing at a next level down of
detail.

The problem I find is that if its unclear whether the message is to
the same agent, or to another agent of the same type, then it makes
understanding the diagrams more difficult.  At the top level of agent
interaction diagrams, I would argue we don't need to show within-agent
processing - at the next level down (drawing from activity diagrams?)
I would agree we do want to show this.

> 
> One of the useful features about UML is that it can be used informally
> to sketch out ideas, because there aren't too many constraints on how
> it is used.  Although I agree that we we will need to define precise
> semantics for AUML, I don't think we should be aiming to constrain its
> use any more than is necessary for that purpose.

But a problem is following someone else's ideas if the semantics is
unclear - this is the major problem we have had.

lin
> 
> > 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 agree with this.
> 
> - Stephen
> 
> _______________________________________________
> Modeling mailing list
> Modeling@www.fipa.org
> http://fipa.org/mailman/listinfo/modeling