[Modeling] Class Diagram Specification

[Marc-Philippe Huget]

Hello Paola and all,

Paola Turci wrote:

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

Actually, what I would like to mean by that is: defining class diagrams for
object systems is not the same than defining class diagrams for agent systems
because we don't directly handle attributes, for instance we use (believe self
(a == 10)), then we describe in terms of attributes later...

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

crudely speaking, I would like to say that we have two levels: agent level
where we handle beliefs, knowledge and an "object" level where we write the
translation of this agent level into something that can be depicted as a class
diagram. Does it help?

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

Personally, I think an agent class is translated into several classes,
Classifier I didn't think about that, I will check but if class and agent class
are sibiling that will be a problem in my opinion since agent class is higher
level

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

By roles and groups, I refer to Ferber's and Odell's definition, just check the
paper "Roles of Roles..." written by Jim. So, what pieces of information do you
put in the generic agent? If it is just the agent ID, our generic agent will be
ridiculous and cumbersome. Why do you think that an agent has not necessarily a
role and a group? Could you give some examples?

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

I understand your point, that's right "derived" may not be the correct word and
above all, if we delete all the information in the generic agent, let's say
templates

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

Thanks too for your comments

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