[Modeling] Modeling an Agent Class

Tue, 10 Jun 2003 17:19:41 +0200

--------------070301010609070107090904
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Stephen Cranefield wrote:

>I wrote:
>
>>... I think the metamodel or profile does somehow need to
>>represent the idea that agents can receive messages.  One
>>way to do this would be to specify that agents have exactly
>>one operation: receiveMessage.  [...]
>>
>
>Of course, there would need to be *two* operations: receiveMessage
>and sendMessage.
>
Stephen,
I agree with you that the metamodel has to represent agent communication 
capabilities, so
'send message' and 'receive message' sounds OK to me. However, I 
wouldn't model them as
Operation to avoid bringing in the Design by Contract legacy that 
doesn't really apply here:

sendMessage() can just be called from within the agent thread of 
control: in a OO implementation
it could even be a private method. Its correctness pre-condition can 
only be related to inner details
of the agent, such as the outgoing mailbox being not full. I wouldn't 
put higher level concerns such as
feasibility preconditions of FIPA Communicative Acts here. The 
post-conditions are not very significant,
too: most of the time agent message passing is asynchronous, so 
completing the sendMessage() operation
doesn't tell much of the state of the agent and of the environment.

Similarly, receiveMessage() pre- and post-conditions are related to low 
level concerns: the pre-condition can
be 'the incoming mailbox is not empty' (and the post-condition can be 
'the returned message is non-null, and
has been sent in the past by someone to this agent') or it can simply be 
'true' (and the result can also be null).

I'd rather model the communication capabilities of an agent through a 
class and association graph, such as
Agent-utters-CommunicativeAct, Message-transports-CommunicativeAct, and 
the like.
I believe that we should build a Class Diagram depicting AgentClass and 
its related concepts.
In particular, if we go for the 'AgentClass subclass of Classifier' 
road, we can model some of the agent traits as
Feature (e.g., could we define a Goal subclass of Feature and attach it 
to AgentClass?), whereas for other traits,
the more structured ones I would say, we would have to go for classes 
and associations (Agent-achieves-Goal, in
the previous example).

>
>- Stephen
>
>P.S.  I will be away and out of email contact for the next two
>weeks.
>
OK. No problem.

    Giovanni

>
>_______________________________________________
>Modeling mailing list
>Modeling@www.fipa.org
>http://fipa.org/mailman/listinfo/modeling
>

-- 
	         Giovanni Rimassa
     Dipartimento di Ingegneria dell'Informazione
         Universita` di Parma - Parma (ITALY)
    Phone: +39 0521 905712 -  Fax: +39 0521 905723

--------------070301010609070107090904
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Stephen Cranefield wrote:<br>
<blockquote type="cite" cite="mid:B57613845A50D211864C0000F8FA5C280768BE03@mars.otago.ac.nz">
  <pre wrap="">I wrote:<br></pre>
  <blockquote type="cite">
    <pre wrap="">... I think the metamodel or profile does somehow need to<br>represent the idea that agents can receive messages.  One<br>way to do this would be to specify that agents have exactly<br>one operation: receiveMessage.  [...]<br></pre>
    </blockquote>
    <pre wrap=""><!----><br>Of course, there would need to be *two* operations: receiveMessage<br>and sendMessage.<br></pre>
    </blockquote>
Stephen,<br>
I agree with you that the metamodel has to represent agent communication
capabilities, so<br>
'send message' and 'receive message' sounds OK to me. However, I wouldn't
model them as<br>
Operation to avoid bringing in the Design by Contract legacy that doesn't
really apply here:<br>
    <br>
sendMessage() can just be called from within the agent thread of control:
in a OO implementation<br>
it could even be a private method. Its correctness pre-condition can only
be related to inner details<br>
of the agent, such as the outgoing mailbox being not full. I wouldn't put
higher level concerns such as<br>
feasibility preconditions of FIPA Communicative Acts here. The post-conditions
are not very significant,<br>
too: most of the time agent message passing is asynchronous, so completing
the sendMessage() operation<br>
doesn't tell much of the state of the agent and of the environment.<br>
    <br>
Similarly, receiveMessage() pre- and post-conditions are related to low level
concerns: the pre-condition can<br>
be 'the incoming mailbox is not empty' (and the post-condition can be 'the
returned message is non-null, and<br>
has been sent in the past by someone to this agent') or it can simply be
'true' (and the result can also be null).<br>
    <br>
I'd rather model the communication capabilities of an agent through a class
and association graph, such as<br>
Agent-utters-CommunicativeAct, Message-transports-CommunicativeAct, and the
like.<br>
I believe that we should build a Class Diagram depicting AgentClass and its
related concepts.<br>
In particular, if we go for the 'AgentClass subclass of Classifier' road,
we can model some of the agent traits as<br>
Feature (e.g., could we define a Goal subclass of Feature and attach it to
AgentClass?), whereas for other traits,<br>
the more structured ones I would say, we would have to go for classes and
associations (Agent-achieves-Goal, in<br>
the previous example).<br>
    <br>
    <blockquote type="cite" cite="mid:B57613845A50D211864C0000F8FA5C280768BE03@mars.otago.ac.nz">
      <pre wrap=""><br>- Stephen<br><br>P.S.  I will be away and out of email contact for the next two<br>weeks.<br></pre>
      </blockquote>
OK. No problem.<br>
      <br>
&nbsp;&nbsp;&nbsp; Giovanni<br>
      <br>
      <blockquote type="cite" cite="mid:B57613845A50D211864C0000F8FA5C280768BE03@mars.otago.ac.nz">
        <pre wrap=""><br>_______________________________________________<br>Modeling mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:Modeling@www.fipa.org">Modeling@www.fipa.org</a><br><a class="moz-txt-link-freetext" href="http://fipa.org/mailman/listinfo/modeling">http://fipa.org/mailman/listinfo/modeling</a><br><br></pre>
        </blockquote>
        <br>
        <br>
        <pre class="moz-signature" cols="$mailwrapcol">-- <br>	         Giovanni Rimassa<br>     Dipartimento di Ingegneria dell'Informazione<br>         Universita` di Parma - Parma (ITALY)<br>    Phone: +39 0521 905712 -  Fax: +39 0521 905723<br><br></pre>
        <br>
        </body>
        </html>

--------------070301010609070107090904--