BOCHICA: A MODEL-DRIVEN FRAMEWORK FOR

ENGINEERING MULTIAGENT SYSTEMS

Stefan Warwas, Klaus Fischer, Matthias Klusch and Philipp Slusallek

German Research Center for Artiﬁcial Intelligence (DFKI), Campus D3.2, 66123, Saarbr

ucken, Germany

Keywords:

Agent-oriented software engineering, Modeling framework.

Abstract:

Modeling real world agent-based systems is a complex endeavour. An ideal domain speciﬁc agent modeling

language would be tailored to a certain application domain (e.g. virtual worlds) as well as to the target execu-

tion environment (e.g. a legacy virtual reality platform). This includes the use of specialized domain concepts,

information models, software languages (e.g. query languages for reasoning about an agent’s knowledge),

as well as custom views and diagrams for designing the system. At the same time it is desirable to reuse

application domain independent model artifacts such as interaction protocols (e.g. auction protocols) or goal/-

plan decompositions of a certain problem domain that already proved their use in similar scenarios. Current

agent modeling languages cover the core concepts of multiagent systems but are neither thought to be cus-

tomized for a certain application domain nor to be extended by external researchers with new or alternative

AI and agent concepts. In this paper we propose a model-driven framework for engineering multiagent sys-

tems, called BOCHICA, which is based on a platform independent core modeling language and can be tailored

through several extension interfaces to the user’s needs. The framework leverages the reuse of existing design

patterns and reduces development time and costs for creating application domain speciﬁc modeling solutions.

We evaluated our approach on a distributed semantic web based execution platform for virtual worlds.

1 INTRODUCTION

The research ﬁeld of Agent-oriented Software Engi-

neering (AOSE) is concerned with investigating how

algorithms and methods developed in the wide area of

Artiﬁcial Intelligence (AI) can be used for engineer-

ing intelligent software agents in a systematic way.

AOSE should not be seen in isolation: As it gets in-

creasingly applied in main stream software engineer-

ing it is confronted (of course) with typical problems

of today’s software development such as (i) an in-

creasing number of software frameworks, program-

ming languages, and execution platforms, (ii) shorter

development cycles, and (iii) heterogeneous and dis-

tributed IT environments. A key to tackle the rapidly

growing complexity in software development is ab-

straction. Higher-level software languages are re-

quired to hide the complexity and focus on the de-

sign of IT systems. Model-driven Software Devel-

opment (MDSD) is driven by industry needs to deal

with complex software systems. The underlying idea

of MDSD is to model the System Under Consider-

ations (SUC) on different levels of abstractions and

use model transformations to gradually reﬁne them

until concrete code can be generated. Several core

aspects of MDSD were standardized by the Object

Management Group (OMG) as Model-driven Archi-

tecture (MDA).

During the recent years, several approaches for

modeling agent-based systems have been proposed

(Sterling and Taveter, 2009). Although we think that

the developed modeling languages are a step into

the right direction, they have problems with fulﬁll-

ing a user’s need to efﬁciently model a certain appli-

cation domain. An ideal modeling language would

contain, beside the core concepts of Multiagent Sys-

tems (MAS), speciﬁc concepts, software languages,

graphical representations, etc. for a certain target en-

vironment. Moreover, it is desirable to extend the

modeling language with new concepts from AI and

agent research (e.g. new ways of modeling behav-

iors). In this paper we propose a model-driven frame-

work for engineering agent-based systems to over-

come the mentioned limitations. Our framework,

called BOCHICA

, is based on a core Domain Spe-

ciﬁc Language (DSL) which covers the main aspects

Bochica was a semi-god of the Muisca culture who

brought them living skills and showed them how to orga-

nize their lives.

109

Warwas S., Fischer K., Klusch M. and Slusallek P..

BOCHICA: A MODEL-DRIVEN FRAMEWORK FOR ENGINEERING MULTIAGENT SYSTEMS.

DOI: 10.5220/0003741901090118

In Proceedings of the 4th International Conference on Agents and Artiﬁcial Intelligence (ICAART-2012), pages 109-118

ISBN: 978-989-8425-95-9

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

of MAS (see Figure 1). The framework provides sev-

eral interfaces for new concepts, methods, and 3rd

party software languages. We envision BOCHICA as a

bridge between agent research and software develop-

ment. The customizations allow the user to deﬁne the

right level of abstraction for his application domain

without loosing the integration into a larger frame-

work which enables the exchange of model artifacts

such as goal hierarchies and interaction protocols.

!"#$%&' ($"%)*

+,"-#

+).$/#".#0)"

+112/.3#/%-

4%53/-

+,"-#67%)"

489

:%.$/.36;)35"<%)=

Figure 1: The BOCHICA framework for AOSE is based on

a platform independent core DSL and is able to integrate

research results, methods, and application domains.

The ﬁrst part of this paper provides background

on previous work (Section 2), introduces the general

idea of the BOCHICA framework (Section 3), and pro-

vides on overview of the extension interfaces (Sec-

tion 4). The second part shows how to customize the

framework for creating an application domain speciﬁc

agent development environment for semantic virtual

worlds (Section 5). Finally, Section 6 discusses the

related work and Section 7 concludes this paper.

2 BACKGROUND

Raising the level of abstraction in software develop-

ment was always an important driver in computer sci-

ence research. The level of abstraction of a software

language can be deﬁned as the distance between the

computer hardware and the concepts of that language

(Kleppe, 2008). Since the invention of computer sys-

