[Modeling] Modeling an Agent Class- register your opinion

[f.tolman]

Hi All

My example is again somewhat different. In a Virtual Design Team (an agent)
several agents participate, a Virtual Architect, a Virtual Engineer, etc.
When the Design Team ends (because the design has been excepted) the lower
level agents hapilly life ever after.

So here the fact that both the composite and the components agents does not
seem to make any difference.

Cheers

Frits




----- Original Message ----- 
From: "Dr. Hong Zhu" <hzhu@brookes.ac.uk>
To: "ModelingTC" <modeling@fipa.org>
Sent: Thursday, June 26, 2003 1:08 PM
Subject: Re: [Modeling] Modeling an Agent Class- register your opinion


> Hi, Stephen,
>
> ----- Original Message ----- 
> From: "Stephen Cranefield" <scranefield@infoscience.otago.ac.nz>
> To: "ModelingTC" <modeling@fipa.org>
> Sent: Thursday, June 26, 2003 12:02 AM
> Subject: RE: [Modeling] Modeling an Agent Class- register your opinion
>
>
> > Hong Zhu wrote (on 19 June):
> > > We have a agent that represents a department in a university, and a
> number
> > > of agents as members of the department. When the department is
> destroyed,
> > > the members as individuals still exist, but their membership to the
> > > department is lost.
> > >
> > > The relationship between the department and it members is different
from
> > > composite in UML, because the agent is still alive after the owner is
> > > destroyed. It is also different from aggregation because the destroy
of
> > the
> > > owner (the department) affects the behaviour of the member agents
(they
> > lost
> > > the membership of department members and the associated capability and
> > > accessible resources). If an object is a part of another object as an
> > > aggregate, the destroy of the owner will not affect the part object's
> > > membership to any class, so does not affect its behaviour.
> > >
> > > Therefore, we need a new kind of part-whole relationship
> > > between department
> > > and its members, which is called 'congregation' in my language CAMLE.
> >
> > Sorry for the late response to this.
> >
> > I don't understand your argument.  Your example seems no different from
> the
> > following one:
> >
> > There is a fire station which has a number of fire engines assigned to
it.
> > To cut costs, the fire service is forced to close the fire station.
> > Therefore
> > the fire engines are reassigned to another station.  (Note that I do not
> > consider fire engines to be agents, at least not with current
technology).
> >
>
> Whether the parts are agents make a fatal difference.
>
> > Now, the fact that the fire station ceases to exists does not mean that
> > the fire engines cease to exist.
>
> In my example of departments, the employees do exist after the department
is
> destroyed. The difference for each employ is their membership to the
class,
> i.e. the change from a memebr to non-member. This has nothing to do with
> lifetime, and has nothing to do with sharedness. It is the change of
classes
> that make things different.
>
> > The relationship between the fire station
> > and its assigned fire engines can be modelled in UML as composition (the
> > ownership of parts can be transferred to another composite).  Why is the
> > situation any different when modelling a department and its employees as
> > agents?  Just because we talk in English about an employee being a
> "member"
> > of a department doesn't mean that the best (or only) way of modelling
the
> > employee-department relationship is as some sort of instance:class
> > relationship (sorry if I misunderstand you).  Composition seems to work
> > perfectly well to me.
> >
>
> This is because that you think fire engines are objests. Even so, the
> relationships between a fire station and fire engines should be aggregate,
> rather than composite.
>
> > - Stephen
> > _______________________________________________
> > 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