[Modeling] Class Diagram Specification

[James Odell]

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
>>