tems, the level of abstraction was steadily increased

from opcodes, assembler languages, procedural lan-

guages, up to object-oriented languages. The ques-

tion that arises is how the next higher level of abstrac-

tion looks like. According to (Kleppe, 2008), “The

challenge for language engineers is that the software

languages that we need to create must be at a higher

level of abstraction, a level we are not yet familiar

with. They must be well designed, and software de-

velopers must be able to intermix the use of multiple

languages. Here too, we are facing a new, unknown,

and uncertain task.” In the agent community, AOSE

has been seen as a natural successor of OOSE for a

long time. Several articles discuss why AOSE has

not arrived yet in mainstream software engineering

(Belecheanu et al., 2006)(Jennings and Wooldridge,

2000)(McKean et al., 2008). Three of the identiﬁed

main problems are (i) misunderstandings or wrong

assumptions by non-agent experts, (ii) agent-oriented

standards and methods are not yet sufﬁcient for in-

dustry needs, (iii) lack of powerful tools. However,

regarding the level of abstraction (Belecheanu et al.,

2006) concludes: “With concepts such as roles and

responsibilities, agent-oriented approaches to prob-

lem and system description are much closer to the

ways in which managers conceive of business do-

mains than are traditional software engineering de-

scriptions.” This matches the requirements stated by

Kleppe. Our research hypothesis is that agent tech-

nology can embody concepts like goals, roles, and

organizational structures in order to build modeling

languages of the next higher level of abstraction.

The model-driven framework presented in this pa-

per is based on the Domain Speciﬁc Modeling Lan-

guage for Multiagent Systems (DSML4MAS) (Hahn

et al., 2009). DSML4MAS is a platform indepen-

dent graphical modeling language and covers the

core aspects of MAS, such as agents and organi-

zations, interaction protocols, goals, behaviors, de-

ployment aspects, etc. Its abstract syntax is de-

ﬁned by the Platform Independent Metamodel for

Agents (PIM4AGENTS). Object Constraint Lan-

guage

(OCL)-based constraints are used for validat-

ing PIM4AGENTS models. Model validation on a

platform independent level already prevents many er-

rors in early phases of a project. DSML4MAS is plat-

form independent but it inherently possesses different

degrees of abstraction. The requirements layer is the

most abstract degree and covers abstract goals, roles,

interactions, and organizations. The system design de-

gree contains (i) agent types, (ii) behavior templates,

(iii) concrete goals, etc. The lowest degree is the de-

ployment layer which speciﬁes concrete deployment

conﬁgurations (e.g. agent instances and resources).

The platform, domain, and methodology independent

nature of DSML4MAS makes it the perfect language

for building an extensible framework around it. For

this purpose, we introduce the overall idea behind

BOCHICA and present the made extensions.

3 FRAMEWORK OVERVIEW

Before we go into the technical details, we present

the overall vision of how we think that large scale

agent-based software should be developed using the

http://www.omg.org/spec/OCL/2.0/PDF/

ICAART 2012 - International Conference on Agents and Artificial Intelligence

110

BOCHICA framework.

3.1 Stakeholders

The application of the BOCHICA framework requires

the interplay of different stakeholders. In the follow-

ing we characterize the involved parties and deﬁne

their tasks.

Agent Researcher. The research area of MAS is still

young and many concepts are still under research.

The task of the agent researcher is threefold: (i) new

concepts and methods have to be developed, (ii) re-

search results regarding properties or limitations of

model elements (such as interaction protocols) have

to be integrated into model repositories, and (iii) our

framework needs to be grounded in a theoretical agent

framework to bridge research and software develop-

ment.

Language Engineer. Since BOCHICA is based on a

DSL, the language engineer is responsible for extend-

ing it with new concepts. Detailed knowledge of the

core DSL is required to align new concepts to exist-

ing ones. We distinguish between language engineers

who further develop the core modeling language and

those who create 3rd party plug-ins. The language en-

gineer has to choose the right level of abstraction for

the conceptual extensions.

Tool Developer. The tool developer is responsible

for building the development environment based on

BOCHICA. This includes (i) writing model trans-

formations (ii) creating new or extended diagrams,

and (iii) providing further usability extensions such

as wizards and additional tools. He has to make sure

that the tools and transformations cover the (required)

functionality of the target platform.

Agent Engineer. The agent engineer is the end user

of the development environment. According to his

needs, he installs the required plug-ins and uses an

agent methodology to design a MAS for a certain sce-

nario. He uses a model repository to cooperate with

colleagues and reuses existing model artifacts. The

agent engineer is also responsible to reﬁne the gener-

ated code where necessary.

3.2 Customization

In our opinion, the assumption that one metamodel or

DSL can cover the whole spectrum of agent-based ap-

plications is not realistic. The platform independent

core modeling language of our framework contains

generic concepts that are relevant for a wide area of

agent-based applications (interaction protocols, orga-

nizational structures, behaviors, etc.). However, for

many application domains it is desirable to specialize

these concepts in order to improve the expressiveness

of the models (e.g. for modeling agents for virtual

worlds, electronic business, or agent-based simula-

tion). It might also be the case that agent researchers

want to integrate their research results by providing

plug-ins that extend BOCHICA with new concepts

(e.g. commitments or new agent architectures). What

we want to prevent by the extension mechanism is that

the core DSL gets cluttered by concepts that are only

relevant for a small sub-set of applications. The ben-

eﬁt of BOCHICA is that the mature core can be reused

