[Modeling] Modeling an Agent Class- change of classes
Dr. Hong Zhu
Thu, 26 Jun 2003 14:26:51 +0100
----- Original Message -----
From: "Wagner, G.R." <G.R.Wagner@tm.tue.nl>
To: "Dr. Hong Zhu" <email@example.com>; "ModelingTC" <firstname.lastname@example.org>
Cc: "Giancarlo Guizzardi (E-mail)" <email@example.com>
Sent: Thursday, June 26, 2003 1:41 PM
Subject: RE: [Modeling] Modeling an Agent Class- change of classes
> > In dynamic classification, an entity can change its class at
> > run-time. Say, an object of class A becomes an object of class B.
> > That is what I meant by 'change classes'.
> OK, I think I see your point. The basic situation is
> Person [playingTheRoleOf Employee] isPartOf Company
> in a model with two classes (Person and Company) and
> an aggregation between them with a role name Employee.
It is not my model. My model have three classes: (a) Company, (b) Employee,
(c) Persons. There is a part-whole relation between Company and Employee.
Employee is a also a subclass of Persons.
> Then, if you destroy a particular company, say Enron, all
> aggregation links involving Enron will be deleted. But the
> involved persons continue to exist. So in this basic
> external model (not adopting the view of any particular
> company), there is no Employee class, but only a role
> name Employee.
I am afraid that roles are also classes in my models. Being a member of a
role class is to play the role.
> You can reify/"objectify" this aggregation into an association
> class isEmployedBy/Employment with suitable attributes. So, we
> would get
> Person [playingTheRoleOf Employee] isEmployedBy Company
In my model, it would read as follows:
A person P is employed by a company C, if P is a member of the Employee
class and P has a part-whole relation to the company C at run-time.
> But you cannot use an Employee subclass of Person in such
> an external (company-independent) model.
> Maybe that's what you wanted to suggest:
> Person isSuperClassOf Employee isPartOf Company
> But that's not a correct model, because you would need
> several Employee instances for the same person (one for
> each employment of that person), which is not consistent
> with the isSubclassOf relationship.
If such a nature model does not work well with the existing definition of
part-whole relation and subclass relation, then, we need something new.
However, I do not fully understand yous reasons here for why the model is
not correct. Why we need several Enployee instances for the same person? The
person can be shared by many companys (shareablity), and the person can move
from one company to another (lifetime independence). I agree that have
several instance for one person is not good. And, why it is not consistent
with the 'subclass of' relation?
My problem with the model is that, according to existing definition of
part-whole relations, we cannot get the person remain as an instance of
Persons class and at the same time not a member of the Employee class when
the company is destroyed. The only existing way of modelling the situation
is to kill the instance and recreate another one as a member of Persons.
This is not a nice way of modelling. Therefore, I suggest introducing a new
type of part-whole relation (i.e. the congregation relation) to solve the
> You could use an Employee subclass of Person (associated
> with Company by means of an aggregation) in an internal model
> adopting the perspective of a particular company, such as Enron
> (this class denotes, in fact, "EnronEmployee"). But then
> you would no longe have other (non-Enron) employees in
> your model.
I am not taking this view. However, I may consider if there is any problem
for this view.
> Modeling mailing list