[Modeling] Comments on interaction diagram modeling doc

[Lin Padgham]

As mentioned we have worked primarily in closed agent systems to
date. We mostly use an agent development environment, so agents are
clearly distinguished entities (classes essentially). Roles are then
either implict - i.e. exist only at design level, or are implemented
as the capabilities the agent has.  Because beliefs/knowledge within
an agent are shared by all the capabilities within an agent (in the
framework we use), you don't need to have messages to pass along
information between capabilities/roles within a siongle agent - so it
does affect the concrete protocol diagrams.

The distinction you make between rigid and non-rigid types makes sense
- though it depends on the implementation platform whether and how you
could have role changing. The major difference for us really is that
within an agent beliefs and knowledge are (at least potentially)
shared between roles/capabilities, whereas between agents these are
not shared other than via explicit communication (or ugly hacks :-).

If one is working in the context of an open system, one can't really
make any assumptions about the groupings of roles into agents for any
other agents than one's own. This is why I said that it may be more
necessary to use roles than agent types when working in open systems.

Regards,

Lin

> > 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. 
> 
> How do you distinguish these two concepts? Ontologically,
> there is a distinction between what Guarino has called
> a "rigid" type and a "non-rigid" type: an instance of
> a rigid type will always be an instance of that type
> (during its lifetime), while an instance of a non-rigid 
> type may cease to be an instance of that type. A role
> corresponds to a non-rigid type. UML allows for dynamic 
> classification, which means that a role type, say
> Customer, can be modeled as a subtype/subclass of a 
> rigid type, say Person. Of course, it would be good
> to designate role types in UML diagrams, e.g. by means
> of a stereotype <<role>>. We may use this flexibility
> of UML classes to represent both rigid and role types
> also in AUML interaction diagrams.
> 
> -Gerd
> 
> ---------------------------------------
> Gerd Wagner  
> http://tmitwww.tm.tue.nl/staff/gwagner/
> Dep. Information & Technology 
> Eindhoven University of Technology  
> Email: G.Wagner@tm.tue.nl 
> Phone: (+31 40) 247 26 17  
> Fax: (+31 40) 247 26 12