in many application domains and only needs punctual

extensions. The same applies to model transforma-

tions which are used to produce executable code for a

certain execution environment. Existing transforma-

tions can be reused and only need to be extended for

the changed aspects. Our vision is that the core of

our framework will evolve over time in a community

process where other researchers can contribute their

ideas on how to develop MAS.

3.3 Collaboration

Our vision regarding the collaboration of agent engi-

neers is that model repositories will become available

for sharing design patterns and model artifacts such

as interaction protocols, organizational structures, ca-

pabilities, or behavior templates. For example, agent

engineers use organizational structures and and/or de-

composition trees for decomposing complex prob-

lems into sub-problems. Those patterns can be reused

as blue print for similar scenarios and execution plat-

forms. In (Warwas et al., 2011), an approach for mak-

ing the underlying design of concrete implemented

MAS was presented. Agent experts can use this ap-

proach for sharing new and validated artifacts to the

repositories which proved their use in practical appli-

cations. Currently, we are using a ﬁle-based approach

for sharing model artifacts but native model reposito-

ries are already becoming available (e.g. CDO

3.4 Theoretical Foundation

Wee see BOCHICA as a bridge between agent research

and concrete software development. Metamodels are

very well suited for discussing and aligning new con-

cepts from different research areas to each other. At

the same time, metamodels are the foundation for

MDSD. What would also be interesting is an align-

ment of BOCHICA to theoretical agent frameworks.

Research results (e.g. about the properties of a spe-

ciﬁc auction protocol) can be directly linked to model

http://www.eclipse.org/cdo/

BOCHICA: A MODEL-DRIVEN FRAMEWORK FOR ENGINEERING MULTIAGENT SYSTEMS

111

artifacts in the model repository. This information

helps engineers in constructing MAS.

4 FRAMEWORK INTERFACES

In order to customize the BOCHICA framework it of-

fers various interfaces which can be extended through

external Eclipse-based plug-ins. The remainder of

this section provides an overview of those interfaces.

Examples will be given in Section 5.

4.1 Conceptual Extension

BOCHICA can be extended with new concepts for (i)

introducing new ways of modeling existing aspects

(e.g. behaviors), (ii) introducing completely new as-

pects (e.g. commitments), or (iii) specializations for

a certain application domain or execution environ-

ment. The extension is enabled by several interface

concepts such as Agent, Interaction, Resource,

or Task that can be specialized by external plug-

ins. The beneﬁt of extending our framework in op-

posite to creating a completely new approach is that

large parts, which are common to most MAS, can be

reused. The core concepts will evolve over time and

will build a solid foundation for AOSE. As an exam-

ple of how the BOCHICA framework can be extended

is the approach for an alternative (declarative) way of

modeling interaction protocols with DSML4MAS pre-

sented in (Leon-Soto, 2009). The presented approach

extended the Interaction concept of DSML4MAS

and added custom diagrams. At the time of the

creation of the extension, BOCHICA was not avail-

able so that DSML4MAS had to be extended directly.

Now, BOCHICA provides interfaces for 3rd party de-

velopers for extending it with new concepts without

touching the core. At the same time, the extension

is integrated into the overall framework. End users

can choose which alternative to apply. Technically,

the extension mechanism is based on the Eclipse

OSGi

framework and the Eclipse Modeling Frame-

work (EMF) (Steinberg et al., 2008).

4.2 Information Model

The information model interface of BOCHICA con-

sists of four parts (see Figure 2). The core of the in-

formation model has been separated from BOCHICA

and is based on the Ecore metamodel provided by

EMF (Steinberg et al., 2008). Ecore is used to model

classes and their attributes and relations among each

http://eclipse.org/equinox/

other. The reuse of Ecore has several advantages: we

get (i) graphical modeling support (UML class dia-

gram style) and (ii) import from UML, XML schema

(including XML de-/serialization) and existing Java

code for free. Types deﬁned in an Ecore-based infor-

mation model can be made available within BOCHICA

by the concept EType (see Figure 2). On top of the

Ecore metamodel, BOCHICA deﬁnes basic data struc-

tures such as Sequence, Set, or HashMap. The third

layer consists of special purpose data structures like

the concept ProtocolContext which is used to store

information for managing the execution of an interac-

tion protocol. It is used in plans to access the current

conversation context (e.g. the participants and the cur-

rent state of the conversation). So far, we described

the types which build the interface to the outside of

the agent system. The fourth layer of the informa-

tion model are internal types such as Agent, Event,

or Goal. These internal types are required for access-

ing model artifacts inside a plan (e.g. the parameters

of a goal). The information model of BOCHICA can

be extended by external plug-ins. One use case would

be to introduce specialized data structures similar to

the ProtocolContext (e.g. specialized result sets for

querying legacy knowledge bases). Technically, the

user deﬁned data structures use the same extension

interfaces as in Section 4.1.

Figure 2: The four layers of the BOCHICA information

model interface: (1) basic Ecore types, (2) basic data struc-

tures, (3) specialized data structures, (4) internal types.

4.3 Language Interfaces

There exists a large number of software languages

that are relevant for developing agent-based systems

such as (i) knowledge representation languages (e.g.

OWL), (ii) query languages (e.g. SPARQL), (iii) rule

languages (e.g. SWRL, PROLOG), (iv) communi-

cation languages (e.g. KIF, FIPA ACL), (v) pro-

gramming languages (e.g. Java). A software lan-

guage is always developed with a certain purpose in

mind. Thus, it depends on the concrete use case

ICAART 2012 - International Conference on Agents and Artificial Intelligence

112

which one to use. BOCHICA provides abstract lan-

guage interfaces which can be extended by external

language plug-ins (see Figure 3). The main concept

is Expression. There exist several specialized ex-

pression types such as BooleanExpression, Rule, or

ContextCondition. The abstract expression types

are used throughout the framework. For example,

an AchieveGoal has a target and failure condition

of type BooleanExpression and a Plan has a con-

text condition of type ContextCondition. External

plug-ins can specialize the abstract expression types

with concrete languages. We assume that an exter-

nal language is also based on Ecore. This is not a

hard restriction since more and more software lan-

guages, such as SPARQL or Java, are becoming avail-

able in public metamodel zoos (e.g. EMFText con-

crete syntax zoo

, Atlantic metamodel zoo

). We use

a reﬂection-based approach for parsing user deﬁned

expression strings into a language speciﬁc expression

model (interface concept EObject) and assign it to

the Expression object’s object attribute (see Fig-

ure 3). This approach can be used (i) for check-

ing the syntactical correctness of an expression, (ii)

for checking whether variable symbols inside the lan-

guage model are bound in the surrounding scope, and

(iii) to process the expression models in model trans-

formations. The beneﬁt of our approach is that tech-

nical details, such as the integration of the knowledge

base and SPARQL into the concrete agent execution

platform, are hidden on the modeling level. At the

same time, models can be tailored to a certain target

environment. Of course, the integration at the plat-

form level has to be done at some point (we discuss it

later) but the agent engineer has a consistent view and

can concentrate on the design of the overall system.

4.4 Methodologies

During the recent years, several agent-oriented

methodologies have been proposed (Sterling and

Taveter, 2009). Most of the developed approaches

are supported by a graphical modeling language (see

discussion in Section 6). The focus of our approach

was always on developing an expressive platform in-

dependent agent modeling language that can be used

for model-driven development of agent-based sys-

tems and less on the methodology part. Since both

aspects are complementary, our idea is to use method-

ology plug-ins for extending the BOCHICA frame-

work. In the same way as BOCHICA can be extended

with new agent concepts, methodology providers can

contribute plug-ins with new views and methodol-

http://www.emftext.org/

http://www.emn.fr/z-info/atlanmod/index.php/Atlantic

ogy concepts. For example, the Prometheus method-

ology (Padgham et al., 2004) collects in the sys-

tem speciﬁcation phase abstract functionalities and

goals of a SUC. In the architectural design phase

the functionalities and goals are grouped to agents.

A Prometheus plug-in for BOCHICA could extend it

with the missing concepts for collecting abstract func-

tionalities in the system speciﬁcation phase (since it

is not covered by the core DSL). The architectural

design phase could be based on existing concepts of

the core DSL. As interface, BOCHICA provides the

concept MethodologyArtifact. Instead of having a

separate modeling language and tool for each method-

ology, most of the methodologies could be integrated

into one framework and share a common core. This

would join the efforts of the involved parties and

would ease the maintenance of the tool chain.

Figure 3: Expression interface of BOCHICA.

4.5 Transformations

Model transformations in MDSD are used to gradu-

ally reﬁne a model of a SUC until executable code is

generated. We assume that there exist base transfor-

mations from BOCHICA to agent execution platforms

such as Jack or Jadex. A base transformation maps the

concepts of the core DSL to executable artifacts of an

agent platform. As BOCHICA gets extended with new

concepts, an existing base transformation is no longer

complete regarding the covered concepts. Thus, an

extension transformation is required which extends

an existing base transformation for the new concepts

(if the target platform shall be enabled for the ex-

tension). We see three possibilities how this can be

achieved. Some model transformation languages (e.g.

QVT

) allow to write a new transformation which in-

herits from an existing one. Thus, an existing map-

ping rule can be overloaded by a new and extended

one. Other transformation languages like XPand

use

an aspect-orientated approach for hooking into an ex-

isting transformation and extending it. A further pos-

sibility is to chain transformations, where the ﬁrst one

is a base transformation and the succeeding one sup-

http://www.omg.org/spec/QVT/1.0/

http://www.eclipse.org/modeling/m2t/

BOCHICA: A MODEL-DRIVEN FRAMEWORK FOR ENGINEERING MULTIAGENT SYSTEMS

113

plements the result of the proceeding one. Thus, an

external plug-in for BOCHICA usually exists of (i)

conceptual extensions and (ii) an extension transfor-

mation for the required target environment (assuming

that the base transformation already exists). Main-

taining the tool chain is one of the main problems in

MDSD. Reusing existing model transformations re-

duces development costs and time and increases code

quality by using well established design patterns.

4.6 Custom Views and Tools

Views are used in graphical modeling languages to

visualize the relations of model artifacts of a cer-

tain sub-aspect of a system. BOCHICA provides stan-

dard views for agent types and organizational struc-

tures, protocols, goal hierarchies, deployment conﬁg-

urations, etc. 3rd party developers can use the exten-

sion interface for customizing BOCHICA to a certain

application domain or introduce new ways of viewing

existing aspects. Views can also help to adapt the de-

velopment environment to certain user groups. Tech-

nically, diagrams and tools can be plugged into the

framework by using the extension point mechanism

of the Eclipse OSGi framework and GMF

5 VIRTUAL REALITY DEVELOP-

MENT ENVIRONMENT

After we introduced the overall framework, we now

want to show how to apply BOCHICA to a large scale

real world scenario. Today, intelligent behavior of

avatars in virtual worlds is usually simulated by trig-

gered script sequences which create the illusion of

intelligent behavior for the user. However, the ﬂex-

ibility of those avatars is, due to their static nature,

very limited. In the research project Intelligent Simu-

lated Realities (ISReal) our research group developed

the ﬁrst simulation platform based on semantic web

technology for bringing intelligent behavior into vir-

tual worlds (Kapahnke et al., 2010). The basic idea of

ISReal was to use semantic web technology to extend

purely geometric objects with ontological information

(OWL-based; e.g. concept door links two rooms and

can be open or closed) and specify their functionality

by semantic service descriptions (OWL-S-based; e.g.

open and close door services), called object services.

Intelligent agents perceive this information, store it

in their knowledge base, and use it for reasoning and

planning. An object service is grounded in a service

implementation which invokes according animations

http://www.eclipse.org/gmf

or simulation modules. The platform consists of var-

ious simulation components which can be distributed

in a network. Before we show how we extended the

BOCHICA framework for developing ISReal agents

on the Jadex BDI platform, we introduce the main

components of the ISReal platform.

Global Semantic Environment. The Global Seman-

tic Environment (GSE) maintains the global ontolog-

ical facts of the virtual world. It is responsible for

(i) executing object services (e.g. checking the pre-

condition and invoking the service grounding), (ii)

updating facts (e.g. when a door gets closed), and

(iii) handling queries (e.g. SPARQL).

Agent Environment. The ISReal agent environment

deﬁnes interfaces for connecting 3rd party agent exe-

cution platforms to the ISReal platform (we currently

use Jack, Jadex, and the Xaitment

game AI engine).

Every ISReal agent is equipped with a Local Semantic

Environment (LSE) which is an agent’s local knowl-

edge base. The LSE stores the perceived information

and enables the agent to reason about it. Moreover,

the LSE is equipped with an AI planner.

Graphics Environment. The user interface of the

ISReal platform is realized by an XML3D

-enabled

standard web browser. The 3D scene graph is part

of the browser’s Document Object Model (DOM) and

can be manipulated using Java Script. It also contains

RDFa

-based semantic annotations of the 3D-objects

such as the concept URI, the object URI, and the se-

mantic object service URIs. Moreover, we extended

the browser with an agent sensor which allows agents

to perceive the annotated 3D objects.

An intelligent ISReal avatar consists of (i) the ge-

ometrical shape (body) and animations, (ii) a percep-

tion component, (iii) semantic annotations, and (iv)

an agent that processes the perceived information and

controls the body. Artifacts such as the geometrical

shape, animations, or ontologies are developed us-

ing specialized 3rd party tools. We decided to base

the development environment for ISReal agents on

BOCHICA and use Jadex as the target agent platform.

This has several advantages: (i) BOCHICA already

provides the core concepts, diagrams, etc. for model-

ing agent systems, (ii) we can reuse the existing base

transformation to Jadex, (iii) we only need to cus-

tomize the missing aspects of BOCHICA for creating

an individual development environment for agents in

semantic virtual worlds, and (iv) it enables the reuse

of existing model artifacts (e.g. interaction protocols).

Figure 4 depicts the big picture of how we think that

http://www.xaitment.com/

http://www.xml3d.org

http://www.w3.org/TR/xhtml-rdfa-primer/

ICAART 2012 - International Conference on Agents and Artificial Intelligence

114

!"#$%&'(%#)*+

(%,-."&%+$

!"#$%&

!'(&)*+,)!-#+$&!.-/

!01)%*+,)2#1&

