capabilities 1/3

Extending the Capability Concept for Flexible BDI Agent Modularization

Lars Braubach,Alexander Pokahr,Winfried Lamersdorf
Distributed Systems and Information Systems
Computer Science Department,University of Hamburg
Vogt-K?lln-Str.30,22527 Hamburg,Germany
{braubach|pokahr|lamersd}@informatik.uni-hamburg.de

Abstract.Multi-agent systems are a natural way of decomposing complex systems into more manageable and decentralized units.Nevertheless,as single agents can represent complex subsystems themselves,software engineering principles for the design and implementation of coherent parts of single agents are necessary for producing modular and reusable software artifacts.This paper picks up the formerly proposed capability concept for structuring BDI agents in functional clusters,and generalizes and extends it to support a higher degree of reusability.The resulting mechanism allows for designing and implementing BDI agents as a composition of configurable agent modules(capabilities).It is based on a black-box approach with export interfaces that is in line with objectoriented engineering principles.

1 Introduction
One important traditional software-engineering principle is modularization[12],which means that functionality is packaged into delimited units.Thereby,referring to[6]a module is seen as“[...]a well-defined component of a software system that provides a set of services to other modules.Services are computational elements that other modules may use.”
For example,in the imperative paradigm modules represent collections of procedures,data types and constants from which only a small subset is made accessible through the module’s export interface.For other paradigms such as functional programming or object-orientation adapted forms of modularization have been developed as well.Generally,modularization achieves inter alia the
following three advantages:First and most importantly,it enables reuse and extensibility of software artifacts as modules form separate units of functionality. Secondly,modules enhance flexibility through encapsulation,because changes inside a module should not affect other odules.Thirdly,modularization increases the effectiveness of software development and the comprehensibility of the applications as separate modules represent abstractions that can be considered independently for understanding cutouts of the system.
To achieve those advantages in practice,fundamental design principles have to be taken into account for module creation.On the one hand the couplingof different modules(interrelationships)should be minimized,whereas on the other hand the cohesion of the elements contained in a module should be maximized[17].The basic idea of modules is to abstract from implementation details through information hiding[12],which means that the internals of a module are encapsulated and can therefore be changed without affecting other modules.Adhering to these principles ensures that modules represent self-contained,reusable entities for some well-defined functionality.
For the agent paradigm modularization is also an important topic.Even though multi-agent systems are a natural technique for decomposing complex scenarios into autonomous actors,the resulting agents can still be fairly complex. Breaking down such complex agents into teams of smaller ones is not always an appropriate solution,because splitting up a self-contained entity requires a connection between those smaller agents to be established at the communication level,leading to possibly ineffcient solutions.
Hence,specifically adapted concepts for structuring the internals of an agent are necessary.Such a structuring technique depends in turn on the considered agent architecture determining the high-level elements and processes which may or may not be suitable for modularization.Cognitive architectures such as 3APL[4],BDI[15]or SOAR[11]propose different high-level abstractions leading to possibly different modularization approaches.In this paper Busetta et al.’s capability concept[3]for modularization of BDI agents is taken up and extended to support more flexible agent configuration.
In the next section the original capability concept is shortly sketched and its limitations are described.In section 3 the extended capability concept is proposed and its implementation within the Jadex BDI reasoning engine is described in section 4.The concepts are further clarified by an example application in section 5.A summary and an outlook of future work conclude the paper.
2 Capabilities Revisited
The capability concept for structuring BDI agents in modules and its implemen-
tation within the JACK agent framework[8]was first described in[3].The main
idea of the original proposal is to define beliefs,goals and plans that functionally
belong together in a common namespace called capability.In addition,scoping
rules allow for an exact specification of the parts of a capability that should be
visible from the outside.According to[3]a capability is defined as:
1.an identifier(that is,a name);
2.a set of plans;
3.a fragment of the knowledge base concerning the beliefs manipulated by the
plans of the capability;
4.the visibility rules for those beliefs,that is,which ones are restricted to the
plans of the capability and which ones can be seen from the outside;
5.which types of events,generated as a consequence of the activity of the
capability are visible outside its scope,and their processing algorithm;Fig.1.Original capability concept
6.which types of events,generated outside the capability,are relevant to the
capability(that is,to one or more of its plans);
7.finally,recursive inclusion of other capabilities.
Each capability type specified in this way can be included in another capabil-
ity or in the agent.For this inclusion an additional symbolic name has to be
provided to allow multiple usages of one capability type within the same con-
text.This is similar to the usage of a class in an object-oriented language,i.e.
the symbolic name identifies a specific instance.In Fig.1 the main ideas of the
original capability concept are also illustrated graphically.The interface of the
inner capability is defined by means of the(di?erent kinds of)external events
the inner capability can process and also by those exported events that could be
handled in the outside capability.In addition beliefs of the inner capability can
be made visible for the outer capability,while plans are only visible locally.
As an example,in[3]negotiation functionalities for two types of agents par-
ticipating in a negotiation are described(initiator and bidder).These function-
alities can be encapsulated in two capabilities and reused by all agents which
like to take part in a negotiation.
2.1 Limitations
The original capability concept as outlined above allows for grouping mental
attitudes according to their functional purpose and therefore is an e?ective tech-
nique for modularization.Nevertheless,this approach exposes some conceptual
limitations that are discussed next:
–Concerning the export interface,the approach distinguishes explicitly be-
tween mental attitudes and treats them in a di?erent manner.This meansthat there is no continuous mechanism for all types of elements.So,for events
the propagation(from the outside/to the outside)is relevant,for beliefs the
visibility can be defined(local vs.external)and for plans only their usage can
be declared.Having specific means for each of the elements to be grouped
inside a capability not only renders the mechanism hard to learn and use,it
is also not easily possible to adapt the reusability mechanism to other mental
notions,be it extensions to the BDI model or alternative mental models.
–Another important limitation of the approach is concerned with parametriza-
tion as only the static structure is considered.Besides the static structure
the initial mental state of a capability respective an agent is of major im-
portance.In the current form,capabilities cannot be configured with some
initial mental state,which hinders flexible reuse.
–Only design-time composition has been taken into account.No work has been
done so far regarding the possibilities of dynamic agent behavior modification
by adding/removing or exchanging capabilities at runtime.In this respect a
model would have to be provided,how the addition or removal of a capability
influences the functionality of other capabilities.
–The concept does not allow for refinement of parts of a capability specifica-
tion.E.g.it is not possible to provide an extended context condition for a
plan.Elements have to be used in exactly the way they are defined in the
inner capability,which hinders flexible reuse.
3 Extending the Notion of Capabilities
This section presents a capability concept,suitable to address the aforementioned
shortcomings.It follows the general idea of a capability being“[...]a cluster of
plans,beliefs,events and scoping rules over them”[3],but di?ers from the original
capability concept in several important ways.
1.The locality principle assures that all elements of a capability are part of
exactly one capability.
2.A general import/export mechanism is introduced to define which elements
are part of the capability’s interface and are visible from the outside.Ele-
ments contained in the interface can be used in the containing capability by
defining local proxy elements.
3.A creation semantics determines which element instances of a static struc-
ture(composed of a single concrete element type and arbitrarily many prox-
ies)are created at runtime.
4.The explicit specification of initial configurations separately to the static
structure of a capability is supported.
5.The foundations of dynamic capability modifications are layed down.
These extensions are discussed in the following sections.Fig.2.Reference concept
3.1 Locality Principle
The original capability concept assumes a global repository of mental elements
(i.e.event or plan type specifications)which are then just referenced in a ca-
pability definition.Therefore the same type of element can be used in di?erent
capabilities or even agents(i.e.for sending and receiving message events).
In our model we follow the locality principle of elements which means that
a capability itself defines the available types(e.g.of beliefs),and forms the
namespace for these types.These element types are not globally available,but
only inside the capability.As a consequence e.g.from within plans only locally
defined beliefs are accessible,which means that it is not su?cient to know that
a belief of a contained capability is exported.To be able to use such a belief a
local reference has to be declared.
Following the locality principle has the main advantage of increasing the
transparency.This is because e.g.a plan only depends on local elements and not
on elements defined in a subcapability.Changes with respect to a subcapability
are therefore hidden from the plan.Another advantage concerns the openness of
agent applications.As no global elements such as message events are specified,
each agent can interpret a received message in its own respect,not depending
on message representation details of other agents.
3.2 Import/Export Mechanism
The locality principle requires a newly designed import/export concept.For
usability,all mental notions and their interrelations across capability borders
should be defined using the same mechanism.The main idea is to cleanly dis-
tinguish relationships between di?erent mental elements(such as a certain goal
being handled by a certain plan)from the import and export specifications
that relate elements from di?erent capabilities.Relationships between mentalelements follow the locality principle,and therefore are only allowed inside a
capability.Import and export specifications permit a single logical element to
be present in several connected capabilities using a proxy model(see Fig.2).
The figure shows how a capability(outer)can reuse functionality from another
(inner)capability.Concrete elements(which may be beliefs,goals,etc.)are pre-
sented as white rectangles.Proxy elements(i.e.placeholders for beliefs or goals
of another capability)are shown as grey rectangles.
Per default,any concrete element is internal,meaning that it is only visible
locally in its enclosing capability.E.g.internal beliefs can only be accessed by
plans of the same capability.If an element should be accessible to the outer
capability it can be marked as exported.To be used from the outside,a place-
holder(called reference)for the original element has to be defined in the outer
capability.The reference element specification includes the relative name of the
inner element it refers to(e.g.in the form“subcapability.elementname”).Note
that references to exported inner elements are optional.An outer capability is
only required to provide a reference,when the element is accessed from other
elements of the outer capability.For example when a plan of the outer capabil-
ity wants to access a belief defined in the inner capability,the outer capability
defines a belief reference,which acts as a proxy for the inner belief.The plan
accesses the proxy like it would access a locally defined belief.Therefore,it is
transparent to the plan that the belief is actually defined in the inner capability.
A capability may also include abstract elements,i.e.proxies which are not
assigned to any concrete element by themselves.An abstract optional element
is an element,which does not require an assignment,what means that the func-
tionality of the capability can also be used,when this element is not present.For
example,an abstract belief provides an extension point,where the outer capa-
bility can add knowledge to the inner capability.A plan in the inner capability
can then check if the belief is available and proceed in di?erent ways according
to the information from the belief.An abstract required element is an element,
which is required for proper operation of the capability.
Both required and optional abstract elements are assigned from the outside,
by adding“assignto”specifications to concrete elements of the outer capability.
An outer element may be assigned to many di?erent abstract elements,but an
abstract element must be assigned from(at most)a single concrete element.In
addition,it is also possible to define proxies for proxies,i.e.to define a reference to
an element which is itself a reference,or to assign an abstract element to another
abstract element of a child capability.This allows building up reference structures
through multiple levels of capabilities.E.g.in the figure,the outer capability
might choose to re-export elements referenced from the inner capability.
3.3 Creation Semantics
The proxy concept introduced in the last section shows how an element can
be visible in a di?erent capability.The definition of proxies only specifies a
static structure of references for element visibility.It depends on the creation
context,if an instance of a proxy is created for a specific element instance.It