[Modeling] Class Diagram Specification

[James Odell]

Hi Hong,

Thank you for your thoughts on this topic.  Am not sure how the current UML
metamodel violates your notions of multiple and dynamic classification or
aggregation/composition.  Perhaps you could propose a model that would
extend the UML metamodel that would support you notions.  That would be very
helpful.

Cheers,

Jim


On 6/9/03 7:09 AM, "Dr. Hong Zhu" indited:
> 
> 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
>>>>