!3*4+125+)2#1&

/.--01.20$).+

"#$% "#$%

6*#)#,#$

3-0+#

4.0-#

!9#1,*%)%!-#+$&!.-/

!'4%1)!:;<%&

!=%>+?2#*&

!9#$$+(#*+)2#1&

!9+<+(2$2)2%&

!01&)+1,%&

!9#1@24A*+)2#1&

!"%&#A*,%&

5%67)2%&%+$#

3*4+125+)2#1

B%)>#C&

8*%+$'9:%;7$).+'3-0$<.2&

420,=);#'9+>)2.+&%+$

4-.10-'!%&0+$);'9+>)2.+&%+$

?1@%;$

!%2>);%#

:*2<$%!D)#*%

?+$.-.*)%#

;

)

;

)

5%0#.+%2

B!9 B!9

C!5%0-'8*%+$#

D,%1%

-*+<>

!%+#.2

8++.$0$).+#

)

=39H09'!I*+E%J#*K

Figure 4: The bottom layer depicts the components of the ISReal platform. The upper central part shows the inherent degrees

of abstraction of BOCHICA. The left an right hand side represent the interfaces for extending the framework.

intelligent agents for the ISReal platform should be

developed. For a detailed introduction to the ISReal

platform we refer to (Kapahnke et al., 2010). The re-

