[Modeling] Class Diagram Specification

[Dr. Hong Zhu]

We certainly need a 'class diagram' for multiagent systems, in my opinion.
The question is what is 'agent class' as Marc-Philippe asked. I would like
to say that 'agent class' is quite different from object class. First,
multiple classification and dynamic classification play such a vital role in
agent class that they cannot be ignored in agent-oriented modelling because
they are essential for role models. Second, 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 different from object's agregation, in
which an object as a part of agregation exists when the whole object is
distroyed, however, it the class membership of the object does not change.
Due to the autonomy of agents, this new type of whole-part relationship will
be common in agent oriented modelling. Therefore, we need an additional
whole-part relation for this, which is called 'associate' relation in my
language CAMLE (Caste centric agent modelling language). Therefore, I think
we need a new classifier.

As for the name of the new classifier, I would like to suggest a new name
instead of using 'agent class' or 'agent type', which I find that many
people who is not familiar with agent technology but have background in
object orientation often get confused, when we explain that 'agent class is
not class'. In UML, we already have two classifiers, type for classifying
data, and class for classifying objects. I believe that people in this
mailing list would agree that agent is significantly different from objects.
Then, why not have a new name for classifying agents (the new type of
entities)?

The second question is: Do we need yet another classifier for roles? In a
paper titled 'Representation of Role models in Caste', I discussed how to
represent role models in caste (my name for agent class). My opinion is that
agent class is sufficient to model roles if it has the features of dynamic
classification, multiple classification, and 'autnomous associate'
whole-part relations. It is my second reason why I use caste as the name of
agent class, so that it can be read both as the type of agents and also the
roles that the agent plays.

A 'class diagram' like this would be able to specify the static
relationships between roles, but also depict certain dynamic relationships
between agents and roles, if how agents would change their roles are
represented in the same diagram.

Best regards,
Hong



----- Original Message ----- 
From: "James Odell" <email@jamesodell.com>
To: <modeling@fipa.org>
Sent: Sunday, June 08, 2003 7:46 PM
Subject: Re: [Modeling] Class Diagram Specification


