[Modeling] Modeling an Agent Class- composition

[Joaquin Peña]

Hello Jim:

Ok, but such kind of roles are static and data--driven. We use
roles from the "behavioural" point of view (UML collaborations).
It is very important to point out what we mean by "behaviour": it
terms of dynamic interactions with OTHER agents or even complete
agent systems.

That it is to say, the diagram I sent represents the mapping of a
collaboration into a class diagram. Although, Role view (UML
collaborations) and Class view must be orthogonal, if we want to
deal with behaviour variability it should not be implemented
inside the AgentClass, but in a different role class that contains
only the interacting behaviour of the agent.

An important point here is that for behaviour modelling
UML collaborations can be use to naturally model these features and no
static associations can be established between agentclasses in
this terms. Thus, the description of an open agent systems, where
agents continuously change their role to interact with others,
cannot be modelled with a class-centered approach because we
cannot relate them with static associations.

So, if you use a class approach you the option could be: define a
new association for dynamic interactions.

Although, we think that the class approach does not fit with this
purpose, we sent the diagram with roles and agents separated in
order to show that if we want to dynamically assign different
behaviours to an agent, this behaviour (represented as a role)
"cannot" be part of the agent.

Finally, the main point we wanted to come forward was that an Agentclass
must be able to describe the set of roles that the agent
eventually can play.

Best regards,

Joaquin.

 
> Very good!  Now you are beginning to identify an important 
> notion in enterprise modeling: that association classes often 
> carry the meaning you want for roles rather that just 
> subtypes of Person, Organization, and Party.
> The notion of being an employee is bound up in the notion of 
> an association between a person and an organization.  If you 
> are an employee with two employers, the person actually has 
> two different roles -- qualified by the
> employer organization.   Also, being a customer is yet 
> another association,
> except it is an association class the exists between two 
> parties (where a "party" is an person or organization).



> 
> -Jim
> 
> 
> On 6/26/97 2:40 PM, "Joaquin Peña" indited:
> 
> > I agree someway with you Hong.
> > 
> > I think, an employee can not be a class. It is a role that 
> object in 
> > the class person can perform.
> > 
> > Can be a solution to put such kind of relations between 
> roles? That it 
> > is to say, our idea is:
> > 
> > ********  play  -----------         interact    ----------  play
> > *************
> > CLASS  *------->* ROLE    * ------------------- * ROLE   
> *<------  CLASS
> > Person *        * employee*                     * Manager*
> > Department
> > ********        -----------                     ----------
> > *************
> > 
> > Thus, the implementation of Role is a set of method-calls 
> of the class 
> > person (note if you are a person who works for a company 
> and you lose 
> > your job, you still knows how to work, thus, method for 
> work must be 
> > maintain in class person). Then, if you destroy the department, you 
> > can delete such roles.
> > 
> > Thus, we decouple behaviour from functionality. We need a relation 
> > interact, and a relation play (can be also uses).
> > 
> > Does it makes sense?
> 
> _______________________________________________
> Modeling mailing list
> Modeling@www.fipa.org
> http://fipa.org/mailman/listinfo/modeling
>