mainder of this section discusses the extensions of the

BOCHICA framework for developing ISReal agents.

5.1 Conceptual Extension

Figure 5 depicts some of the conceptual extensions

for ISReal. The upper row shows interface concepts

of BOCHICA. The OMSConfig concept is the root of

a metamodel which is used in the ISReal platform for

conﬁguring the LSE with concrete ontologies, object

services, etc. The imported OMSConfig concept of

the ISReal platform is reused by the extension plug-

in. The middle row depicts the actual conceptual ex-

tensions. The ISRealAgent specializes the concept

Agent and has an URI which deﬁnes an agent’s on-

tological type, an ISRealRaySensor (resolution, up-

date rate), a LSE, and a (not visualized) reference to

an existing graphical avatar (the agent’s body). Some

concepts of BOCHICA change their technical mean-

ing when they are transformed to the ISReal plat-

form. For example, ISReal agents use their plans to

orchestrate object services. BOCHICA already pro-

vides support for orchestrating web services by plans.

Since ISReal object services are very similar to web

services, the existing concepts can be reused with-

out modiﬁcation. Figure 6 depicts a very simple plan

that is triggered by the MoveNearGoal and invokes

the MoveNearService with the according parame-

Figure 5: A part of the ISReal extension of BOCHICA.

Figure 6: Agent-based orchestration of ISReal object ser-