> So, if an agent is primarily composed of roles, would a component diagrams
> be a good for to express this?  We would still need a "class" that defines
> the non-role essence of agent-ness.  Or, would the agent "class" define
all
> the basic support notions for an agent and contain all of the acquired
> roles, as well?
> A major logical problem I have is that a particular agent can be an
instance
> of multiple roles, in multiple groups.  In other words, Agent A can be an
> instance of multiple classes.  While this is a normal concept for us
humans,
> most languages do not directly support multiple classification.  In other
> words, it is the *same* instance -- with the same name and structural
> /behavioral propensities -- that is also an instance of other classes
> (roles).  Furthermore, the basic agent-ness is still preserved
(inherited?)
> within the roles.
> If we are going to support a society as Sehl describes, such
considerations
> need to be addressed -- IMO, of course.
>
> -Jim
>
>
> On 6/4/03 7:44 PM, sehl mellouli scribed:
>
> > Hello all,
> > We need to define an Agent Diagram (I will not use the term class
> > diagram since agent is not a class!!). My view concernig this diagram is
> > as follows:
> >
> > We need to design a Multi-Agent System to do some tasks. These tasks can
> > be grouped semantically together to form roles. We can see a role as a
> > set of tasks (and that's the case in general). these different roles are
> > related with each other.  we can define social relations, control
> > relations, etc. For example, a professor role has relations with program
> > director role that has also relations with department chief role.
> > Relations between roles are static, always, for a long period of time.
> >
> > Agents are assigned roles. A person agent A is assigned two roles that
> > are professor and program director. another person agent B is assigned
> > department chief role. In that case the two agents relations can be
> > deduced from their roles relations. After three months, agent A is no
> > longer program director. Its roles have changed and so its relations
> > with agent B. But again, the new relations can be deduced from roles
> > relations.
> >
> > What I want to say is: we can propose, in the first level proposed by
> > Marc-Philippe, a role diagram, that represents reltions between roles
> > such as social relations, control relations, collaboration relations
> > etc. In the agent diagram we propose first a mechanism to assign roles
> > to agents, and then deduce agent relations from those of their roles.
> > Doing so, I think we hold both static and dynamic multi-agent systems.
> >
> >
> > I'm writing a paper in this sense and I will make it available for the
> > mailing list when it will be submitted.
> >
> > Best regards,
> >
> > Marc-Philippe Huget wrote:
> >> Hello all,
> >>
> >> Since now my duty on interaction diagram specification is almost
> >> finished (for the first version waited for June, 1st, I think the
> >> current version will be issued soon after proof-reading and the like),
I
> >> have plenty of time to work on class diagram specification that was
> >> really bad considered by me... Sorry for that.
> >>
> >> Well, here are my feelings around class diagrams. I would like to share
> >> them with you to know if you agree with me:
> >>
> >> Class diagrams for object systems are "easy" to do, you write the
> >> attributes, the methods, the associations and it is finished, for sure,
> >> we cannot apply the same recipe for agents since usually you don't
> >> handle String k1 = "believe self (a = 10)" but (believe self (a = 10)).
> >> My idea is the following, we need to distinguish two levels in class
> >> diagram specification: the first level is the one, we always consider
> >> knowledge, acquaintances, roles, groups, protocols, etc. and we have a
> >> second level where we describe those elements in a "computable" manner,
> >> see the example above, the first level is at design level, the second
> >> one is at implementation level, and above all, we need to give recipes
> >> to help designers moving from the first level to the second one.
> >> Moreover, that would be an utopia to say: we know all the different
> >> kinds of agents that could be implemented as a consequence, we need to
> >> offer in this class diagram specification: some "agent template" and
> >> elements to fulfill these "templates".
> >>
> >> So, here is the plan I would like to follow:
> >>
> >> Class diagram specification:
> >> 1. Scope
> >> 2. What is an agent? I know this question is a lot of pain for
everybody
> >> but at least we need to explain what this specification covers
> >> 3. "Generic agent description", there are many different agent types
but
> >> at least, they all share some elements in common: agent id, role and
> >> group, this generic agent will have these elements and all the
different
> >> kinds of agents will be a derivation of this one
> >> 4. Elements for agent description: beliefs, knowledge, ontologies,
> >> protocols, etc. This section will present how to describe all these
> >> elements to be included in the agent class diagram.
> >> 5. Derived agent types: reactive agents, BDI agents, mobile agents,
etc.
> >> This section will present how elements from Section 4 will be used and
> >> included in agent class diagram to give a specific kind of agents.
> >> It means that the end user that would like to create a BDI agent will
> >> read Section 5 on BDI agents, then s/he will take description of
> >> elements in Section 4, then includes them in the class diagram, then
> >> adds other features.
> >>
> >> Until now, we were in the design level, we now move to the
> >> implementation level  When I speak about implementation level , I refer
> >> to the fact that I would like to have a design level oriented to agent
> >> description and an implementation level where it is possible to
> >> represent agent features as usual UML class diagrams if possible
> >> 6. Implementation level. For instance, a belief is an object instance
of
> >> a class X where there are Y attributes, the believer from the design
> >> level is the attribute String Z, etc.
> >>
> >> That's my idea so, since we are late to provide the class diagram
> >> specification (my fault), I would like to have a prompt answer from you
> >> about several points:
> >>
> >> 1. Design level/Implementation level: pros and cons, why?
> >> 2. Document structure
> >> 3. Elements that would be provided within agents
> >>
> >> As soon as we have a clearer view, I can begin to write even if some
> >> parts are already done. Thanks in advance for your help.
> >>
> >> Cheers,
> >> Marc-Philippe
> >>
>
> _______________________________________________
> Modeling mailing list
> Modeling@www.fipa.org
> http://fipa.org/mailman/listinfo/modeling
>