[Modeling] Class Diagram Specification
Mon, 26 May 2003 11:54:29 +0100
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:
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.
Agent Applications, Research and Technology Group
Department of Computer Science
University of Liverpool
Chadwick Building, Peach Street
L69 7ZF Liverpool