[Modeling] Class Diagram Specification

[Paola Turci]

Hi Marc-Philippe and everybody,
thank you for the valuable contribution you are giving: we, Giovanni Rimassa
and I, took some time to read it and had some thoughts over it. Now we have
gathered some comments that we would like to share with the FIPA modeling
TC. Inline comments follow.

Marc-Philippe 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)).

What exactly do you mean with that? The first expression is a Java String,
but
what is the second one supposed to be? A String-encoded S-expression? A Java
structured
tree of objects representing the formula? A Prolog clause?
We think it is important to be clear about this because our possible
misunderstanding of
your example could easily lead to a completely misaligned communication.

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

Again, it's not that a String is more 'computable' than, say, a Believe
class or an implicitly
defined belief base made by a List of instances of Predicate class (where
e.g. each concrete predicate
actually contains the syntax tree representation of its formula). We agree
with your purpose of moving
from a more abstract architectural design specification towards a more
detailed one.
However, it's not really clear to us how you propose to define and
characterize these two levels.
Unfortunately, as we wrote above, your example is not helping us. Could you
please elaborate on that?

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

We agree with this one; we would also like to point out that there are
several well-known agent architectures, so it would be nice to provide some
kind of ready-made support for them (i.e. if you choose a BDI or vertically
layered architecture you can save some specifications and reuse a template,
but if you roll your own architecture then you will describe it using a
lower abstraction layer, that is classes).


> 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

Actually, the correct question here would be "what is an agent class";
moreover, it is by no means obvious that an Agent Class has to be a Class,
because being a Class in the UML metamodel raises quite a few issues related
to fundamental object-oriented tenets that do not necessarily apply to
autonomous software components (more on this follows). Looking at the UML
2.0 specs, we noticed that Classifier now is a richly defined element:
wouldn't it make sense to define AgentClass as a direct subclass of
Classifier (so that it is a sibling of Class)? This way, we could do without
all the object-oriented semantics commonly associated with Class that does
not really apply to AgentClass. Any opinions?

Anyway, we think that since this is going to be a part of the FIPA
specification, we should not try to be overly general but simply cover the
FIPA definition and specification of an agent, which is not a mere label but
is to be inferred from the whole set of specification (i.e. a FIPA agent can
communicate with FIPA ACL complying with its semantics, can use FIPA
ontologies, can participate in FIPA interaction protocols and the like).

> 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

We are OK with the 'generic' idea, but we don't think that an agent has to
have a role or a group (what do you mean by 'role' and 'group', by the
way?). As far as basic FIPA compliance is concerned, an agent must have an
agent ID; the role and group attributes are not mandated and should not be
part of the 'generic' agent definition.

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

That's OK with us.


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

We have some problems here. First, the three category examples you gave are
not comparable: the 'reactive agent' category is defined in terms of the
agent observable behaviour, 'BDI agent' is an actual internal architecture
and 'mobile agent' is a deployment information. One can have a reactive,
mobile BDI agent. Maybe you meant 'FSM based' instead of 'reactive'?
Second, and more important, what do you mean with 'derived'? We believe that
subtyping and inclusion polymorphism (two cornerstones of object
orientation) *do not* apply to agents. This is because agent classes are
active (their 'isActive' attribute is set to true), and Design by Contract
states that when method invocation and method execution threads differ you
cannot apply method preconditions any longer (they cease to be correctness
preconditions and become waiting guard predicates).
Therefore, it's not meaningful to define a generalization association where
BDIAgent is a subtype of GenericAgent, because there are no publicly
callable methods in GenericAgent with meaningful pre- and post-conditions.
To check the above statements, please refer to B. Meyer, Object-Oriented
Software Construction, 2nd Ed. Chapter 30 (particularly the separate feature
call proof rule in section 30.10).

Our point is that it is OK to provide agent templates and ready-made agent
architectures, but the extension mechanism should not be class
generalization.
Ideally, we would like to express the requirement 'an agent must have an
agent architecture' at the GenericAgent level, and then provide the
ready-made options (FSM, Petri Net, BDI, various layered architectures,
etc.) along with the guidelines on how to describe custom agent
architectures (using the elements you mentioned in point 4). Has anyone got
a proposal about how to achieve this? Should we use an extended classifier
with template parameters? Should we define an AgentArchitecture abstract
class and a 'use' association between GenericAgent and AgentArchitecture?


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

We agree with that (actually the believer should be a structured Agent ID),
and we also think that we should coordinate work on class diagrams with the
Modeling Area 'Single vs. Multi-Agent' where we are currently tackling the
modeling of implementation-level elements in MASs.

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

We hope we have provided meaningful observations in the above.
Thank you for your help and let us know if you have comments.

Paola and Giovanni


> As soon as we have a clearer view, I can begin to write even if some

<SNIP>

> Modeling@www.fipa.org
> http://fipa.org/mailman/listinfo/modeling