vices (behavior diagram).

ters. The MoveNearService is used for in-room nav-

igation (no path ﬁnding across rooms). The plan’s

context condition checks whether the target object is

located in the same room. The ISReal model transfor-

mation generates code for invoking an ISReal object

service instead of code for invoking an ordinary web

service (see Section 5.3).

5.2 Language Extension

In order to make rational decisions, it is essential for

BOCHICA: A MODEL-DRIVEN FRAMEWORK FOR ENGINEERING MULTIAGENT SYSTEMS

115

agents to reason about the perceived information.

The interface to a knowledge base is usually de-

ﬁned by a query language. As ISReal agents are

based on semantic web technology, we decided to

use SPARQL queries to access the LSE. Two of

the application scenarios are (i) to use SPARQL-

Ask queries to deﬁne the target condition of achieve

goals and (ii) to specify the context condition of

plans with SPARQL-Select queries. As explained

in Section 4.3, BOCHICA deﬁnes language interface

concepts such as BooleanExpression that are used

throughout the framework. We reused an Ecore-based

SPARQL DSL which is provided by the EMFText

concrete syntax zoo to extend BOCHICA (see Sec-

tion 4.3). The BooleanExpression was extended

with SPARQL-Ask and the ContextCondition with

SPARQL-Select. We also reused the automatically

generated parser of EMFText for parsing SPARQL

text queries into SPARQL models that are plugged

into the BOCHICA extension slot. Figure 7 depicts an

example AchieveGoal for walking to an object. The

target condition nearAt(self, object) is validated

in the agent’s LSE. The predicate is perceived by the

agent through its sensor after it has been computed by

the graphics environment and the GSE.

Figure 7: AchieveGoal with SPARQL target condition.

5.3 Transformations

A Jadex application consists of XML-based conﬁg-

uration ﬁles for applications, agents, and capabili-

ties. Behaviors are encoded in Java-based plans. The

base transformation from BOCHICA to Jadex consists

of the four modules Application, Agent, Capability,

and Behavior (see Figure 8). The ﬁrst three mod-

ules map concepts from BOCHICA to the Jadex Plat-

form Speciﬁc Metamodel (PSM) (green arrows) using

QVT model-to-model transformations. The generated

Jadex model is automatically serialized to valid Jadex

XML ﬁles by EMF. We decided not to create a sep-

arate Jadex metamodel for plans. This decision was

made due to experiences with previous transforma-

tions to Jack and Jade (to avoid overhead and sim-

plify extensions). The model-to-text transformation

is done using XPand. The separation of the trans-

formation into separate modules leverages extensibil-

ity and eases maintenance. As explained in Section

!"#$%#& '()*&+ ',-"."/*+

011+%#&2%",

03*,2

4&1&5%+%26

