[Modeling] Modeling an Agent Class- register your opinion
Dr. Hong Zhu
hzhu@brookes.ac.uk
Fri, 20 Jun 2003 09:21:19 +0100
Joaquin,
My solution is slight different from yours.
----- Original Message -----
From: "Joaquin Peña" <joaquinp@us.es>
To: "'Dr. Hong Zhu'" <hzhu@brookes.ac.uk>; "'Wagner, G.R.'"
<G.R.Wagner@tm.tue.nl>; "'James Odell '" <email@jamesodell.com>;
"'ModelingTC '" <modeling@fipa.org>
Sent: Friday, June 20, 2003 8:50 AM
Subject: RE: [Modeling] Modeling an Agent Class- register your opinion
> That is my idea, Hong.
>
> Class Diagram are used to represent static relations ---> In the
> agent field this relations changes over time, so, It can not be
> easily used in agents.
Traditional object class is weak, and therefore, we need to extend it. So, I
introduced the concept of caste (which is called agent class in this mailing
list). Caste has the features of dynamic classification and multiple
classification, and new part-whole relations. In my caste diagrams, we can
specify 'role' change paths to represent the dynamic change of
classifications, etc.
> The solution, as I've commented before, is
> to model such transient relations using design patterns that allow
> us to decouple classes and interaction between them.
>
In my opinion, design patterns are at a lower level of abstraction than
modelling. Moreover, if we can have a stronger language, we might be able to
solve such implementation problems more straightforwardly.
> Objet Diagram, are used to model behaviour of instances, but,
> unfortunately, limited to the static relations defined in the
> class diagram.
>
Yes, object diagrams and behaviour diagrams also need to be modified.
-Hong
> Joaquín Peña
>
>
> > -----Mensaje original-----
> > De: Dr. Hong Zhu [mailto:hzhu@brookes.ac.uk]
> > Enviado el: viernes, 20 de junio de 2003 9:42
> > Para: Joaquin Peña; 'Wagner, G.R.'; 'James Odell '; 'ModelingTC '
> > Asunto: Re: [Modeling] Modeling an Agent Class- register your opinion
> >
> >
> > Hello, Joaquin,
> >
> > ----- Original Message -----
> > From: "Joaquin Peña" <joaquinp@us.es>
> > To: "'Wagner, G.R.'" <G.R.Wagner@tm.tue.nl>; "'Dr. Hong Zhu
> > '" <hzhu@brookes.ac.uk>; "'James Odell '"
> > <email@jamesodell.com>; "'ModelingTC '" <modeling@fipa.org>
> > Sent: Thursday, June 19, 2003 6:56 PM
> > Subject: RE: [Modeling] Modeling an Agent Class- register your opinion
> >
> >
> > > Hello:
> > >
> > > I think that the main problem is that object orientation
> > does not fit
> > > well with system where behaviour is crucial.
> > >
> >
> > Yes, I agree.
> >
> > > This issue can be easily solved using Role Modelling:
> > >
> > > A employee is not a class, it is a role that an object of the class
> > > person can perform. Thus, if a department is destroyed, all its
> > > employees lose this role becoming only persons (performing
> > the other
> > > roles they have, i.e. father, engineer, ...).
> > >
> >
> > What is a role in object orientation? According to the OO
> > philosophy that 'everything is object', the answer can only
> > be that roles are objects. Of course, they are defined
> > through class, i.e. instances of class. This hights why OO
> > does not modelling the world in a straightforward way, but
> > one needs to twist their minds and arms to view the world.
> >
> > > There are a lot of papers on how to implement roles in the OO
> > > paradigm, but we think most appropriate approach is such that use
> > > Aspect-Oriented Programming where functionality and behaviour are
> > > orthogonal in the implementation.
> > >
> >
> > I believe that agent-orientation can provide a nature way
> > solve this problem.
> >
> > -Hong
> >
> > > Joaquin.
> > >
> > >
> > > > -----Mensaje original-----
> > > > De: modeling-admin@fipa.org [mailto:modeling-admin@fipa.org] En
> > > > nombre de Wagner, G.R. Enviado el: jueves, 19 de junio de
> > 2003 18:58
> > > > Para: Dr. Hong Zhu ; Wagner, G.R.; James Odell ; ModelingTC
> > > > Asunto: RE: [Modeling] Modeling an Agent Class- register
> > your opinion
> > > >
> > > >
> > > > > 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.
> > > >
> > > > Hong,
> > > >
> > > > again, the difference between aggregaion and composition
> > is simply
> > > > the property of shareable parts. The property of lifetime
> > dependency
> > > > you refer to is orthogonal to this.
> > > >
> > > > Obviously, in your example, there is an aggregation relationship
> > > > between the members of a department and the department
> > (because a
> > > > member can be also a member of another department, i.e.
> > members can
> > > > be shared). An aggregation relationship does not imply
> > anything wrt
> > > > lifetime dependency and it does neither imply that it would not
> > > > affect its parts. These are additional, othogonal issues.
> > > >
> > > > So, your conclusion that we need a "third" part-whole
> > relationship
> > > > is unfounded.
> > > >
> > > > -Gerd
> > > >
> > > >
> > > > > ----- Original Message -----
> > > > > From: "Wagner, G.R." <G.R.Wagner@tm.tue.nl>
> > > > > To: "Dr. Hong Zhu " <hzhu@brookes.ac.uk>; "James Odell "
> > > > > <email@jamesodell.com>; "ModelingTC " <modeling@fipa.org>
> > > > > Sent: Tuesday, June 17, 2003 9:03 PM
> > > > > Subject: RE: [Modeling] Modeling an Agent Class- register
> > > > your opinion
> > > > >
> > > > >
> > > > > > > The part-whole relationship between agents are also
> > > > different: The
> > > > > > > aggregation relationships between the whole and part is
> > > > > different in
> > > > > > > agent classes from that in object class. In object
> > > > > > > orientation,
> > > > > there
> > > > > are two
> > > > > > > types of whole-part relations:
> > > > > > > (1) composition, in which the lifespan of the whole and the
> > > > > > > part
> > > > is
> > > > > the
> > > > > > > same, and (2) aggregation, in which the lifespan of the
> > > > whole and
> > > > > part
> > > > > > > is independent. Having two whole-part relations is
> > > > inadequate for
> > > > > > > agent-orientation due to agent's autonomous behaviour. For
> > > > example,
> > > > > we
> > > > > > > have a agent which 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 class
> > > > membership
> > > > > as
> > > > > the
> > > > > > > member of the department are lost.
> > > > > >
> > > > > > This is a misunderstanding of the UML aggregation concept.
> > > > Composition
> > > > > > is defined as a "non-shareable" aggregation, and not via
> > > > > > lifetime
> > > > > dependency.
> > > > > > There are some misleading remarks about lifetime
> > dependency in
> > > > > > UML
> > > > > 1.4.
> > > > > > Lifetime dependency is implied in aggregations with
> > inseparable
> > > > parts.
> > > > > > It's not related to shareability. Please see my ODBASE'2002
> > > > > > paperr
> > > > on
> > > > > > ontological foundations of UML (on my homepage) for further
> > > > > explanattions.
> > > > > >
> > > > > > Of course, all general ontological isssues of the part-whole
> > > > > relationship
> > > > > > apply to all things, no matter if they are agents or objects.
> > > > > >
> > > > > > -Gerd
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Modeling mailing list
> > > > Modeling@www.fipa.org http://fipa.org/mailman/listinfo/modeling
> > > >
> > >
> > >
> >
>
>
>