[Modeling] Modeling an Agent Class- composition

[James Odell]

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.

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?

-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
>> 
>