7&/*89:(.

!*$&;%"<

=.> 7&;&

(*<%&+%?&2%",

@5A*#2B

7&;&=.>

4",-C9."/*+B

'()*&+9:(.

(*<%&+%?&2%",

! !

ISReal Agent Modeling Framework

ISReal Agent Execution Platform (Jadex)

'()*&+

>%5<&<6

D82C

Figure 8: ISReal (Jadex) transformation overview.

4.5, the information model is based on Ecore and we

rely on the capability of EMF to automatically se-

rialize types to Java code (white arrow). Since we

want to focus on the overall approach, the details of

the transformations and the Jadex PSM will not be

discussed in this paper. The blue parts in Figure 8

depict (i) the ISReal extension of BOCHICA, (ii) the

ISReal extension to the Jadex QVT and XPand base

transformations, (iii) the generation of conﬁguration

ﬁles for the ISReal agent component, and (iv) an ad-

ditional ISReal library that enables Jadex for the IS-

Real platform. The ISReal library implements the in-

terfaces of the ISReal agent environment for passing

incoming perception events and user queries to the

agents running in the Jadex platform. Moreover, it

includes Jadex into the start-up procedure of the dis-

tributed ISReal platform and provides an ISReal capa-

bility which makes a Jadex agent to an ISReal agent.

For example, it equips an agent with a LSE. Figure 9

depicts a XPand-based aspect-oriented mapping rule

which replaces the original mapping rule of the Jadex

base transformation for invoking a standard web ser-

vice by the invocation of an ISReal object service.

The ﬁrst part sets the variable bindings of the object

service and the second part does the actual invocation

through a helper class provided by the ISReal library.

5.4 ISReal View

The technical details explained so far are (in the ideal

case) not visible to the end user. He is guided by a

methodology and uses graphical diagrams to design

a MAS for a certain use case. The graphical front

end abstracts from technical details such as (i) the in-

tegration of Jadex into the ISReal platform, (ii) the

invocation of ISReal object services in Jadex, or (iii)

the evaluation of SPARQL queries in the LSE. Figure

10 depicts the ISReal agent diagram which contains,

in addition to the standard BOCHICA agent diagram

ICAART 2012 - International Conference on Agents and Artificial Intelligence

116

!"#$%&'()*+,-.)*//01234*567839*(:$#(,0+;.<*1)6//=1234*>?@

((56%A0(B(C!)D06E6*A208*F19G301)@H!)D06E3,*A.)031&.+*@CI

(J56K01901<6B(1*5(K01901<L06)=+,-MNI

(J!:$#F"OP()D06E0183+01<G.A.+*)*A6("?(0Q@

(JJ(J56K01901<6E.99G.0AMC!)D06E6*A208*F19G301)@H!0E1.+*@CR

(((((!A*63-2*S135-*9<*T.-U*FV,A*66031M0E2.-U*E)A0+MNR(0R()D06N@NI

(J!F&':$#F"OPQ@

(J$?=1238.)031(5(B(1*5($?=1238.)031MM=?#*.-"<*1)N()D06

(J((E<*)K*-0*WX.6*MNE<*)K*-0*WMC06A*.-"<*1)CNE<*):.8)MNR(56%A0R

(JJ(((56K01901<6R(M-31<N(!)D06E)0+*3U)(Y(Z[[[@NI

(J)D06E5.0):3AFV)*A1.-O3190)031M5NI

(J56#*6(B(5E<*)#*6U-)MNI

(J0WM\56#*6N()D06EW.0-MNI

!F&'"#$%&'@

Figure 9: This mapping rule replaces the original web ser-

vice invocation by an ISReal object service invocation.

Figure 10: The customized ISReal agent diagram.

artifacts, the ISReal sensor and the LSE. Placing an

ISReal agent implies, compared to a plain agent, the

generation of an ISReal agent component which inte-

grates into the ISReal platform, the LSE, sensor inter-

faces, different service execution semantics, etc.

We evaluated the ISReal extension in a virtual pro-

duction line scenario. The current MAS model en-

compasses about 20 goals and plans which cover ba-

sic navigation and object interaction (e.g. for operat-

ing a virtual machine). Code for simple plans such

as the one shown in Figure 6 can be completely gen-

erated and do not need further manual reﬁnements at

code level. Our experience with modeling the demo

scenario shows that the extension mechanism fulﬁlls

the requirements of real world applications. The ex-

tensions focus on single isolated aspects and integrate

into the core DSL and the Jadex base transformation.

Sometimes we experienced limitations of the current

interfaces. For example, it is currently not possi-

ble to have mixed target conditions in goals (e.g. a

combined SPARQL-Ask query plus a boolean Java

expression). This issue could be solved by expres-

sion containers which allow to combine different soft-

ware languages. However, we will further develop

the interfaces as we gain experiences with applying

BOCHICA to other execution environments. The ex-

isting extensions clearly simplify the development of

ISReal agents.

6 RELATED WORK

During the recent years, several agent-oriented mod-

eling languages have been proposed. The majority of

the modeling languages were created in order to sup-

port a certain agent methodology (Henderson-Sellers

and Giorgini, 2005)(Sterling and Taveter, 2009). One

problem of existing methodology-oriented modeling

approaches that we see is that they do not clearly

distinguish between (i) the agent platform, (ii) the

methodology, and (iii) the modeling language. Two

indicators which support our perception are (i) the de-

velopment of the modeling languages is not decou-

pled from the methodologies and (ii) none of the lan-

guages has an own name (only the tools have names).

However, we think the development of modeling lan-

guages is orthogonal to the development of agent

methodologies and tools. Of course, a methodology

can (and most likely will) have certain requirements

to a modeling language (e.g. own methodology ar-

tifacts and views). For this purpose, BOCHICA can

be extended with methodology artifacts. However,

the core of the agent modeling language is indepen-

dent of a certain methodology. Unfortunately, the ma-

jority of the developed modeling tools are only par-

tially based on standardized technology for model-

driven development

which hampers the beneﬁts of

MDSD. For example, the Prometheus Design Tool

(Prometheus methodology) has no explicit underly-

ing metamodel. AgentTool III

(O-MaSE), INGE-

NIAS Development Kit

(INGENIAS), Taom4e

(Tropos), and REBEL

(ROADMAP) are based on

Ecore metamodels but use legacy or non-MDA-based

model transformations. To the best of our knowl-

edge, the mentioned approaches are not thought to

be extended or customized by 3rd party plug-ins.

Beside the methodology-based modeling languages,

there exist also approaches for extending the Uniﬁed

Modeling Language (UML) with agent concepts (e.g.

Object Management Group’s (OMG) Agent Meta-

model and Proﬁle

(AMP) or FIPA Agent UML

Those approaches promise to reuse the ecosystem

built around UML – including the large user group.

However, modeling agents is fundamentally different

from modeling objects. Agents possess an internal

cognitive model and require different methods and

design patterns. Moreover, our experiences in AMP

showed that it is hard to extend UML since the under-

lying Meta Object Facility (MOF) metamodel is com-

We analyzed the publicly available software.

http://www.cs.rmit.edu.au/agents/pdt/

http://agenttool.cis.ksu.edu/

http://ingenias.sourceforge.net/

http://selab.fbk.eu/taom/

http://www.agentlab.unimelb.edu.au/software.html

http://www.omg.org/cgi-bin/doc?ad/08-09-05.pdf

http://www.auml.org/

BOCHICA: A MODEL-DRIVEN FRAMEWORK FOR ENGINEERING MULTIAGENT SYSTEMS

117

plex and extensions of existing elements have many

not desired and non-obvious implications. Thus, we

are sceptical that extending UML in its current form

sufﬁces the needs of AOSE. UML, which is a gen-

eral purpose modeling language, offers two exten-

sion mechanisms: (i) heavy weight metamodel ex-

tensions and (ii) light weight proﬁles. Metamodel

extensions of UML underlie the standardization pro-

cess of OMG and are not for the normal end user.

Proﬁle-based extensions can be created by end users

and allow a limited customization. An alternative

to our approach would be the creation of a plat-

form speciﬁc modeling language (e.g. for the ISReal-

enabled Jadex platform). This would mean to rein-

vent many things that are already part of BOCHICA.

In (Kardas et al., 2009) two platform speciﬁc mod-

eling languages for the agent platforms SEAGENT

(Dikenelli, 2008) and Jadex were presented. The pos-

sibility to customize the language if the agent plat-

form (e.g. Jadex) is integrated into a larger platform

is not discussed. Our approach is especially suited for

large scale applications or target environments with

many end-users (e.g. the ISReal platform) where cus-

tomizations pay off. Small applications can be real-

ized with the functionality provided by the core mod-

eling language and the base transformations (similar

to existing approaches). We see BOCHICA comple-

mentary to existing approaches as it provides a clean

conceptual framework and interfaces for integration.

7 CONCLUSIONS

In this paper we presented a novel model-driven

framework for AOSE which integrates the experi-

ences we gained during the recent years with model-

ing MAS. The BOCHICA framework goes beyond the

state of the art in AOSE as it is not created for a cer-

tain execution platform, methodology, or application

domain. Instead, it is based on a platform independent

agent core modeling language and provides generic

extension interfaces for integrating results from agent

research as well as for customizing it regarding user-

speciﬁc application domains, new methods, and plat-

forms. After we presented our vision on how to apply

our framework in Section 3, the extension interfaces

were introduced in Section 4. Based on BOCHICA,

we showed how to create a model-driven development

environment for semantic virtual worlds. We see our

approach as a contribution to the uniﬁcation of the

diverse ﬁeld of agent-oriented modeling and to bridge

agent research and concrete software development. In

the future we want to integrate existing agent method-

ologies and work on collaborative modeling of agent-

based systems.

REFERENCES

Belecheanu, R. A. et al. (2006). Commercial applications of

agents: Lessons, experiences and challenges. 5th Int.

joint Conf. on Autonomous Agents and Multi-Agent

Systems., pages 1549—1555.

Dikenelli, O. (2008). SEAGENT MAS platform develop-

ment environment. In Proc. of the 7th Int. joint Conf.

on Autonomous agents and multiagent systems: demo

papers, AAMAS ’08, pages 1671–1672. IFAAMAS.

Hahn, C. et al. (2009). A platform-independent meta-

model for multiagent systems. Autonomous Agents

and Multi-Agent Systems, 18:239–266.

Henderson-Sellers, B. and Giorgini, P. (2005). Agent-

Oriented Methodologies. Igi Global.

Jennings, N. R. and Wooldridge, M. (2000). Agent-

Oriented Software Engineering. Artiﬁcial Intelli-

gence, 117:277—296.

Kapahnke, P. et al. (2010). ISReal: an open platform for

semantic-based 3D simulations in the 3D internet. In

Proc. of the 9th Int. Semantic Web Conference on the

Semantic Web (ISWC’10), page 161–176. Springer.

Kardas, G., Ekinci, E. E., Afsar, B., Dikenelli, O., and

Topaloglu, N. Y. (2009). Modeling tools for platform

speciﬁc design of Multi-Agent systems. In Proc. of the

8th German Conf. on Multiagent System Technologies

(MATES’10), volume 5774, pages 202–207. Springer.

Kleppe, A. (2008). Software Language Engineering: Cre-

ating Domain-Speciﬁc Languages Using Metamodels.

Addison-Wesley Longman, Amsterdam, 1 edition.

Leon-Soto, E. (2009). Modelling interaction protocols as

modular and reusable 1st class objects. In Agent-

Based Technologies and Applications for Enterprise

Interoperability, volume 25 of LNBIP, pages 174–

219. Springer.

McKean, J. et al. (2008). Technology diffusion: analysing

the diffusion of agent technologies. Autonomous

Agents and Multi-Agent Systems, 17(3):372–396.

Padgham, L. et al. (2004). Developing Intelligent Agent

Systems: A Practical Guide. John Wiley & Sons.

Steinberg, D. et al. (2008). EMF: Eclipse Modeling Frame-

work. Addison-Wesley, 2nd revised edition.

Sterling, L. and Taveter, K. (2009). The Art of Agent-

Oriented Modeling. The MIT Press.

Warwas, S. et al. (2011). Making multiagent system designs

reusable: A model-driven approach. In Proc. of the

Int. Conf. on Intelligent Agent Technology (IAT’11),

pages 101–108. IEEE.

Please contact the ﬁrst author if you need a backup of the ref-

erenced documents in the footnotes (14.10.2011).

ICAART 2012 - International Conference on Agents and Artificial Intelligence

118