[Modeling] Modeling an Agent Class- change of classes
Dr. Hong Zhu
Fri, 27 Jun 2003 08:55:57 +0100
Sorry for the delay in replying your email.
----- Original Message -----
From: "Wagner, G.R." <G.R.Wagner@tm.tue.nl>
To: "Dr. Hong Zhu" <firstname.lastname@example.org>; "ModelingTC" <email@example.com>
Cc: "Giancarlo Guizzardi (E-mail)" <firstname.lastname@example.org>
Sent: Thursday, June 26, 2003 7:27 PM
Subject: RE: [Modeling] Modeling an Agent Class- change of classes
> >> 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
> > Yes, exactly.
> >> 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.
> > 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?
> It's quite simple: if the person Hong is employed both by
> Enron and by Oxford University, then there need to be two
> links in the association class isEmployedBy/Employment,
> one between Hong and Enron (say with EmpNo=123) and another
> one between Hong and Oxford University (say, with EmpNo=007).
> However, if you use a Person subclass Employee, how can you
> have two different Employee instances denoting the same
> Person instance?
Of course, as a person, I only have one instance. This instance has a
part-whole relation with Enron and one part-whole relation with Oxford
Brookes. What is wrong with that? Of course, if we still use aggregation or
composition part-whole relations to explain this, then, we have problems.
So, my comclusion is that these two relations are not sufficeint and we need
more part-whole relations.
> > 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 simple solution is: when Enron is shut down, the Employment
> instance Enron-Hong is deleted, while the other Employment
> instance OxfordUniversity-Hong survives (and the person Hong
> survives anyway!).
Yes, that is the basic semantics of my congregation part-whole relation.
> Modeling mailing list