IMPULSE: a Design Framework for Multi-Agent SystemsBased on Model Transformation

Hiroyuki NakagawaThe University of

Electro-CommunicationsChofu–shi, Tokyo, Japan

nakagawa@is.uec.ac.jp

Nobukazu YoshiokaNational Institute of

InformaticsChiyoda–ku, Tokyo, Japannobukazu@nii.ac.jp

Akihiko OhsugaThe University of

Electro-CommunicationsChofu–shi, Tokyo, Japanohsuga@is.uec.ac.jp

Shinichi HonidenNational Institute of

InformaticsChiyoda–ku, Tokyo, Japan

honiden@nii.ac.jp

ABSTRACTThe purpose of this study is to reduce the difficulties encounteredwhen designing multi-agent systems (MAS). Although MAS areone of the more effective approaches for dealing with the recentincrease in software complexity, they are themselves difficult todevelop. We believe the difficulties in determining agent respon-sibilities and the organizational structure as the most significantobstacles to MAS development. In this paper, we propose a de-sign framework for MAS, which includes restriction rules in thegoal-oriented requirements description and a generator that trans-forms the restricted requirements description into a general MASdesign model. We demonstrate the effectiveness of our frameworkthrough a case study and show how the framework can be usedto construct MAS design models more precisely than conventionalmethods permit.

Categories and Subject DescriptorsD.2.1 [Software Engineering]: Requirements/Specifications—Methodologies; I.2.11 [Artificial Intelligence]: Distributed Artifi-cial Intelligence—Multiagent systems

General TermsDesign

KeywordsModel transformation, goal-oriented requirements descriptions, ar-chitectural design, multi-agent systems

1. INTRODUCTIONAgent technology offers a solution for producing complex soft-

ware systems characterized by autonomous behaviors, a high de-

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SAC’11 March 21-25, 2011, TaiChung, Taiwan.Copyright 2011 ACM 978-1-4503-0113-8/11/03 ...$10.00.

gree of distribution, and mobility support. In particular, a consider-able number of studies have focused on the methodologies for de-veloping multi-agent systems (MAS) [27]. The development pro-cess for MAS [2, 18] usually starts with the requirements analysisphase and ends with the maintenance phase through the design,implementation, and test phases, which is similar to what is donefor other types of software. However, since MAS have multipleautonomous components in the system, which are the agents, andthey interact with each other, one of the remaining difficulties isdeciding on the responsibilities of the individual agents, i.e., theiractivities, interactions, and constraints, in the design phase.

In this paper, we propose a MAS design framework called IM-PULSE. Our approach uses the requirements description [25, 6]for the architectural design. As Nuseibeh described [22], the soft-ware requirements strongly influence the system architectures. We,in particular, use a goal-oriented requirements description [26, 1],which captures the goals at different abstraction levels and the var-ious objectives of the system under consideration, in order to iden-tify the individual agent responsibilities. IMPULSE contains re-striction rules that are imposed on the goal-oriented requirementsdescription and a generator that transforms the restricted require-ments description into a general MAS architectural model. Wepreviously investigated the possibility of a connection between therequirements and design phases of the MAS development in [20].The work presented in this paper provides a stable framework withformalization and automation.

The primary contributions of this paper are as follows:

1. We introduce restriction rules imposed on the requirementsdescriptions. These rules enable developers to analyze MASon the requirements descriptions and help an automatic MASarchitectural model construction.

2. We also introduce a formal mapping from the requirementsdescription to a standard MAS architectural model, whichis implemented as a model generator. It automatically con-structs a partial MAS architectural model with no contradic-tions to the requirements description.

The rest of the paper is organized as follows: Section 2 describesthe difficulties of constructing a MAS architectural model. Thissection also presents an overview of KAOS, a goal-oriented re-quirements analysis method that we use in this study. Section 3 ex-plains how developers can construct the MAS architectural model

1411

safety

liveness

permissions

activities

description

role schema

Role *

Agent

*

rules

Organization

protocol

initiator/ partner

*

description

output

input

name

Interaction

permission

Resource

*

Environment

Figure 1: Gaia metamodel.

based on IMPULSE. Section 4 reports on our evaluation resultsthrough a description of a case study. Section 5 discusses relatedwork, and Section 6 concludes the paper with future work.

2. BACKGROUND

2.1 Difficulties of MAS architectural designSeveral methodologies have been proposed for constructing MAS,

such as Gaia [31, 28], MaSE [10], Tropos [3], ROADMAP [15, 16],Prometheus [23], and PASSI [7]. Among these, we particularly fo-cus on Gaia since it provides simple but essential models for de-signing MAS. Gaia has four models for the architectural design:role, interaction, organization, and environment models, as illus-trated in Figure 1. The role model is the basis of the agent model;the interaction model defines the direct communications betweenagents; the organization model defines partial structures, which ex-ist in MAS and have the roles as members, and it also defines theorganizational rules, which are the constraints on the organization;the environment model consists of the resources in the system envi-ronment and their access permissions. Even though Gaia providesthese models, it is still difficult to construct them in terms of thefollowing two main aspects.

