[Modeling] Modeling an Agent Class- register your opinion
Dr. Hong Zhu
Thu, 26 Jun 2003 12:08:21 +0100
----- Original Message -----
From: "Stephen Cranefield" <email@example.com>
To: "ModelingTC" <firstname.lastname@example.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
> > of agents as members of the department. When the department is
> > 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
> > owner (the department) affects the behaviour of the member agents (they
> > 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
> 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.
> 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
> 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