[Modeling] Modeling an Agent Class- register your opinion

Stephen Cranefield scranefield@infoscience.otago.ac.nz
Thu, 26 Jun 2003 11:02:51 +1200

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

Now, the fact that the fire station ceases to exists does not mean that
the fire engines cease to exist.  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.

- Stephen