Role model construction. Since roles determine the behaviorsof the individual agents, the most important element in MAS archi-tectural design is the role. If MAS developers fail to determine suit-able role responsibilities, MAS will not satisfy their requirementsor may exhibit unexpected behaviors. When using Gaia methodol-ogy, the developers can start from the role extraction from the re-quirements description; however, the standard system requirementsdescriptions, which usually represent features of the systems, areinsufficient for extracting suitable role responsibilities. Moreover,the developers have to define their properties in the role model. Tobriefly explain the properties of the role model1, the protocols de-fine relevant interactions with other roles, the activities are the tasksthat the roles can complete by themselves, the permissions repre-sent the access permissions for each environmental resource, theliveness shows a role’s operational sequence, which is composed ofprotocols and activities, and safety comprises the constraints to besatisfied at all times. The determination of these properties requiresa correct understanding of each role’s responsibility and behavior,but Gaia does not provide such an understanding.

Organization extraction. The organizations are defined as theentities composed of specific agents and are structured by the agents’interactions in order to achieve the main aim of the organization.They connect the whole MAS with the individual agents. In theGaia architectural design, developers extract the sets of roles thatcompose the organizations and define the organizational rules, which1Table 5 shows a concrete role model.

Goal

Subgoal1 Subgoal2

Expectation

AND-refinement

Requirement1

OR-refinement

Requirement3Requirement2Softgoal

Performance

CauseEntity1 Responsibility assignment

Operationalization

Output

Entity2

Output

InputEvent1

Event2

Operation

KAOSAgent1 KAOSAgent2

Figure 2: Legend of KAOS model.

are the constraints of the organizations. In order to determine therole sets and the constraints, however, developers have to figureout which organizations should exist in the MAS and have to fullycomprehend the involvement and influence of each role within theorganization. Even though the organizational model connects theMAS and individual agents, it is still difficult to construct it.

2.2 KAOSKAOS [8, 17] is the goal-oriented requirements analysis method

that we use in this study. Figure 2 shows the syntax of the KAOSmodel. In KAOS, the system goals are refined (decomposed) intorequirements, softgoals, and expectations in the goal model. Therequirements are the goals that the target system should achieve;the softgoals are the goals that can be used for describing the non-functional requirements, such as performance, safety, and usability.On the other hand, the expectations are the states that the exter-nal actors, i.e., the users, devices, or the relevant systems, shouldsatisfy. After refinement, the extracted requirements and expecta-tions are assigned to the agents in KAOS2 as their responsibilities,and then the operations that satisfy them are derived. Finally, allthe system behaviors are expressed as the chain of operations andevents. KAOS provides not only the requirements description el-ements, e.g., the goals, requirements, and KAOS agents, but alsothe system design description elements, such as the operations andevents, which can be used for model transformation into anothermodel for system design. We use the KAOS model as a require-ments description to generate the MAS architectural model.

3. IMPULSEWe propose a design framework for the MAS development called

IMPULSE, which uses the goal-oriented requirements descriptionsto reduce the difficulties in designing MAS. IMPULSE contains re-striction rules imposed on the KAOS description and a generatorthat transforms the restricted KAOS description into a partial Gaiaarchitectural model. Figure 3 shows an overview of the design pro-cess based on IMPULSE. It starts with a description of the KAOSmodel with our restriction rules through the requirements analysisfor a complex system. After constructing the KAOS model, weuse a generator to create a partial Gaia architectural model as anarchitectural model schema. Developers add more designs to the

2Agents in KAOS represent the actors, which are the target systemand environmental actors, e.g., users, devices, and relevant systems.From here on, we shall call agents in KAOS KAOS agents.

1412

Requirements

analysis based on

KAOS with

restriction rules

System

Requirements

Activity 1Requirements

analysis

based on KAOS

KAOS model

followed

restriction rules

Activity 2Automated model

transformation

MAS architectural

model schema

Activity 3Additional

design

MAS (Gaia)

architectural

modelactivity input/output

comment

activity

Legend

artifact

Review generated

schema and add

constraints for roles

and organizations

Requirements Architecture

Figure 3: Overview of IMPULSE framework.

schema to complete the MAS architectural model. The followingsubsections explain each activity of our framework.

3.1 Requirements analysis based on KAOSKAOS provides an adequate requirements description capability

even if the target application is MAS, when we extract the func-tionalities of the system, which is one of the main activities of therequirements analysis. However, certain constraints should be usedwhen connecting the requirements description with the MAS archi-tectural model. In order to transform the KAOS model into a Gaiaarchitectural model, we add the restriction rules, R1 · · · R5, listedin Table 1 for the KAOS description.

