[Modeling] Modeling an Agent Class- composition

[Joaquin Peña]

Hello Jim:

> Joaquin,
> 
> Yes, you are quite right.  I had some crossed neurons when I 
> wrote that.  I think it was because I was developing a UML 
> 2.0 certification exam when I read your mail.  So, forget 
> what I wrote.

We have been working in modelling dynamic behaviour of agents
(also in distributed systems) for long and I thing that some
ideas we assume may be outside of the context of this TC.

I should explain things deeper.  It was my guilt. I'm sorry.

> 
> Having said that, I find that I am puzzled by your earlier 
> statement that "...Role is a set of method-calls of the class 
> person."  If a person plays the role of employee, mayor, 
> homeowner, and pet owner, it would seem odd to me that all 
> the method calls would go to the class Person.  That could 
> make it a very fat class, indeed.  Perhaps I misunderstand 
> the intent of that statement?

What I wanted to say is that these calls must be external to class
person, that it is to say, class person is a passive object that
only offers its functionality to roles. 

We have work on these ideas using proprietary diagrams. Now, We
are working on representing such concepts in UML. Do you think
that they could be interesting for this TC?

Regards,

Joaquin.


> 
> -Jim
> 
> 
> 
> On 6/28/97 4:06 PM, "Joaquin Peña" indited:
> 
> > 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
> >> 
> > 
> 
> _______________________________________________
> Modeling mailing list
> Modeling@www.fipa.org
> http://fipa.org/mailman/listinfo/modeling
>