[Modeling] Class Diagram Specification

[sehl mellouli]

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
> 
> 
> --
> Marc-Philippe Huget
> 
> Agent Applications, Research and Technology Group
> Department of Computer Science
> University of Liverpool
> Chadwick Building, Peach Street
> L69 7ZF Liverpool
> United Kingdom
> 
> email: mph@csc.liv.ac.uk
> http://www.csc.liv.ac.uk/~mph
> 
> 
> 
> _______________________________________________
> Modeling mailing list
> Modeling@www.fipa.org
> http://fipa.org/mailman/listinfo/modeling


-- 
Mellouli Sehl
Computer Science Engineer
Information Systems Administration MBA
Computer Science Phd Student
Université Laval, Québec, P.Q, Canada
Tél: bur (418) 656-2131 (4704)
Home page: http://www.ift.ulaval.ca/~mellouli