First, since the KAOS agent assigned requirements representsthe target system in generic KAOS, the developers tend to assigninsufficiently decomposed requirements to the target MAS, whichmakes it unclear the responsibilities of individual agents in MAS.We define R1 and R2 to sufficiently decompose the requirementsand assign them to roles. R1, in particular, helps the developers de-compose the goals and form suitable sets of requirements. We canuse milestone-driven refinement and case-driven refinement [9] forsatisfying R1. R2 is based on the fact that agents are autonomousentities and can take responsibility for achieving these objectives.Next, operations are usually defined at the system function levelin generic KAOS; however, this means that some role activities,which do not directly affect the system functions, may fail to bedescribed. This also makes it difficult to extract the interactions be-tween the roles in MAS. R3 and R4 allow developers to explicitlydescribe the individual role activities and the interactions.

As for R5, the developers usually describe the system behaviorsby connecting the operations to the events in generic KAOS. Inthis paper, we call the diagrams where developers draw such con-nections operation diagrams. These operation diagrams usuallyillustrate scenarios, and by imposing R5, we can regard the rolesthat appear in the same operation diagram as the members formedin the same organization. This interpretation allows developers toformally extract organizations. Finally, R2 and R3 ensure that allthe requirements and softgoals are assigned to the KAOS agentsand all the operations satisfying the requirements are derived. Thismeans that the responsibilities of the roles are clearly stated, notoverlapped, and sufficiently cover all of goals for the target MAS.Due to these restriction rules, we can overlay the KAOS model onthe Gaia model illustrated in Figure 4, which can be the basis of aGaia model generation.

Figure 4: Extended KAOS metamodel by adding the restrictionrules. Labels colored blue represents the corresponding MASattributes that the generator transforms into.

Output

RequestInference

Infer

RequestInference

Identify Target

Location

Migrate

Tracker

Estimator

Schedule

Log

ReportSensingData

Performance

Performance

Performance

Cause

Cause

Cause

Output

Input

Input

KAOS Agent

Operation

Event

Entity

ReportMigration

Output

Figure 5: Inference operation diagram for tracking process.

3.2 Transformation into MAS architectureThe generator, which we propose in this paper, transforms a

KAOS model described based on the restriction rules into a par-tial Gaia model as an architectural model schema. This genera-tor is implemented as an Eclipse Plugin and accepts XML data,which is output from the KAOS drawing tool Objectiver [4] as aconstructed KAOS model. The generator parses and verifies therestricted KAOS model by checking R2, R3, and R4 in the restric-tion rules, and finally generates the architectural model schema.Appendix A shows our transformation algorithm from the KAOSmodel into the Gaia model. Once the model is generated, the de-velopers check the validity of the schema and add some designsincluding the safety property in the role model and organizationalrules to complete the Gaia architectural model. We will briefly ex-plain how to generate the Gaia architectural model schema usinga motivating example. Figure 5 shows a KAOS operation diagramfor the tracking system. It shows a process for tracking objectsthat uses an inference mechanism. IMPULSE mainly exploits theKAOS operation diagram to generate the schema since it is usuallydescribed in the final stage in the KAOS analysis and consists ofthe elements that can be extracted as those for system design.

Step 1: Role identification. By imposing the restriction rules,IMPULSE regards KAOS agents that are assigned the requirementsas roles and constructs the role models. In our example, while theassignment relationship is not described in this paper, we assume

1413

Table 1: Restriction rules for KAOS description.

# Rule description Target objects Automatedvalidation

R1 Goals should be decomposed into sets of requirements, which represent states that the goals,system has to achieve to satisfy these goals. requirements

R2 All requirements, softgoals, and expectations should be assigned to single KAOS agents, requirements, softgoals,√

and KAOS agents assigned requirements should represent roles, not the target system. expectations, KAOS agentsR3 Every requirement should have at least one corresponding operation. requirements, operations

√

R4 Operations should be defined as activities that single roles or single external actors can operations, KAOS agents√

complete independently.R5 Operation diagrams should describe only single scenarios. operation diagrams

that both the Tracker and Estimator agents are assigned require-ments, and thus, we identify them as roles.

Step 2: Interaction Extraction. We focus on the events in theoperation diagrams for generating the interaction model. AlthoughKAOS uses events for describing two different concepts, i.e., in-ternal or external events, we can deterministically distinguish be-tween them by checking the creator and receiver of the event. Ifboth KAOS agents represent different roles, IMPULSE identifiesthe event as an interaction, or if at least one of them is an externalactor, it identifies it as an external event. In Figure 5, we can deter-mine that the RequestInference is an interaction because its sendersand receivers are previously identified as the different roles.

Step 3: Organizations discovery. We have to determine whetherthe MAS should have organizations. R5 in our restriction rules al-lows us to recognize an operation diagram as a scenario that in-cludes an organization, and IMPULSE regards the roles describedin the same operation diagram as the members formed in the sameorganization. The operation diagram described in Figure 5 includestwo roles, Tracker and Estimator; therefore, IMPULSE extractsthem as members of the Inference organization.

Step 4: Environmental resource aggregation. The environ-mental model defines its resources and permissions for these re-sources. IMPULSE first extracts the entities in the operation dia-grams as environmental resources, and then assigns each resourceto a suitable permission according to the link with the operationsowned by the roles. In Figure 5, two objects, Schedule and Log,are identified as readable resources, and in particular, the generatorassigns reads permissions of these resources to Estimator.

Step 5: Role properties determination. The goal of this stepis to construct the role model. The generator extracts all proper-ties of the role model except description and safety from the re-stricted KAOS model. We explain the way of generating a livenesssequence as follows. Liveness describes the sequences of activi-ties and interactions that a role must perform in order, based onthe syntax of the liveness expressions [31]. In order to generateeach liveness sequence, the generator first collects the operationsassigned to the roles and the events relevant to the operations, andthen classifies them in terms of the performers (roles). After furtherclassification by operation diagram membership, the transforma-tion rules for generating a Gaia liveness notation from the KAOSmodels listed in Table 2 are repeatedly adapted. Table 3 lists thegenerated role model schema for Tracker from the operation dia-gram illustrated in Figure 5. If other operation diagrams exist, eachproperty is additionally obtained according to these diagrams.

4. EVALUATION

4.1 Case Study: Tracking SystemWe evaluated the applicability of IMPULSE through a case study

Table 3: Generated role model schema for Tracker.Properties Values

Role Schema TrackerProtocols and Protocols: ReportSensingData, RequestInference,Activities ReportMigration

Activities: IdentifyTargetLocation,Migrate

Permissions Reads: –Changes: –

Liveness ReportSensingData. IdentifyTargetLocation.RequestInference. Migrate. ReportMigration

on the construction of the architectural model of a tracking system.The tracking system chases targets by using sensing data and a rea-soning mechanism. In this case study, two developers first coopera-tively constructed the Gaia model in the generic Gaia design. Next,two weeks later, we let the developers describe a KAOS model forthe tracking system based on our restriction rules. After executingthe generator, the developers completed the Gaia model by addingdesign to the generated schema. We compared these three models,(1) the pre-constructed Gaia model in the generic Gaia design, (2)the generated schema, and (3) the completed model based on theschema in the IMPULSE design.

As for the KAOS model construction in the IMPULSE design,the developers constructed six diagrams as the goal models, eightdiagrams for assigning responsibility (six for roles and two for ex-ternal actors), and two operation diagrams. Figure 6 shows theresponsibility of the Estimator, one of the extracted roles, and Fig-ure 7 shows a part of an operation diagram representing the processfor chasing objects using an inference mechanism. Note that thesemodels were used not only for the formal transformation but alsoas a visual understanding when the developers added more designsto the generated schema.

Table 4 lists the quantitative evaluation results from this casestudy. We used the number of elements that appeared in the live-ness property, and the number of constraints in the safety propertyas the metrics to show the difficulties in constructing role models.We also used the average number of organizational rules as a metricfor the difficulty of extracting organizations. Table 5 lists one of thecompleted role models, the model for Estimator, through the IM-PULSE design. The bold print values in this table show that theycould not be extracted in the generic Gaia design.

Table 4 and Table 5 show that the generator outputs more activ-ities and interactions than the generic Gaia design. By observingthe constructed KAOS model, we found that our restriction rulesenabled the developers to explicitly describe auxiliary activities,such as locally aggregating the sensing data, and exception flow,e.g., cancellation of inference, listed in Table 5. Note that we also

1414

Table 2: Transformation rules for generating liveness sequence.Concept Condition in the KAOS model (o is current focused operation of role r) Liveness notation

interleave {X,Y} ⊆ PLS (r) ∧ d1, d2 ∈ OperationDiagrams ∧ ∀x∀y(x ∈ X ∧y ∈ Y∧ X || Y((on(x, d1) ∧ on(y, d2) ∧ d1 , d2) ∨ (x < Y ∧ y < X)))

join {X,Y} ⊆ PLS (r) ∧ e1, e2 ∈ Event ∧ cause(e1, o) ∧ cause(e2, o) (X|Y). o∧ (e1 ∈ X ∨ ∃o1(o1 ∈ X∧ output(o1, e1)) ∧ (e2 ∈ Y ∨∃o2(o2 ∈ Y∧ output(o2, e2)) ∧ X ∩ Y = ϕ

monitor e ∈ Event ∧ a1 ∈ ExternalActors ∧ o1 ∈ Operations ∧ perform(a1, o1) ∧ output(o1, e) ∧ cause(e, o) Monitorω.obranch e ∈ Event ∧ o1 ∈ Operations ∧ perform(r, o1) ∧ cause(e, o) ∧ cause(e, o1) (o. · · · ) | (o1. · · · )follow e ∈ Event ∧ o1 ∈ Operations ∧ perform(r, o1) ∧ output(o, e) ∧ cause(e, o1) o. o1 (or o. e. o1)unify Concept interaction is satisfied and both names of o and e are same. e (eliminate o)

Event e1, e2 satisfy concept interaction, and e1 and e2 have same name “e”. e (no duplicate extraction)interaction e ∈ Event ∧ r1 ∈ Roles ∧ r1 , r ∧ o1 ∈ Operations ∧ perform(r1, o1) ∧ output(o1, e) ∧ cause(e, o) e.o (extract e)

e ∈ Event ∧ r2 ∈ Roles ∧ r2 , r ∧ o2 ∈ Operations ∧ perform(r2, o2) ∧ output(o, e) ∧ cause(e, o2) o.e (extract e)activity default (o ∈ Operations) o

*PLS(r) denotes the set of all partial liveness sequences of role r.

Estimator

Accurate reqsoning

Short reasoning time

Reasoning based on the

latest confirmed sensing data

and available schedule data

Schedule table

for target can be

checkedstop inference

infer location

Reasoning is canceled

Log can be checked

Performance

Performance

Figure 6: Responsibility assignment to Estimator role.

report tracking data to tracker

[I]request inference

request inference

Loginfer

location

Schedule

[R]request inference

move to zone

give notice of destination

show result

[I]cancel inference

cancel inference

stop inference

Estimator

[R]cancel inference

Cause Cause

CauseCause

CauseCause

Cause

Cause

OutputOutput

OutputOutput

Output

Intput

Intput

PerformancePerformance

Figure 7: Operation diagram for chasing objects.

Table 4: Experimental results of Gaia model construction.

Generic IMPULSEProperties Gaia generated completed

(1) model (2) model (3)# Roles 6 6 6

# Activities 5 9 9# Interactions 8 13 13# Elements in liveness 31 43 43Average liveness length (per role) 5.17 7.17 7.17# Constraints (Safety) 2 – 8

# Organizational rules 10 – 15# Organizations (incl. MAS itself) 6 3 3Rules/organizations 1.67 – 5

Table 5: Constructed role model for Estimator in IMPULSE de-sign. The bold print values correspond to the items that couldnot be extracted in the generic Gaia design.

Properties ValuesRole Schema EstimatorDescription The role infers where target exists by using schedule(manually added) data and sensing log dataProtocols and Protocols: RequestInference, CancelInferenceActivities Activities: InferLocation, StopInferencePermissions Reads: Log, Schedule

Changes: –Liveness RequestInference.InferLocation.RequestInference

||CancelInference.StopInference.CancelInferenceSafety – Time required for reasoning ≤MaxResponseTime(manually added) – Reliability of result ≥ AcceptableRate

1415

found that the developers manually inserted contradictions betweenthe permission property of the role model and that of the environ-mental model in the generic Gaia design.

While these activities and interactions were automatically ex-tracted by the generator, the IMPULSE design also acquired moreconstraints for the safety property. The developers derived the con-straints by observing the constructed KAOS model in the IMPULSEdesign. For example, the safety property listed in Table 5 seemedto be derived from the softgoals shown in Figure 6.

Table 4 also suggests that the IMPULSE design extracted fewerorganizations but more organizational rules than the Gaia design.While the generic Gaia design acquired only the time-series rules,such as “A ⇒ ^B”, the IMPULSE design additionally extractedthe structural constraints, such as:

“∀z ∈ Zones [∃zoneManager[manage(zoneManager, z)]]”,

and invariants on data, such as:

“∀data [∃sensor ∃zone ∃zoneManager [data ∈ SensedData(sensor)∧ belong(sensor, zone) ∧ manage(zoneManager, zone)⇒data ∈ ReportedData(zoneManager)]]”.

The developers derived these constraints by observing the constructedoperation diagram, such as that shown in Figure 7.

4.2 DiscussionWe will now evaluate our development framework in light of

the results of the case study. First, as for role model construction,the restriction rules help developers to identify the role’s responsi-bilities. The result suggests that IMPULSE helps ensure that de-velopers do not fail to extract auxiliary activities and interactionsin the exceptional flow by imposing restrictions. We believe that astate-based requirements description by R1 and the definition of theoperations from these requirements by R3, in particular, help to ex-tract these passive activities and exceptional interactions. Based onour findings, we argue that the milestone-driven refinement helpsto extract roles’ activities and interactions, and the case-driven re-finements helps to discover exceptional scenarios. Although thesafety property cannot be automatically generated in the IMPULSEdesign, developers can use the diagrams for responsibility assign-ment, such as shown in Figure 6, where softgoals and requirementsare sufficiently refined for discussing the constraints put on theroles. The automatic generation is also beneficial not only for ex-tracting most of the properties for the role model but also for pre-venting the weaving of inconsistencies between the role model andother models.

Regarding organization extraction, IMPULSE enables develop-ers to consult KAOS operation diagrams to determine the organiza-tional structures and behaviors. As for the organizational structure,it helps developers to forgo extracting any unnecessary organiza-tions due to R5 in our restriction rules. Developers can extract onlythe organizations that are described on the operation diagrams, andthe roles that appear in these diagrams as their members. As for theorganizational behavior, observing each operation diagram, whichsequentially describes the roles’ activities and interactions, makesit easier to understand the dynamic aspects of the organization andeach role’s involvement in it. Therefore, while the organizationalrules are the properties that the developers must manually extract,we argue that IMPULSE helps the developers to better understandthe structures and behaviors of the organizations.

There are limitations to our approach. First, IMPULSE dependson the goal modeling in the requirements analysis activity; how-

ever, constructing goal-oriented requirements descriptions is stilldifficult. We have to refine goals into requirements without leak-ing the necessary states that the system achieves. Existing goalrefinement patterns, as shown in [9], and additional analysis guide-lines for MAS, would be of help to construct a more elaboratemodel. Second, the generator does not generate all informationof the MAS architectural model. Developers have to discuss thevalidity of the generated schema and add the constraints for theroles and organizations in this activity. We believe that the for-mal descriptions in the KAOS model3 can be used for generating afurther elaborated model. Third, when considering the review pro-cess, more iterative development processes for evolving the KAOSmodel are desired. The current IMPULSE provides only a genera-tor, but since the additional designs are manually described on thegenerated schema, certain change management mechanisms for themanual input should be implemented as support tools.

Finally, we use the KAOS model as a goal-oriented requirementsdescription in this study. The reason we chose KAOS is that it pro-vides not only the requirements descriptors but also the system de-sign descriptors, such as operation and event, and the relationshipsbetween these descriptors. Tool support for outputting a structuredtext data file, i.e., an XML file in this case, is another reason wechose KAOS. We can apply other goal-oriented requirements de-scriptions in our framework if these descriptions have the necessaryfeatures.

5. RELATED WORKThere have been some attempts to use requirements description

for designing MAS. ROADMAP [14, 16] is a methodology thatextends Gaia to support the requirements analysis phase activity. Ittries to use the use-case in [14] and the goal-oriented requirementsdescription in [16]. As for the use of the goal-oriented description,it would be partly beneficial to reduce the role model constructiondifficulty; however, since it does not explicitly define the descrip-tion rules, it may lead developers to forgo extracting the clear re-sponsibilities of the roles. ROADMAP also does not provide a cleardefinition of the mapping rule from the requirements description tothe architectural model. Tropos [3] and PASSI [7] also support re-quirements analysis phase activities. Tropos is a methodology thatsupports MAS development from the requirements analysis phaseto the implementation phase. It makes use of i* [29], which pro-vides a goal-oriented requirements description. PASSI identifiesthe system requirements using a use-case diagram. Compared tothese methodologies, IMPULSE provides clearer rules for the re-quirements description and a design model generator.

Goal-oriented requirements description is also used for analyz-ing dynamically adaptive systems [5, 19]. The goal-oriented de-scription is suited to exploring alternative requirements and repre-senting alternative behaviors. We use the description for analyzingthe requirements of MAS, however, the main reason of using it isthat it can be used to sufficiently refine the requirements for assign-ing them to roles.

As for the formulation of the requirements descriptions, somerestrictions or metamodels are applied on use cases in [30, 24, 11]and applied on problem frames [13] in [12]. The object of thesestudies is to reduce the ambiguities of description and to facilitatethe process of automated validation or automated derivation of thesuccessor model from these descriptions. Since MAS has multipleautonomous actors, which are the agents, we use the goal-orientedapproach in order to assign suitable responsibilities to the roles by

3KAOS has a formal description layer as well as the graphical no-tation.

1416

using the goal refinement.

6. CONCLUSIONWe have proposed the IMPULSE framework to reduce the diffi-

culties related to designing MAS. We imposed restriction rules onKAOS, which we use as a goal-oriented requirements descriptionfor analyzing MAS, and implemented a model generator, whichmaps the restricted KAOS model into the Gaia architecture modelas a general MAS architectural model. Our evaluation results sug-gest that our framework supports a MAS architectural design pro-cess that can extract individual role responsibilities and organiza-tions.

In future work, we plan to use formal descriptions in the KAOSmodel and add more restrictions and transformation rules, for gen-erating further elaborated architecture model. We believe that thisreinforcement leads to the reduction of the manual addition of theconstraints for the roles and organizations. As for the MAS de-sign framework, we have recently proposed a method of validatingthe MAS architecture model based on the requirements importance[21]. In this method, we introduced role importance calculated byusing the requirements importance as a metric to extract a suitablerole set. We are consolidating our framework and method in or-der to verify a generated architecture model. We will also extendIMPULSE for iterative development and for handling requirementsevolution.

7. REFERENCES[1] A. I. Antón and C. Potts. The use of goals to surface

requirements for evolving systems. In ICSE ’98:Proceedings of the 20th international conference onSoftware engineering, pages 157–166, Kyoto, Japan, 1998.IEEE Computer Society.

[2] C. Bernon, M. Cossentino, and J. Pavón. Agent-orientedsoftware engineering. The Knowledge Engineering Review,20(2):99–116, 2005.

[3] P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia, andJ. Mylopoulos. Tropos: An agent-oriented softwaredevelopment methodology. Autonomous Agents andMulti-Agent Systems, 8(3):203–236, 2004.

[4] CEDITI. Objectiver. http://www.objectiver.com/.[5] B. H. C. Cheng, P. Sawyer, N. Bencomo, and J. Whittle. A

goal-based modeling approach to develop requirements of anadaptive system with environmental uncertainty. In Proc. ofthe ACM/IEEE 12th International Conference on ModelDriven Engineering Languages and Systems (MoDELS2009), pages 468–483. Springer, 2009.

[6] L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos.Non-Functional Requirements in Software Engineering.Springer, 1999.

[7] M. Cossentino, S. Gaglio, L. Sabatucci, and V. Seidita. ThePASSI and agile PASSI MAS meta-models compared with aunifying proposal. In International Workshop of Central andEastern Europe on Multi-Agent Systems (CEEMAS 2005),pages 183–192. Springer, 2005.

[8] A. Dardenne, A. van Lamsweerde, and S. Fickas.Goal-directed requirements acquisition. Science of ComputerProgramming, 20(1-2):3–50, 1993.

[9] R. Darimont and A. van Lamsweerde. Formal refinementpatterns for goal-driven requirements elaboration. In Proc. ofthe 4th ACM SIGSOFT symposium on Foundations ofsoftware engineering, pages 179–190, 1996.

[10] S. A. DeLoach, M. F. Wood, and C. H. Sparkman.Multiagent systems engineering. The International Journalof Software Engineering and Knowledge Engineering,11(3):231–258, 2001.

[11] J. J. Gutiérrez, C. Nebut, M. J. Escalona, M. Mejías, andI. M. Ramos. Visualization of use cases throughautomatically generated activity diagrams. In Proceedings ofthe 11th international conference on Model DrivenEngineering Languages and Systems (MoDELS ’08), pages83–96, Berlin, Heidelberg, 2008. Springer-Verlag.

[12] D. Hatebur, M. Heisel, and H. Schmidt. A formal metamodelfor problem frames. In Proc. of the 11th internationalconference on Model Driven Engineering Languages andSystems (MoDELS ’08), pages 68–82, Berlin, Heidelberg,2008. Springer-Verlag.

[13] M. Jackson. Problem Frames: Analysing and StructuringSoftware Development Problems. Addison-Wesley, 2000.

[14] T. Juan, A. Pearce, and L. Sterling. Roadmap: extending thegaia methodology for complex open systems. In Proc. of thefirst international joint conference on Autonomous agentsand multiagent systems (AAMAS ’02), pages 3–10, NewYork, NY, USA, 2002. ACM.

[15] T. Juan and L. Sterling. The roadmap meta-model forintelligent adaptive multi-agent systems in openenvironments. In Proc. of the 4th International workshop onAgent Oriented Software Engineering, pages 53–68, 2003.

[16] P. P. Kuan, S. Karunasekera, and L. Sterling. Improving goaland role oriented analysis for agent based systems. InASWEC ’05, pages 40–47. IEEE Computer Society, 2005.

[17] E. Letier. Reasoning about Agents in Goal-OrientedRequirements Engineering. PhD thesis, UniversiteCatholique de Louvain, 2001.

[18] M. Luck, R. Ashri, and M. D’Inverno. Agent-Based SoftwareDevelopment. Artech House, 2004.

[19] M. Morandini, L. Penserini, and A. Perini. Towardsgoal-oriented development of self-adaptive systems. In Proc.of the International Workshop on Software Engineering forAdaptive and Self-managing Systems (SEAMS2008), pages9–16, Leipzig, Germany, 2008.

[20] H. Nakagawa, T. Karube, and S. Honiden. Analysis ofmulti-agent systems based on KAOS modeling. In Proc. ofthe 28th International Conference on Software Engineering(ICSE 2006), pages 926–929, Shanghai, China, 2006. ACM.

[21] H. Nakagawa, N. Yoshioka, A. Ohsuga, and S. Honiden. Aframework for validating task assignment in multi-agentsystems using requirements importance. In Proc. of the 13thInternational Conference on Principles and Practice ofMulti-Agent Systems (PRIMA2010), Kolkata, India, 2010.

[22] B. Nuseibeh. Weaving together requirements andarchitectures. IEEE Computer, 34(3):115–117, 2001.

[23] L. Padgham and MichaelWinikoff. Prometheus: Amethodology for developing intelligent agents. In LectureNotes in Computer Science: Agent-Oriented SoftwareEngineering III: Third International Workshop (AOSE 2002),volume 2585, pages 174–185. Springer, 2003.

[24] M. Smialek, J. Bojarski, W. Nowakowski, A. Ambroziewicz,and T. Straszak. Complementary use case scenariorepresentations based on domain vocabularies. In Proc. of the10th International Conference on Model Driven EngineeringLanguages and Systems (MoDELS ’07), pages 544–558,Nashville, USA, 2007. Springer.

[25] A. van Lamsweerde. Requirements engineering in the year

1417

00: a research perspective. In Proc. of the 22nd internationalconference on Software engineering (ICSE ’00), pages 5–19.ACM, 2000.

[26] A. van Lamsweerde. Goal-oriented requirementsengineering: A guided tour. In Fifth IEEE InternationalSymposium on Requirements Engineering (RE’01), pages249–262, Toronto, Canada, 2001.

[27] M. Wooldridge. An Introduction to Multiagent Systems (2ndEd.). John Wiley & Sons, 2009.

[28] M. Wooldridge, N. R. Jennings, and D. Kinny. The gaiamethodology for agent-oriented analysis and design.Autonomous Agents and Multi-Agent Systems, 3(3):285–312,2000.

[29] E. S. K. Yu. Towards modelling and reasoning support forearly-phase requirements engineering. In In Proc. of the 3rdIEEE International Symposium on RequirementsEngineering (RE’97), pages 226–235, 1997.

[30] T. Yue, L. C. Briand, and Y. Labiche. A use case modelingapproach to facilitate the transition towards analysis models:Concepts and empirical evaluation. In Proc. of the 12thInternational Conference on Model Driven EngineeringLanguages and Systems (MODELS ’09), pages 484–498.Springer, 2009.

[31] F. Zambonelli, N. R. Jennings, and M. Wooldridge.Developing multiagent systems: The Gaia methodology.ACM Transactions on Software Engineering andMethodology, 12(3):317–370, 2003.

APPENDIXA. TRANSFORMATION ALGORITHM

FROM KAOS INTO GAIAInput: kM: (Restricted) KAOS modelOutput: gM: Gaia model1: /* Role identification */2: for all agent in kM.Agents do3: if ∃ req ∈ km.Requirements ((agent, req) ∈ km.Assignments)

then4: gM.Roles← gM.Roles ∪ {agent};5: end if6: if ∃ exp ∈ km.Expectations ((agent, exp) ∈ km.Assignments)

then7: gM.ExternalActors← gM.ExternalActors ∪ {agent};8: end if9: end for

10:11: /* Activity extraction */12: for all op in kM.Operations do13: if role ∈ gM.Roles ∧ (role, op) ∈ kM.Performs then14: role.Activities←role.Activities∪{op};15: end if16: end for17:18: /* Interaction extraction */19: for all event in kM.Events do20: senderOp← op1 ∈ kM.Operations (op1.output = event);21: receiverOp← op2 ∈ kM.Operations (op2.cause = event);22: if (role1 ∈ gM.Roles ∧ (role1, senderOp) ∈ kM.Performs)

∧ (role2 ∈ gM.Roles ∧ (role2, receiverOp) ∈ kM.Performs)then

23: role1.Protocols← role1.Protocols ∪ {event};24: role2.Protocols← role2.Protocols ∪ {event};

25: end if26: end for27:28: /* Organizations discovery */29: for all opDiagram in kM.OperationDiagrams do30: org← opDiagram; //org: organization31: gM.Organizations← gM.Organizations ∪ {org};32: for all operation in opDiagram do33: if role ∈ gM.Roles ∧ (role, operation) ∈ kM.Performs

then34: org.Members← org.Members ∪ {role};35: end if36: end for37: end for38:39: /* Environmental resource aggregation */40: for all entity in kM.Entities do41: obj← entity;42: gM.Objects← gM.Objects ∪ {obj};43: for all role in gM.Roles do44: for all activity in role.Activities do45: if activity.output = obj then46: obj.setMASPermission(“Changes”);47: obj.setPermission(“Changes”);48: role.Permissions← role.Permissions ∪ {obj};49: else50: if activity.input = obj then51: obj.setPermission(“Reads”);52: role.Permissions← role.Permissions ∪ {obj};53: end if54: end if55: end for56: end for57: if obj.getMASPermission() = null then58: obj.setMASPermission(“Reads”);59: end if60: end for61:62: /* Extraction of the role model */63: for all role in gM.Roles do64: role.liveness← sequences generated by transformation rules

in Table 2;65: end for

1418